Date: Sat, 3 Feb 2024 08:59:46 -0700 From: Warner Losh <imp@bsdimp.com> To: "Bjoern A. Zeeb" <bz@freebsd.org> Cc: Gleb Smirnoff <glebius@freebsd.org>, =?UTF-8?Q?Mina_Gali=C4=87?= <freebsd@igalic.co>, Warner Losh <imp@freebsd.org>, src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: git: ce348fe5cfc3 - main - amd64 & i386: enable VIMAGE in MINIMAL Message-ID: <CANCZdfoBonTCdLNXR3AUt9KiQPQOgmf8A6A9cXd%2BQY05-h3sWQ@mail.gmail.com> In-Reply-To: <70o6oo0s-r8nn-7r92-5s6r-6so586rpo1o1@SerrOFQ.bet> References: <202402030136.4131aQIM010980@gitrepo.freebsd.org> <Zb3OC2IxxL8dlTUV@cell.glebi.us> <70o6oo0s-r8nn-7r92-5s6r-6so586rpo1o1@SerrOFQ.bet>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000cd4fa806107c5182 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [[ moved this to arch@ ]] On Sat, Feb 3, 2024 at 6:44=E2=80=AFAM Bjoern A. Zeeb <bz@freebsd.org> wrot= e: > 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 --000000000000cd4fa806107c5182 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div>[[ moved this to arch@ ]]<br><d= iv><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat,= Feb 3, 2024 at 6:44=E2=80=AFAM Bjoern A. Zeeb <<a href=3D"mailto:bz@fre= ebsd.org">bz@freebsd.org</a>> wrote:<br></div><blockquote class=3D"gmail= _quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204= ,204);padding-left:1ex">On Fri, 2 Feb 2024, Gleb Smirnoff wrote:<br> > To be fair, it totally disagree with this change.<br> <br> For different reasons I second that.<br> VIMAGE definitively does not belong in MINMAL for comfort.<br></blockquote>= <div><br></div><div>I too had reservations about this change when it was su= bmitted. Allow me to explain my reasoning.</div><div><br></div><div>Years a= go 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 wa= s an unsustainable trend.</div><div><br></div><div>So I embarked on the pro= ject to reduce GENERIC to its core parts, and load the rest. This idea date= d back to when I committed devd to the tree, though it was almost an aftert= hought with the nomatch events there. I wrote devmatch and decorated all th= e PNP tables in the tree (with much help) so that we could load all the dri= vers on demand automatically. As part of this work I created the MINIMAL ke= rnel. A name I now regret, but the theory of the kernel was "everythin= g you need to boot, but everything else will be dynamically loaded". T= here are (still?) some things in it that could be loaded, like serial drive= rs, because we can't (couldn't? I haven't rechecked in years) h= ave the console be=C2=A0 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 MINIMA= L some time ago. Manu even did some good work in the boot loader to parse t= he linker.hints file so that fdt drivers could be loaded there (we still ne= ed PCI and ACPI). But common root filesystem devices were retained. So this= kernel has always had the charter of the GENERIC minus everything you coul= d 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 c= am.ko. In time, I'd hoped the default kernel would become MINIMAL and n= obody (or almost nobody) would notice.<br></div><div><br></div><div>So when= this pull request came in, my initial reaction was 'yuck, why do you n= eed it?' I too thought it was too much for MINIMAL. However, VIMAGE fal= ls under the 'can't load it later' exception. And it's not = exactly a trivial piece of infrastructure that we can just ignore. It provi= des useful functionality when paired with jails. It was also in GENERIC. Th= ese reasons coupled together let the idea grow on me. It ticked all my boxe= s: 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 commit= ted 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.</div><= div><br></div><div>Now, I totally get the desire to have a minimal kernel t= hat doesn't have any baggage in it. I totally support that notion. Mayb= e 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 M= INIMAL to MODULAR and have it (eventually) become the new default. Or we ne= ed 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 fo= r what's in this config (the absolute smallest that will boot? Or are t= here a few additional things that are needed).<br></div><div><br></div><div= >One problem, as noted on irc, is that we need to have slightly better part= itioning of the config files, so that we have a MI std.generic and std.mini= mal 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 la= nguage to properly account for the subtle differences between 'requires= ' and 'depends-on'. The former concept is 'bring in this de= pendency when this item is included' (we don't have this) vs the la= tter '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 ti= mes, but never produced any useful results. Having better tools here might = be helpful, but it's the new sysinstall in many ways.<br></div><div><br= ></div><div>I also love the idea of having a few more kernels that test unu= sual combinations. That's also a good goal. But MINIMAL's charter i= sn't to fulfill that goal. How we balance that with increased 'univ= erse' times is also something that requires some careful thought. We= 9;ve just recently managed to get the number of 32-bit arm kernels under co= ntrol 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 dr= iven testing).<br></div><div><br></div><div>Warner<br></div></div></div></d= iv> --000000000000cd4fa806107c5182--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoBonTCdLNXR3AUt9KiQPQOgmf8A6A9cXd%2BQY05-h3sWQ>