Feedback on proposed loader changes

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Feedback on proposed loader changes

Warner Losh
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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Feedback on proposed loader changes

Poul-Henning Kamp
--------
In message <CANCZdfoF4M1k=wOzueg0KQk9tRoQT-hO0SrB51wxv=-[hidden email]>, Warner Losh writes:

>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?

I think you should just move forward and go for the end-stage
without too many temporary bandaids.

The loader is pretty decoupled from everything, so in case anybody
needs any of these Forth cornercases, they can use 11.X loader with
very little, if any, trouble.

--
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[hidden email]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Feedback on proposed loader changes

Devin Teske


> On Feb 1, 2018, at 1:51 AM, Poul-Henning Kamp <[hidden email]> wrote:
>
> --------
> In message <CANCZdfoF4M1k=wOzueg0KQk9tRoQT-hO0SrB51wxv=-[hidden email]>, Warner Losh writes:
>
>> 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?
>
> I think you should just move forward and go for the end-stage
> without too many temporary bandaids.
>
> The loader is pretty decoupled from everything, so in case anybody
> needs any of these Forth cornercases, they can use 11.X loader with
> very little, if any, trouble.
>

As a person that both reviewed the GSoC code you are working with (in-depth; including a list of short-comings) and the most likely person to bring it up-to-par after it is committed, I have 2 opinions:

1. Please allow both boot systems for a while so that the lua-based menu can be made as feature full as the Forth menu. Example: submenus were added in Forth long after the GSoC lua project had ended

2. Please don’t force us to run Lua until I can code the new features

And as the principal author of the Forth menu since 9.0:

3. Please give me a way to run my code (at the very least until I can bring the Lua up to snuff; and if I can’t just let me run Forth in-perpetuity).

Interrupting boot1 so I can drive the system in the pre-boot Execution env is very important to me.

Devin
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Feedback on proposed loader changes

Warner Losh
On Thu, Feb 1, 2018 at 9:58 AM, Devin Teske <[hidden email]> wrote:

>
>
> > On Feb 1, 2018, at 1:51 AM, Poul-Henning Kamp <[hidden email]>
> wrote:
> >
> > --------
> > In message <CANCZdfoF4M1k=wOzueg0KQk9tRoQT-hO0SrB51wxv=-
> [hidden email]>, Warner Losh writes:
> >
> >> 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?
> >
> > I think you should just move forward and go for the end-stage
> > without too many temporary bandaids.
> >
> > The loader is pretty decoupled from everything, so in case anybody
> > needs any of these Forth cornercases, they can use 11.X loader with
> > very little, if any, trouble.
> >
>
> As a person that both reviewed the GSoC code you are working with
> (in-depth; including a list of short-comings) and the most likely person to
> bring it up-to-par after it is committed, I have 2 opinions:
>
> 1. Please allow both boot systems for a while so that the lua-based menu
> can be made as feature full as the Forth menu. Example: submenus were added
> in Forth long after the GSoC lua project had ended
>

OK. The plan outlined does that. The lua code will be installed into /boot.
But it will be .lua, so no conflicts with .4th. And we start from
loader.lua not loader.rc.


> 2. Please don’t force us to run Lua until I can code the new features
>

OK


> And as the principal author of the Forth menu since 9.0:
>
> 3. Please give me a way to run my code (at the very least until I can
> bring the Lua up to snuff; and if I can’t just let me run Forth
> in-perpetuity).
>
> Interrupting boot1 so I can drive the system in the pre-boot Execution env
> is very important to me.


For !EFI, this is relatively easy. boot1 you can type /boot/loader_forth
instead of the default /boot/loader if the symlink changes and you want to
go back.

For EFI the answer is more complicated. boot1.efi is going away, so
loader.efi will move to the ESP in \efi\freebsd\loader.efi, but it's easy
enough to have multiple versions there (loader_lua.efi and
loader_forth.efi) and select via EFI Shell or EFI Env variables which one
you want should you need to fall back.

Does that answer your concerns?

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Feedback on proposed loader changes

John Baldwin
On Thursday, February 01, 2018 10:59:14 AM Warner Losh wrote:

