Date: Wed, 27 Mar 2019 09:23:59 -0600 From: Warner Losh <imp@bsdimp.com> To: Kyle Evans <kevans@freebsd.org> Cc: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, Konstantin Belousov <kostikbel@gmail.com>, Rebecca Cran <rebecca@bluestop.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" Message-ID: <CANCZdfoR5d-i=J3ir5yDLkRBZ969=HBQ=NwH2A-7%2B3uHiPhL=A@mail.gmail.com> In-Reply-To: <CACNAnaE6xvVL=1B1-26YGnrezqCDTB6YF3%2BooA%2BX_2X2Hvw_4w@mail.gmail.com> References: <0828a41a-c25d-37a2-25b3-82c35c9a5c5d@bluestop.org> <201903270847.x2R8lMxc088823@gndrsh.dnsmgr.net> <CACNAnaE6xvVL=1B1-26YGnrezqCDTB6YF3%2BooA%2BX_2X2Hvw_4w@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. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoR5d-i=J3ir5yDLkRBZ969=HBQ=NwH2A-7%2B3uHiPhL=A>