Feedback on proposed loader changes

[Eric McCorkle]

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 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>