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