Feedback on proposed loader changes

[Eric McCorkle]

The issues tsoome raised with efipart have been dealt with in more recent updates. He just hasn't been able to respond yet.

On February 7, 2018 10:54:05 AM EST, Warner Losh <imp at bsdimp.com> wrote:
>I'm afraid not. There's still unresolved issues in the efipart driver
>changes in the reviews that tsoome raised, so it isn't ready. 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. It goes in first,
>hopefully
>this week. I doubt there will be any affect on your ongoing work.
>
>Warner
>
>On Wed, Feb 7, 2018 at 5:41 AM, Eric McCorkle <eric at metricspace.net>
>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).
>>
>> 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"
>> >
>> _______________________________________________
>> 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"
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.