Date: Wed, 27 Mar 2019 10:31:16 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: Warner Losh <imp@bsdimp.com> Cc: Kyle Evans <kevans@freebsd.org>, Konstantin Belousov <kostikbel@gmail.com>, Rebecca Cran <rebecca@bluestop.org>, "freebsd-arch@freebsd.org" <arch@freebsd.org>, "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, 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: <201903271731.x2RHVGJd090752@gndrsh.dnsmgr.net> In-Reply-To: <CANCZdfoR5d-i=J3ir5yDLkRBZ969=HBQ=NwH2A-7%2B3uHiPhL=A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201903271731.x2RHVGJd090752>