OpenWrt Next Generation Ideas

[Daniel Golle]

Hi!

On Fri, Mar 31, 2023 at 12:44:12PM +0300, Arınç ÜNAL wrote:
> Hi all,
> 
> These are the ideas I've been thinking about for the future of OpenWrt for a
> while. It looks complete enough to share it with all of you.
> 
> I'm willing to put a great deal of effort to get as much out-of-tree patches
> on mainline Linux as possible.
> 
> You can make a comment on Notion or discuss it here, I'm wondering if the
> ideas are feasible and how well it would benefit the people maintaining
> OpenWrt.
> 
> https://arinc9.notion.site/OpenWrt-next-gen-ideas-6db745e7584b4823950291c96f2326bb

I will comment here, I don't have an account on Notion and it seems
to be required to be able to comment there.

> defconfig for each device instead of config for each (sub)target.

Given that we support thousands of devices this will not only increase
the time needed to build a release or snapshot by several magnitudes,
but also make debugging **much** harder. As of now, all devices of a
subtarget are using the same kernel, hence e.g. symbol offsets in a
kernel stack dump match for all of them. To reproduce or investigate
a problem it's hence enough to have similar hardware, not necessarily
the exact same board. As we are already lacking testers and maintainers
for the relatively small amount of targets/subtargets, have a build for
each board would make things much worse...

Per-device builds would also be an invitation to downstream users to
introduce device-specific (kernel-)hacks. If you want that, better go
for OpenEmbedded.

We can modularize things more or even have more sub-targets if it's
really needed to save space.

The disadvantages outweight the advantages imho when it comes to having
a complete kernel build for each device.

> Some Modest Virtualization Observations

How is this related? Virtualization (with OpenWrt being the guest)
matters on x86 which is usually not that space-constraint.
And maybe armvirt. If space is a problem for older x86 boards, let's
disable guest support in x86/legacy.

> Contribute defconfigs and all the devicetrees on OpenWrt to Linux.

For devicetrees this would of course be desirable, but also implies a
lot of work and discussions. If you are up to get it started (ie. setup
a tree to collect cleaned-up and ready to submit dts), I think it would
be worth the effort, at least for more recent targets/SoCs.

Regarding defconfigs I don't think we need an individual defconfig for
each board. The problem here is also that OpenWrt currently has a layered
approach (generic->target->subtarget) approach while Linux itself has
a flat approach, and using that would result in a lot of duplication,
which would in turn make keeping all those defconfigs up-to-date quite
a lot of work...

> Either submit all out-of-tree patches on OpenWrt to Linux or get rid
> of them and find a better solution for what the unacceptable patch
> does.

This would of course be great, but especially for legacy devices it may
not be possible in many cases. Think of all the devices stuck on
swconfig, just to name one example... Think of all the completely
broken vendor bootloaders which require hacks (mangeling kernel cmdline
and such) and cannot easily be replaced...

> Bugfix backporting should happen only after it's accepted to Linux.
> The patch must be identical to the commit on Linux.

The wording here might be a bit too strict to support our existing
mess, but I generally agree. So I'd say 'should' instead of 'must', but
otherwise agree.

> Feature backporting should be done only if it's thoroughly tested.

... and testing often happens in the OpenWrt tree. So it's a bit of
a chicken-egg problem, as often developers don't even have all the
different hardware needed for testing. But generally I agree.
A way to ease testing *before* pushing to openwrt.git or posting to
upstream mailing lists would be to have snapshot builds also for
developers' staging trees.

> Kernel Solution
> Make a mode menu.
> Filesystem only.

So which kernel headers should be used to build e.g. libc and netlink
users?
In a way it is also currently possible to build generic images for
most architectures using the armvirt, malta and x86 targets. Of course,
also in this case a kernel is being built.

> Make a kernel selection menu where the user can choose to feed the
> kernel directory of their own or use the longterm one defined on the
> OpenWrt SDK. Add this as a suboption to the full image mode.

What about CONFIG_EXTERNAL_KERNEL_TREE and friends...?