From owner-freebsd-arch@freebsd.org Wed Mar 27 17:31:25 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D98FD155571A for ; Wed, 27 Mar 2019 17:31:24 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 1D539850AC for ; Wed, 27 Mar 2019 17:31:24 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id D4F9D1555719; Wed, 27 Mar 2019 17:31:23 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9779F1555718 for ; Wed, 27 Mar 2019 17:31:23 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1688A850A9; Wed, 27 Mar 2019 17:31:22 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x2RHVG3F090753; Wed, 27 Mar 2019 10:31:16 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x2RHVGJd090752; Wed, 27 Mar 2019 10:31:16 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201903271731.x2RHVGJd090752@gndrsh.dnsmgr.net> Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" In-Reply-To: To: Warner Losh Date: Wed, 27 Mar 2019 10:31:16 -0700 (PDT) CC: Kyle Evans , Konstantin Belousov , Rebecca Cran , "freebsd-arch@freebsd.org" , "Rodney W. Grimes" , FreeBSD Hackers X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 1688A850A9 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.95 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.95)[-0.954,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 17:31:25 -0000 > On Wed, Mar 27, 2019 at 8:26 AM Kyle Evans wrote: > > > On Wed, Mar 27, 2019 at 3:47 AM Rodney W. Grimes > > 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