Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 31 Jan 2018 22:03:02 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>
Subject:   Feedback on proposed loader changes
Message-ID:  <CANCZdfoF4M1k=wOzueg0KQk9tRoQT-hO0SrB51wxv=-n3ESiUw@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoF4M1k=wOzueg0KQk9tRoQT-hO0SrB51wxv=-n3ESiUw>