OpenWrt Next Generation Ideas

[Arınç ÜNAL]

On 31.03.2023 19:35, Felix Fietkau wrote:
> 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.

I just thought of this. Why don't we just, for example, 'make 
mt7621_defconfig && make mod2noconfig', then compile normally with 
kernel module packages. This way, OpenWrt compiles a kernel with the 
least amount of kernel modules (or rather, it compiles the kernel like 
it always did), and people compiling the kernel outside of OpenWrt can 
choose to remove the kernel modules they don't need.

Arınç