Re: git: ce348fe5cfc3 - main - amd64 & i386: enable VIMAGE in MINIMAL

[[ 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