Feedback on proposed loader changes
Warner Losh
imp at bsdimp.com
Wed Feb 7 16:40:03 UTC 2018
On Wed, Feb 7, 2018 at 9:22 AM, Julian Elischer <julian at freebsd.org> wrote:
> On 2/2/18 1:59 am, Warner Losh wrote:
>
>> On Thu, Feb 1, 2018 at 9:58 AM, Devin Teske <devin at shxd.cx> wrote:
>>
>>
>>> On Feb 1, 2018, at 1:51 AM, Poul-Henning Kamp <phk at phk.freebsd.dk>
>>>>
>>> wrote:
>>>
>>>> --------
>>>> In message <CANCZdfoF4M1k=wOzueg0KQk9tRoQT-hO0SrB51wxv=-
>>>>
>>> n3ESiUw at mail.gmail.com>, 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
More information about the freebsd-arch
mailing list