> On Thu, Feb 1, 2018 at 9:58 AM, Devin Teske <[hidden email]> wrote:
> > And as the principal author of the Forth menu since 9.0:
> >
> > 3. Please give me a way to run my code (at the very least until I can
> > bring the Lua up to snuff; and if I can’t just let me run Forth
> > in-perpetuity).
> >
> > Interrupting boot1 so I can drive the system in the pre-boot Execution env
> > is very important to me.
>
>
> For !EFI, this is relatively easy. boot1 you can type /boot/loader_forth
> instead of the default /boot/loader if the symlink changes and you want to
> go back.
>
> For EFI the answer is more complicated. boot1.efi is going away, so
> loader.efi will move to the ESP in \efi\freebsd\loader.efi, but it's easy
> enough to have multiple versions there (loader_lua.efi and
> loader_forth.efi) and select via EFI Shell or EFI Env variables which one
> you want should you need to fall back.
>
> Does that answer your concerns?

I think there is an even easier route for doing scripted loader development
now: Use bhyve with bhyveload.  You get to run the loader as a plain userland
program (so you can use normal debuggers on it while it is running) while
being able to test all the menu features.  You can even make it use the
builtin host: filesystem without requiring a disk image so you can modify the
lua files directly on the host that are getting pulled in for a fast
edit-debug cycle.

--
John Baldwin
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Feedback on proposed loader changes

Eric McCorkle-2
In reply to this post by Warner Losh
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
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "[hidden email]"
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Feedback on proposed loader changes

Warner Losh
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 <[hidden email]> 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
> > _______________________________________________
> > [hidden email] mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> > To unsubscribe, send any mail to "[hidden email]"
> >
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "[hidden email]"
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Feedback on proposed loader changes

Warner Losh
Just re-read what I posted, and I need to followup.  I should add at least
some of your other changes are somewhat close. I'll do those before my
pending efi boot loader changes. Any rework I have on them would be on me.
I'm not sure how to address tsoome's concerns, though, since they are
rather fundamental to the other work, so I can't fix that on the way in.
So it isn't quite as harsh as I think my original message sounds.

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

On Wed, Feb 7, 2018 at 8:54 AM, Warner Losh <[hidden email]> 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 <[hidden email]>
> 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
>> > _______________________________________________
>> > [hidden email] mailing list
>> > https://lists.freebsd.org/mailman/listinfo/freebsd-arch
>> > To unsubscribe, send any mail to "[hidden email]"
>> >
>> _______________________________________________
>> [hidden email] mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
>> To unsubscribe, send any mail to "[hidden email]"
>>
>
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Feedback on proposed loader changes

Julian Elischer-5
In reply to this post by Warner Losh
On 2/2/18 1:59 am, Warner Losh wrote:

> On Thu, Feb 1, 2018 at 9:58 AM, Devin Teske <[hidden email]> wrote:
>
>>
>>> On Feb 1, 2018, at 1:51 AM, Poul-Henning Kamp <[hidden email]>
>> wrote:
>>> --------
>>> In message <CANCZdfoF4M1k=wOzueg0KQk9tRoQT-hO0SrB51wxv=-
>> [hidden email]>, Warner Losh writes:
>>>> 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?
>>> I think you should just move forward and go for the end-stage
>>> without too many temporary bandaids.
>>>
>>> The loader is pretty decoupled from everything, so in case anybody
>>> needs any of these Forth cornercases, they can use 11.X loader with
>>> very little, if any, trouble.
>>>
>> As a person that both reviewed the GSoC code you are working with
>> (in-depth; including a list of short-comings) and the most likely person to
>> bring it up-to-par after it is committed, I have 2 opinions:
>>
>> 1. Please allow both boot systems for a while so that the lua-based menu
>> can be made as feature full as the Forth menu. Example: submenus were added
>> in Forth long after the GSoC lua project had ended
>>
> OK. The plan outlined does that. The lua code will be installed into /boot.
> But it will be .lua, so no conflicts with .4th. And we start from
> loader.lua not loader.rc.
>
>
>> 2. Please don’t force us to run Lua until I can code the new features
>>
> OK
>
>
>> And as the principal author of the Forth menu since 9.0:
>>
>> 3. Please give me a way to run my code (at the very least until I can
>> bring the Lua up to snuff; and if I can’t just let me run Forth
>> in-perpetuity).
>>
>> Interrupting boot1 so I can drive the system in the pre-boot Execution env
>> is very important to me.
>
> For !EFI, this is relatively easy. boot1 you can type /boot/loader_forth
> instead of the default /boot/loader if the symlink changes and you want to
> go back.
>
> For EFI the answer is more complicated. boot1.efi is going away, so
> loader.efi will move to the ESP in \efi\freebsd\loader.efi, but it's easy
> enough to have multiple versions there (loader_lua.efi and
> loader_forth.efi) and select via EFI Shell or EFI Env variables which one
> you want should you need to fall back.
so, there are multiple loaders.   zfsloader and loader for example.
how does this fit into the picture you are drawing? a symlink for each?


