Date: Wed, 07 Feb 2018 11:24:10 -0500 From: Eric McCorkle <eric@metricspace.net> To: Warner Losh <imp@bsdimp.com> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Feedback on proposed loader changes Message-ID: <A8A666E1-98A8-4F30-81A6-02712DE5F980@metricspace.net> In-Reply-To: <CANCZdfo4PB6mUFQ-%2B09xLZnBBxKH0LFCrTjVE=jD6oeFTodaZw@mail.gmail.com> References: <CANCZdfoF4M1k=wOzueg0KQk9tRoQT-hO0SrB51wxv=-n3ESiUw@mail.gmail.com> <2c882f57-def0-b9f1-3c62-147cbe6bec02@metricspace.net> <CANCZdfo4PB6mUFQ-%2B09xLZnBBxKH0LFCrTjVE=jD6oeFTodaZw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <imp@bsdimp=2Ecom> 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 <eric@metricspace=2Enet> >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: <owner-freebsd-arch@freebsd.org> 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 <freebsd-arch@mailman.ysv.freebsd.org>; 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 <freebsd-arch@freebsd.org>; 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 <imp@bsdimp.com>, Eric McCorkle <eric@metricspace.net> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> References: <CANCZdfoF4M1k=wOzueg0KQk9tRoQT-hO0SrB51wxv=-n3ESiUw@mail.gmail.com> <2c882f57-def0-b9f1-3c62-147cbe6bec02@metricspace.net> <CANCZdfo4PB6mUFQ-+09xLZnBBxKH0LFCrTjVE=jD6oeFTodaZw@mail.gmail.com> <CANCZdfoCJhLEf5fcenWJ3No=Pm-QaynubWjxzBEk4gXkRmOsaQ@mail.gmail.com> From: Julian Elischer <julian@freebsd.org> 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: <CANCZdfoCJhLEf5fcenWJ3No=Pm-QaynubWjxzBEk4gXkRmOsaQ@mail.gmail.com> 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 <freebsd-arch.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arch>, <mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch/>; List-Post: <mailto:freebsd-arch@freebsd.org> List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arch>, <mailto:freebsd-arch-request@freebsd.org?subject=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..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A8A666E1-98A8-4F30-81A6-02712DE5F980>