From owner-freebsd-hackers@freebsd.org Wed Mar 27 15:24:13 2019 Return-Path: Delivered-To: freebsd-hackers@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 845BB1552D2B for ; Wed, 27 Mar 2019 15:24:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F162D80EFB for ; Wed, 27 Mar 2019 15:24:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-lf1-x133.google.com with SMTP id u9so11577324lfe.11 for ; Wed, 27 Mar 2019 08:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Cw8Oj+xmVH3AUxa/tV2nqMXSjCj2kGzimJSuADGVqF4=; b=rqAQq1H4fUE6yMEk8JRD3HTAmtflZEA0iLwv5rxzxpiRoRmrlBSt7fQgN2NtxsbljL ra7FTzwVWFO9P14b/7811LncSHSyx46R2nFjRs/q0AImjREBdtAX0oReen9WExqF7qK/ 9c3pQ8dtDs/CL7s9LwCJdOynJ1qO+NvY7E8GmA5RXnzPZhfJFnqRaSXxkEdhoWUFbkt0 doSOHLB416S8ZHMTBnKXMB3sY9aRWWDtkNVSaji+0dHPDWSkJH0FmbMdq2YSuXxNlHC0 I03z07dfXFfnFHxA7jYBQg7TSV7yeGpW3ESHO9EscxACKCAQPrE3Tl4QyWo/Nw23HZUI Nx8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Cw8Oj+xmVH3AUxa/tV2nqMXSjCj2kGzimJSuADGVqF4=; b=P3gE/QBXgzhbC3Qob5Qjp+ZLf6Us96ljsjyqMDAfWMqDUCc+P+PCP8ZwUwl6SujRxR Y0Y7iDBLvaFLsFqO3EmJ6dRMTQ+PuZekGd0wkkjWXado3de12dfsJ0BCMGL7sXM+G9hf NI16WMPuV5SqHckuySv7t4NKKoAR85+Qbq18a4MxtedBIP+fxmsghFixyG+XS1L2pR2W 7Me+XfRkTUtgH9cphqMo3Kkasrtv+7lh0nK0kfYShw4nBqV9i6JEDT+gVgy1y0j6opvS mcGuE9hMVva3FCusLK7Zes0sLPRziaq54c4t8WfcH8FUNe4gf+lc58eF3zOakeSKJ513 m13Q== X-Gm-Message-State: APjAAAUpTbVDJac4Tbj/zr0mS4G3705Sf4BPm3AtK0Ijb8MvUcjwhrC5 9cBMogpGRMsMG6g9nYHshEGvccdWFlGR8OeQFhWPQA== X-Google-Smtp-Source: APXvYqzLfgNyWtYifyQwpn65JZfx5UcvA6qJ4RokVaefjRetm1OiYbkTcjICFiea6WjMLmaQeW2d/06UrlP+9CBRLoE= X-Received: by 2002:ac2:592f:: with SMTP id v15mr14302952lfi.133.1553700250994; Wed, 27 Mar 2019 08:24:10 -0700 (PDT) MIME-Version: 1.0 References: <0828a41a-c25d-37a2-25b3-82c35c9a5c5d@bluestop.org> <201903270847.x2R8lMxc088823@gndrsh.dnsmgr.net> In-Reply-To: From: Warner Losh Date: Wed, 27 Mar 2019 09:23:59 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Kyle Evans Cc: "Rodney W. Grimes" , Konstantin Belousov , Rebecca Cran , FreeBSD Hackers , "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: F162D80EFB X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.971,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 15:24:13 -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. Warner