Re: git: ce348fe5cfc3 - main - amd64 & i386: enable VIMAGE in MINIMAL
- Reply: Bakul Shah : "Re: git: ce348fe5cfc3 - main - amd64 & i386: enable VIMAGE in MINIMAL"
- Reply: Gleb Smirnoff : "Re: git: ce348fe5cfc3 - main - amd64 & i386: enable VIMAGE in MINIMAL"
- Reply: Jamie Landeg-Jones : "Re: git: ce348fe5cfc3 - main - amd64 & i386: enable VIMAGE in MINIMAL"
- In reply to: Bjoern A. Zeeb: "Re: git: ce348fe5cfc3 - main - amd64 & i386: enable VIMAGE in MINIMAL"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 03 Feb 2024 15:59:46 UTC
[[ moved this to arch@ ]] On Sat, Feb 3, 2024 at 6:44 AM Bjoern A. Zeeb <bz@freebsd.org> wrote: > On Fri, 2 Feb 2024, Gleb Smirnoff wrote: > > To be fair, it totally disagree with this change. > > For different reasons I second that. > VIMAGE definitively does not belong in MINMAL for comfort. > I too had reservations about this change when it was submitted. Allow me to explain my reasoning. Years ago I did a study on the Unix kernel size over time. It was doubling every 3 years or so going back to 1970. I'll skip all the details, but this was an unsustainable trend. So I embarked on the project to reduce GENERIC to its core parts, and load the rest. This idea dated back to when I committed devd to the tree, though it was almost an afterthought with the nomatch events there. I wrote devmatch and decorated all the PNP tables in the tree (with much help) so that we could load all the drivers on demand automatically. As part of this work I created the MINIMAL kernel. A name I now regret, but the theory of the kernel was "everything you need to boot, but everything else will be dynamically loaded". There are (still?) some things in it that could be loaded, like serial drivers, because we can't (couldn't? I haven't rechecked in years) have the console be in a kld, it had to be in the base kernel. ufs was in this list for a while, but it moved to a module and removed from MINIMAL some time ago. Manu even did some good work in the boot loader to parse the linker.hints file so that fdt drivers could be loaded there (we still need PCI and ACPI). But common root filesystem devices were retained. So this kernel has always had the charter of the GENERIC minus everything you could load after mountroot early in boot, with an eye towards pushing more out when the boot loader grew better pci support and could automatically load cam.ko. In time, I'd hoped the default kernel would become MINIMAL and nobody (or almost nobody) would notice. So when this pull request came in, my initial reaction was 'yuck, why do you need it?' I too thought it was too much for MINIMAL. However, VIMAGE falls under the 'can't load it later' exception. And it's not exactly a trivial piece of infrastructure that we can just ignore. It provides useful functionality when paired with jails. It was also in GENERIC. These reasons coupled together let the idea grow on me. It ticked all my boxes: Can it be loaded? no. Is it widely used? yes. Will I need it if I wanted to make MINIMAL the new GENERIC? yes. Based on that, I approved and committed the pull request. It was well within the remit of MINIMAL based on the historic creation and change criteria I've tried to apply to it. Now, I totally get the desire to have a minimal kernel that doesn't have any baggage in it. I totally support that notion. Maybe we need another kernel in the tree to do that. Maybe it should be called MINIMAL since that name makes sense and one of two renamings happen: Either we rename GENERIC to GENERIC-STATIC and MINIMAL to GENERIC, or we rename MINIMAL to MODULAR and have it (eventually) become the new default. Or we need to create a new name that connotes the same things that MINIMAL seems to inspire in people (since the name evokes notions not quite compatible with my original charter for it). I have nothing on good names, though. All the ones I thought of have other issues, though maybe staking out a charter for what's in this config (the absolute smallest that will boot? Or are there a few additional things that are needed). One problem, as noted on irc, is that we need to have slightly better partitioning of the config files, so that we have a MI std.generic and std.minimal that the MD versions of these kernels can pull in and flavor. That's possible, with effort, with config(8). But it isn't super pleasant. I think, as a separate project, we should consider modernizing the config language to properly account for the subtle differences between 'requires' and 'depends-on'. The former concept is 'bring in this dependency when this item is included' (we don't have this) vs the latter 'don't include this item if the dependency is absent (we have this). But that's a whole other discussion that's happened a few times, but never produced any useful results. Having better tools here might be helpful, but it's the new sysinstall in many ways. I also love the idea of having a few more kernels that test unusual combinations. That's also a good goal. But MINIMAL's charter isn't to fulfill that goal. How we balance that with increased 'universe' times is also something that requires some careful thought. We've just recently managed to get the number of 32-bit arm kernels under control by making a generic there and also marking some kernels as not to be built in universe (they are for the convenience of our users, not for CI driven testing). Warner