OpenWrt Next Generation Ideas

[Felix Fietkau]

On 31.03.23 18:22, Arınç ÜNAL wrote:
> On 31.03.2023 19:04, Felix Fietkau wrote:
>> On 31.03.23 14:52, Arınç ÜNAL wrote:
>>> 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.
>>>
>>> Hmm, what about we enable the bare minimum of kernel options for a
>>> target, which is already how it is, then select the rest as kernel
>>> modules (like on the makefile of a target for each device) on the
>>> defconfig for each device? So, in the end, it wouldn't be any different
>>> than selecting a kernel module package from the OpenWrt SDK which, I
>>> believe, does not change the symbol offsets in the kernel stack.
>>>
>>> My reason for pushing for the use defconfigs is that anyone can build
>>> the Linux kernel for their device, without needing OpenWrt. So the work
>>> for adding support for a device would benefit far more people.
>> There are a lot of options in the OpenWrt menuconfig (including kmod 
>> package selections) which *do* affect the kernel compilation in a major 
>> way. They can change struct sizes, enabled features, affect compiled-in 
>> code inside functions, etc.
>> 
>> For maintenance, I strongly believe that switching from the current 
>> system to maintaining full kernel config files is a huge step backwards, 
>> because maintaining individual config files makes them so much easier to 
>> accidentally go out of sync with each other.
>> 
>> If you want to make it easier to build per-device kernels outside of
>> OpenWrt, I'd recommend adding a build system feature to export target 
>> defconfig files.
> 
> I agree that it'd be a lot to maintain. A defconfig per (sub)target is
> much better. It's not so different than what we already have in OpenWrt
> except that it will be on mainline Linux so even people outside of the
> OpenWrt environment can benefit from it.
> 
> I'm starting this off by making a defconfig for the ramips/mt7621 subtarget.

Sure, sending such defconfig files to mainline is a good idea, as long 
as there is no expectation that these will be used by OpenWrt directly 
in any way.

- Felix