From owner-freebsd-arch@freebsd.org Wed Feb 7 16:24:19 2018 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 B842DF12798 for ; Wed, 7 Feb 2018 16:24:19 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 42A2970CE2 for ; Wed, 7 Feb 2018 16:24:19 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [10.1.38.238] (mobile-107-107-63-237.mycingular.net [107.107.63.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 8776E283C; Wed, 7 Feb 2018 16:24:12 +0000 (UTC) Date: Wed, 07 Feb 2018 11:24:10 -0500 User-Agent: K-9 Mail for Android In-Reply-To: References: <2c882f57-def0-b9f1-3c62-147cbe6bec02@metricspace.net> MIME-Version: 1.0 Subject: Re: Feedback on proposed loader changes To: Warner Losh CC: "freebsd-arch@freebsd.org" From: Eric McCorkle Message-ID: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 16:24:20 -0000 The issues tsoome raised with efipart have been dealt with in more recent u= pdates=2E He just hasn't been able to respond yet=2E On February 7, 2018 10:54:05 AM EST, Warner Losh wrote: >I'm afraid not=2E There's still unresolved issues in the efipart driver >changes in the reviews that tsoome raised, so it isn't ready=2E Lua is 3 >commits away and is to the point where all the refinement of those >three >changes is in code that's not in the tree yet=2E It goes in first, >hopefully >this week=2E I doubt there will be any affect on your ongoing work=2E > >Warner > >On Wed, Feb 7, 2018 at 5:41 AM, Eric McCorkle >wrote: > >> Might I suggest we integrate the GELI work before this goes in? It >can >> be added to loader as-is, and it works fine if you apply my >standalone >> loader patch (I have it deployed on a personal laptop)=2E >> >> I'm on the third major revision of this work (with countless smaller >> rebases), and I'd like to not have to redo it a fourth time=2E >> >> Basically, you'd need to commit some fixes to the efipart driver, the >> UEFI KMS driver, the keybuf integration, and finally, the GELI driver >> itself=2E I doubt this would interfere with 4th replacement, but I'd >like >> to not have this stuff get hit by stray changes=2E >> >> On 02/01/2018 00:03, Warner Losh wrote: >> > Greetings, >> > >> > As you may have read or guessed, I'm nearing the end game on >integrating >> > lua into the boot loader from the GSoC a few years ago=2E I've tried >to >> > resolve all the issues it brought up in libsa and other structural >> changes=2E >> > This has allowed lua to be imported unmodified, for example=2E >> > >> > I've been trying to figure out how to handle the transition from >forth to >> > lua and find myself with a few decisions that I should seek >feedback on >> > since I'm at a crossroads=2E >> > >> > The first one is that we have two sets of 4th words, both of which >I >> wrote, >> > that don't fit neatly into the current build system=2E We have a bit >of a >> > hack in place for both the pcibios-* and efi-* functions in 4th=2E >The >> former >> > was something I did as a hack for Netflix that I judged at the time >to be >> > more useful than it turned out to be (as far as I've been able to >tell)=2E >> > The latter turns out to be a road not taken (I'd planned originally >on >> > implementing UEFI boot manager with 4th, but that turns out to be >not >> > desirable even if 4th might be out the door)=2E My plan is to simply >retire >> > this stuff, along with pnp=2E4th which we've never installed=2E If I >do >> this, >> > then I can build everything in the tree w/o regard to whether FORTH >is on >> > or off, which dove tails nicely to my next question=2E=2E=2E >> > >> > If no =2Eo depends on the interpreter we're using (other than the >ones that >> > implement the interpreter), then there'd be no technical barrier to >> > building multiple interpreters=2E So, I'd like to change to building >both >> > the loader with forth and the one without, as well as installing >both (as >> > loader_simple and loader_forth) with a symlink to the default=2E This >would >> > allow people to switch, as well as provide a fallback for most >systems >> > (uboot on FAT would be trickier, but we don't directly install >those from >> > installworld, EFI on FAT would be as well, but there it will matter >much >> > less shortly)=2E This would allow me to roll out loader_lua when it's >ready >> > and have it installed everywhere for people that want to take the >plunge >> > and switch it when the time is ripe=2E This path would also leave the >old >> > boot loaders around for people to interrupt boot1 with (EFI is >another >> > matter, but I'm hoping efibootmgr wills solve that ball of wax)=2E >> > >> > So I'd like feedback on two questions: Should I kill the forth >features I >> > oulined above? And should I make the build system build multiple >loaders >> > with a link controlling the default? >> > >> > Comments? >> > >> > Warner >> > _______________________________________________ >> > freebsd-arch@freebsd=2Eorg mailing list >> > https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-arch >> > To unsubscribe, send any mail to >"freebsd-arch-unsubscribe@freebsd=2Eorg" >> > >> _______________________________________________ >> freebsd-arch@freebsd=2Eorg mailing list >> https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to >"freebsd-arch-unsubscribe@freebsd=2Eorg" >> --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E From owner-freebsd-arch@freebsd.org Wed Feb 7 16:31:04 2018 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 CBDF7F12E4A for ; Wed, 7 Feb 2018 16:31:04 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F48E710CF for ; Wed, 7 Feb 2018 16:31:04 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (220-253-149-130.dyn.iinet.net.au [220.253.149.130]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w17GUxFg070406 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 7 Feb 2018 08:31:02 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: Feedback on proposed loader changes To: Warner Losh , Eric McCorkle Cc: "freebsd-arch@freebsd.org" References: <2c882f57-def0-b9f1-3c62-147cbe6bec02@metricspace.net> From: Julian Elischer Message-ID: <3ef628a0-becd-dc4c-c3d0-efd121e841da@freebsd.org> Date: Thu, 8 Feb 2018 00:30:53 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 16:31:05 -0000 On 8/2/18 12:04 am, Warner Losh wrote: > > As for redoing things, I've just finished redoing ~15-years of sys/boot > neglect for stuff that wasn't done right the first time, so please be > patient with my pickiness. > > Warner the boot code in all its varying forms needs a full (re) writeup. the boot(8) man page and the handbook description (chapter 12 I think) are nowhere near complete. If you are doing this work I'd ask if you can spend a few hours on that too? That way we can follow what the new code is doing better. (and don't forget examples) Especially concentrating on changes..