Re: ACPI panic on boot with new Lua loader and other minor issues

On Feb 19, 2018 3:38 PM, "Kyle Evans" <kevans_at_freebsd.org> wrote:

On Mon, Feb 19, 2018 at 4:32 PM, Warner Losh <imp_at_bsdimp.com> wrote:
>
>
> On Mon, Feb 19, 2018 at 2:57 PM, Devin Teske <dteske_at_freebsd.org> wrote:
>>
>>
>>
>> > On Feb 19, 2018, at 2:21 PM, Kyle Evans <kevans_at_freebsd.org> wrote:
>> >
>> > It seems that the Forth loader might be doing something sneaky and
>> > replacing the standard common "boot" with a Forth boot that handles
>> > this a lot better. CC'ing dteske_at_ so they can confirm.
>>
>> I can indeed confirm this as fact.
>>
>> Not able to help much because I am driving cross-country (San Francisco
to
>> Orlando) right now with the spouse and dog.
>>
>> We get back March 3rd, but I will be checking-in from time to time for
>> sporadic responses during downtime.
>
>
> The command in loader.4th is defined as:
>
> : boot
>   0= if ( interpreted ) get_arguments then
>
>   \ Unload only if a path was passed
>   dup if
>     >r over r> swap
>     c_at_ [char] - <> if
>       0 1 unload drop
>     else
>       s" kernelname" getenv? if ( a kernel has been loaded )
>         try-menu-unset
>         bootmsg 1 boot exit
>       then
>       load_kernel_and_modules
>       ?dup if exit then
>       try-menu-unset
>       bootmsg 0 1 boot exit
>     then
>   else
>     s" kernelname" getenv? if ( a kernel has been loaded )
>       try-menu-unset
>       bootmsg 1 boot exit
>     then
>     load_kernel_and_modules
>     ?dup if exit then
>     try-menu-unset
>     bootmsg 0 1 boot exit
>   then
>   load_kernel_and_modules
>   ?dup 0= if bootmsg 0 1 boot then
> ;
>
> The thing to know here is when you see 'boot' as part of above script,
it's
> calling the 'boot' cli command, not itself recursively.
>
> I can help do more interpretation of the details if you need Kyle. Not
sure
> how much to spell out, but the brief pseudo code is:
>
> If there were any arguments that didn't start with '-', unload.
>   otherwise if kernelname is in in the environment, run the 'menu-unset'
> forth word if it exists, print the boot message and boot.
>   Otherwise load the kernel and modules, run the 'menu-unset' forth word
(if
> it exists), print the boot message and boot with kernelname
> Otherwise load the kernel and modules, run the 'menu-unset' forth word (if
> it exists), print the boot message and boot with kernelname
> if all that fails, load the kernel and modules and if that works boot
them.
>

Yeah, we have something like this on the lua side. Unfortunately, it's
going to wreck people's muscle memory- dropping to the loader prompt
and typing "boot [x]" will never work as expected because lua won't
recognize that as a function call due to spaces as delimiters.

We'd need some shim that takes "cmd [x]" and tries it as "cmd([x])"
(for some [x] that could be multiple space-delimited arguments) before
falling back to the originally typed "cmd [x]" if we want Lua to have
any chance to intercept it and adds its own salt and pepper like Forth
does.


Forth has a framework for making all commands forth words. It leverages
that to run the intercept. We already have the intercept in place with a
stupidly simple policy. We totally can do something generic that would
solve this and maybe other problems. Let's chat online tomorrow about a
couple of possibilities we can choose from.

Warner