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
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
