Date: Wed, 7 Feb 2018 07:41:15 -0500 From: Eric McCorkle <eric@metricspace.net> To: freebsd-arch@freebsd.org Subject: Re: Feedback on proposed loader changes Message-ID: <2c882f57-def0-b9f1-3c62-147cbe6bec02@metricspace.net> In-Reply-To: <CANCZdfoF4M1k=wOzueg0KQk9tRoQT-hO0SrB51wxv=-n3ESiUw@mail.gmail.com> References: <CANCZdfoF4M1k=wOzueg0KQk9tRoQT-hO0SrB51wxv=-n3ESiUw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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). 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. 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. I doubt this would interfere with 4th replacement, but I'd like to not have this stuff get hit by stray changes. 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. I've tried to > resolve all the issues it brought up in libsa and other structural changes. > This has allowed lua to be imported unmodified, for example. > > 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. > > 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. We have a bit of a > hack in place for both the pcibios-* and efi-* functions in 4th. 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). > 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). My plan is to simply retire > this stuff, along with pnp.4th which we've never installed. 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... > > If no .o 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. 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. 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). 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. 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). > > 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.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2c882f57-def0-b9f1-3c62-147cbe6bec02>