On Fri, Mar 31, 2023 at 04:18:53PM +0000, psv sridhar wrote: > idiots, email looks like offcial and you are sending to un-known people. > Thanks and Regards
Thank you for the kind advise. This is a deliberate public debate and you are welcome to participate in any meaningful way. > Sridhar PSVPhone 571 244-5862 > > On Friday, March 31, 2023 at 11:07:50 AM CDT, Felix Fietkau > <[email protected]> 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. > > >>> Either submit all out-of-tree patches on OpenWrt to Linux or get rid > >>> of them and find a better solution for what the unacceptable patch > >>> does. > >> > >> This would of course be great, but especially for legacy devices it may > >> not be possible in many cases. Think of all the devices stuck on > >> swconfig, just to name one example... Think of all the completely > >> broken vendor bootloaders which require hacks (mangeling kernel cmdline > >> and such) and cannot easily be replaced... > > > > Those can stay until eventually the support for them will be dropped on > > newer OpenWrt versions. I believe there are a lot of out-of-tree patches > > that are not for old devices and can be on mainline Linux. > I believe that we will always need to carry some patches even for newer > platforms which will never be accepted upstream, and probably have no > place there. > One example is the NMBM NAND mapping code on MTK platforms. It was > written by MTK long after UBI had already established itself as a much > better solution. And yet, we still have to deal with it because we don't > want to make it a hard requirement to reflash U-Boot on every single > newer NAND based MTK device. > We also need to carry some hacks to Kconfig files to support our kmod > selection and our out-of-tree mac80211/cfg80211 builds. > > - Felix > > _______________________________________________ > openwrt-devel mailing list > [email protected] > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