>
> Does that answer your concerns?
>
> Warner
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "[hidden email]"
>
>

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Feedback on proposed loader changes

Eric McCorkle-2
In reply to this post by Warner Losh
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 <[hidden email]> 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 <[hidden email]>
>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
>> > _______________________________________________
>> > [hidden email] mailing list
>> > https://lists.freebsd.org/mailman/listinfo/freebsd-arch
>> > To unsubscribe, send any mail to
>"[hidden email]"
>> >
>> _______________________________________________
>> [hidden email] mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
>> To unsubscribe, send any mail to
>"[hidden email]"
>>

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Feedback on proposed loader changes

Julian Elischer-5
In reply to this post by Warner Losh
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..



_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Feedback on proposed loader changes

Eric McCorkle-2
The keybuf system also needs a man page (that's on me as it was my invention).

On February 7, 2018 11:30:53 AM EST, Julian Elischer <[hidden email]> wrote:

>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..

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Feedback on proposed loader changes

Warner Losh
In reply to this post by Julian Elischer-5
On Wed, Feb 7, 2018 at 9:22 AM, Julian Elischer <[hidden email]> wrote:

> On 2/2/18 1:59 am, Warner Losh wrote:
>
>> On Thu, Feb 1, 2018 at 9:58 AM, Devin Teske <[hidden email]> wrote:
>>
>>
>>> On Feb 1, 2018, at 1:51 AM, Poul-Henning Kamp <[hidden email]>
>>>>
>>> wrote:
>>>
>>>> --------
>>>> In message <CANCZdfoF4M1k=wOzueg0KQk9tRoQT-hO0SrB51wxv=-
>>>>
>>> [hidden email]>, Warner Losh writes:
>>>
>>>> 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?
>>>>>
>>>> I think you should just move forward and go for the end-stage
>>>> without too many temporary bandaids.
>>>>
>>>> The loader is pretty decoupled from everything, so in case anybody
>>>> needs any of these Forth cornercases, they can use 11.X loader with
>>>> very little, if any, trouble.
>>>>
>>>> As a person that both reviewed the GSoC code you are working with
>>> (in-depth; including a list of short-comings) and the most likely person
>>> to
>>> bring it up-to-par after it is committed, I have 2 opinions:
>>>
>>> 1. Please allow both boot systems for a while so that the lua-based menu
>>> can be made as feature full as the Forth menu. Example: submenus were
>>> added
>>> in Forth long after the GSoC lua project had ended
>>>
>>> OK. The plan outlined does that. The lua code will be installed into
>> /boot.
>> But it will be .lua, so no conflicts with .4th. And we start from
>> loader.lua not loader.rc.
>>
>>
>> 2. Please don’t force us to run Lua until I can code the new features
>>>
>>> OK
>>
>>
>> And as the principal author of the Forth menu since 9.0:
>>>
>>> 3. Please give me a way to run my code (at the very least until I can
>>> bring the Lua up to snuff; and if I can’t just let me run Forth
>>> in-perpetuity).
>>>
>>> Interrupting boot1 so I can drive the system in the pre-boot Execution
>>> env
>>> is very important to me.
>>>
>>
>> For !EFI, this is relatively easy. boot1 you can type /boot/loader_forth
>> instead of the default /boot/loader if the symlink changes and you want to
>> go back.
>>
>> For EFI the answer is more complicated. boot1.efi is going away, so
>> loader.efi will move to the ESP in \efi\freebsd\loader.efi, but it's easy
>> enough to have multiple versions there (loader_lua.efi and
>> loader_forth.efi) and select via EFI Shell or EFI Env variables which one
>> you want should you need to fall back.
>>
> so, there are multiple loaders.   zfsloader and loader for example.
> how does this fit into the picture you are drawing? a symlink for each?
>

That's my plan. Of course, we shouldn't have a separate zfsloader and
loader, but due to other limitaitons we do. At least we don't have a
zfsloader.efi.

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Feedback on proposed loader changes

Ed Maste-2
In reply to this post by Devin Teske
On 1 February 2018 at 11:58, Devin Teske <[hidden email]> wrote:
>
> 1. Please allow both boot systems for a while so that the lua-based menu can be made as feature full as the Forth menu.

Zak, my co-op student from last term did a bunch of this work; it's in
the lua-bootloader branch of https://github.com/ZakSN/freebsd. The
work term ended before Warner's rework was ready, but it should be
relatively straightforward to rebase it and begin review / refinement.

I agree we should support both variants for at least some time.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Feedback on proposed loader changes

Warner Losh
On Wed, Feb 7, 2018 at 7:04 PM, Ed Maste <[hidden email]> wrote:

> On 1 February 2018 at 11:58, Devin Teske <[hidden email]> wrote:
> >
> > 1. Please allow both boot systems for a while so that the lua-based menu
> can be made as feature full as the Forth menu.
>
> Zak, my co-op student from last term did a bunch of this work; it's in
> the lua-bootloader branch of https://github.com/ZakSN/freebsd. The
> work term ended before Warner's rework was ready, but it should be
> relatively straightforward to rebase it and begin review / refinement.
>

I haven't changed the .lua code at all yet from what was in the github
branch that Rui did to forward port the GSoC svn branch. I have plans for a
lot of changes (since it's lame to call perform to call setenv when we can
just directly do a setenv function call, for example).

This code looks to be mergeable, so I'll do that as a separate commit. The
non-lua bits I have to pick and choose, since there's some conflicts
though...


> I agree we should support both variants for at least some time.
>

Forth will be in 12, but not 13 is my plan. Lua will be in 12 and the
default. And thanks to Kyle Evans' heroic MFCs, there's a fighting chance
lua will be an off-by-default option in 11.2.

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Feedback on proposed loader changes

Baptiste Daroussin-2
On Wed, Feb 07, 2018 at 10:42:45PM -0700, Warner Losh wrote:

> On Wed, Feb 7, 2018 at 7:04 PM, Ed Maste <[hidden email]> wrote:
>
> > On 1 February 2018 at 11:58, Devin Teske <[hidden email]> wrote:
> > >
> > > 1. Please allow both boot systems for a while so that the lua-based menu
> > can be made as feature full as the Forth menu.
> >
> > Zak, my co-op student from last term did a bunch of this work; it's in
> > the lua-bootloader branch of https://github.com/ZakSN/freebsd. The
> > work term ended before Warner's rework was ready, but it should be
> > relatively straightforward to rebase it and begin review / refinement.
> >
>
> I haven't changed the .lua code at all yet from what was in the github
> branch that Rui did to forward port the GSoC svn branch. I have plans for a
> lot of changes (since it's lame to call perform to call setenv when we can
> just directly do a setenv function call, for example).
>
> This code looks to be mergeable, so I'll do that as a separate commit. The
> non-lua bits I have to pick and choose, since there's some conflicts
> though...
>
>
> > I agree we should support both variants for at least some time.
> >
>
> Forth will be in 12, but not 13 is my plan. Lua will be in 12 and the
> default. And thanks to Kyle Evans' heroic MFCs, there's a fighting chance
> lua will be an off-by-default option in 11.2.
>
I just want to say thank you to both of you!!! Can wait to be able to use lua
there!

Best regards,
Bapt

signature.asc (849 bytes) Download Attachment