Date: Thu, 28 Mar 2019 14:43:41 -0600 From: Warner Losh <imp@bsdimp.com> To: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> Cc: Kyle Evans <kevans@freebsd.org>, Konstantin Belousov <kostikbel@gmail.com>, Rebecca Cran <rebecca@bluestop.org>, "freebsd-arch@freebsd.org" <arch@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" Message-ID: <CANCZdfoPas=0GWXsYiYbBY9bxwrtVzO-6ScjfHc5t6BCxWpXwg@mail.gmail.com> In-Reply-To: <201903271731.x2RHVGJd090752@gndrsh.dnsmgr.net> References: <CANCZdfoR5d-i=J3ir5yDLkRBZ969=HBQ=NwH2A-7%2B3uHiPhL=A@mail.gmail.com> <201903271731.x2RHVGJd090752@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 27, 2019 at 11:31 AM Rodney W. Grimes < freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > On Wed, Mar 27, 2019 at 8:26 AM Kyle Evans <kevans@freebsd.org> wrote: > > > > > On Wed, Mar 27, 2019 at 3:47 AM Rodney W. Grimes > > > <freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > > > > > > > > On 3/26/19 12:21 AM, Rodney W. Grimes wrote: > > > > > > > > > > > > > > > > > The current BTX 1.1 is bit rot, that value has not changed in > ages > > > > > > and tells me nothing about what boot code I am running, why do we > > > > > > even output it? > > > > > > > > > > > > > > > Sure, but the fact it shows up as "FreeBSD/amd64 EFI loader, > Revision > > > > > 1.1" in "strings /boot/loader.efi" shows one way we could easily > embed > > > a > > > > > useful version number. > > > > > > > > Please go implement the placing of the version that is used to > > > > cause uname -U to output 1200086 or whatever from /usr/sbin/uname > > > > at build time, which is not an issue at all as far as reproducabile > > > > builds as that version number is the same no mater how many times you > > > > run the build. > > > > > > > > This is the current defining value that says your kernel is > compatible > > > > with userland and should also be the defining value for if your boot > > > > code is also compatible. > > > > > > > > > > This feels slightly wrong/misleading. We change loader -> kernel > > > handoff far, far, far less frequently than we change userland <-> > > > kernel compatibility. I don't have any constructive feedback > > > otherwise, though, and it does at least provide an indicator of how > > > old your boot bits are relative to the rest of the world. > > > > > > > Right. The loader has nothing to do with the userland (apart from sharing > > some minor bits of code that are too boring to be versioned). There are > two > > versions we're interested in for the loader. > > > > First is the loader <-> kernel handoff. That's not materially changed in > > decades, so it's version number is still basically 1. there are some fine > > details here I'm purposely glossing over, but they are far down in the > > noise. > > > > The second is the loader to loader support files version. We don't > actually > > version this, but you can't install /boot/loader* without installing the > > companion files. This often will work (especially in the FORTH era when > the > > code velocity of the .4th files was so slow and the new FORTH words / > > loader commands were added so rarely), but not always. In the LUA era, > > we're still in the up-take phase of things. We've gotten to parity (more > or > > less) with FORTH and now it's time to innovate. That innovation will > likely > > require new lua primitives to be implemented in C, which requires a > matched > > set of the loader and support files. This is nothing new (we had it when > > FORTH was moving quickly all the time, and had it less often when new > > features like ZFS booting came in). There's a new wrinkle, though, in all > > this, which is our desire to get rid of boot1.efi and replace it with > > loader.efi. This brings the issue of 'cross-threading' of updates to the > > fore. That's an interesting issue, and that won't be solved by the uname > > version hack. We could burn the sys/param.h version into loader.efi but > it > > wouldn't detect anything in the lua files we install. We could add a new > > lua file that's just the version an complain when there's a mismatch, but > > that seems to just introduce a failure mode that's not effective at > solving > > problems (there will be a lot of false positives, because the loader > > changes like I'm worried about happen at about 1/50th the rate of version > > bumps). We could invent something for the boot loader, but that would be > > fragile, and have all the same issues of 'what to do' when there's a > > mismatch. We're likely better off wrapping new features in such a way as > > they can be missing and the code will still work with reduced > functionality. > > > > This is why it feels wrong to me. It's a poor fit to the problem at hand, > > the number isn't conveniently encoded in the right places and it's > unclear > > what to do with mismatches. > > I care nothing about miss matches, I care to know from witch sources > my loader.* /boot/* files come from and that is just a royal PITA to > figure out without something like this. > You do have the $FreeBSD$ tags for most of that today. For some of the boot pieces you'll never know more than the date it was installed because we're using 7.45kb of the 7.5kb available in boot2 and there's no room. For the other things, there's not really been requests to have more than we have today and it would come at a cost of additional space at a time when we're feeling space pressure in most of the components due to the new features that have rolled in since FreeBSD 10.x or so (secure boot, crypto signing, more filesystems, encrypted filesystems, etc). It all adds up... Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoPas=0GWXsYiYbBY9bxwrtVzO-6ScjfHc5t6BCxWpXwg>