OpenWrt Next Generation Ideas

Arınç ÜNAL arinc.unal at arinc9.com
Sat Apr 1 01:10:31 PDT 2023


On 31.03.2023 14:33, Daniel Golle wrote:
> 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?

I forgot to answer this. I was thinking something similar to what 
Buildroot does. You can choose the kernel headers on the toolchain 
options. The default option is the headers of the latest longterm kernel.

Arınç



More information about the openwrt-devel mailing list