OpenWrt Next Generation Ideas

[Felix Fietkau]

On 31.03.23 18:55, Arınç ÜNAL wrote:
> On 31.03.2023 19:45, Felix Fietkau wrote:
>> On 31.03.23 18:40, Arınç ÜNAL wrote:
>> 
>>> 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.
>> 
>> Because I believe the current OpenWrt kernel config system ist vastly 
>> superior for keeping target kernel configs in sync while at the same 
>> time making it easy to keep an overview of target specific overrides as 
>> well. This is especially relevant for updating the kernel version.
> 
> Hmm, well I'll take your word for it but feel free to explain more if
> you'd like.

We do have a lot of config options that we set as default for all 
targets. With our current system, we keep them in a file in
target/linux/generic/config-<version>
A target can override any of those with its target specific config 
overlay. The clever bit of our kernel config system is that this overlay 
is not handwritten. You can use make kernel_menuconfig or 
kernel_oldconfig to make changes to it, and it will automatically filter 
out the defaults from the generic config.

When updating to a newer kernel for the first time, you can pick any 
target, copy the old version and run make kernel_oldconfig. Afterwards 
you can look through the diff and move any newly added items that should 
be generic over to the generic config template, so you won't be asked 
about it for the next target.

The expectation is that target configs should share as many options as 
possible, so it helps that you can simply go through the target config 
overlays and look at each line to see if it should stay target specific 
or if it should be moved to the generic config instead.

Also, OpenWrt commits that change settings for all targets are much 
easier to review compared to a set of full configs, because you don't 
have to manually verify if you properly applied them to all targets.

It would definitely be possible to build a workflow around full configs 
as well to try to achieve something similar, but the problem that I see 
there is that the relevant information for maintaining would not be as 
readily available. And it would be easier for configs to accidentally 
drift apart, causing spurious build issues when dealing with the 
configurability of our module packages.

- Felix