[UPDATE] New Boot-Loader Menu -- version 1.1

[Olivier Smedts]

2011/5/3 Devin Teske <dteske at vicor.com>:
>> The previous loader behavior when an unknown key was pressed was to reset
>> the delay to the autoboot_delay value.
>
> I wasn't aware of that functionality (I'd always pressed SPACE to pause the
> timer).
>
> Maybe a dumb question, but why would anybody want to reset the timer? I can't
> think of a single scenario where I'd prefer a timer to be reset on keypress
> opposed to just stopping. I'm of the school of thought that there are only three
> reasonable scenarios where you'd want to abate auto-boot (listed below), all of
> which involve more time than just "another 10 seconds" gained by resetting the
> timer:
>
> 1. Slow readers (of which I am guilty of)
> 2. People that just want to bask in the glory of the boot-loader (also guilty)
> 3. Hackers that want to rewrite rogue(6) in FICL for the boot-loader (work in
> progress?)

It surprised me and this loader booted the system while I didn't want, because :
- I was accustomed of the previous behavior
- I only had a 3 seconds delay to boot (I press a key when I want a
longer delay, to read or find a key)
- I wanted to see the new loader (you can count this as "slow readers")
- I don't have a qwerty keyboard, so finding the right keys for the
loader can take some time

> Is this a serious concern (removing the "reset timer on unknown key"
> functionality)?
>
>> And it also worked with, for examble, the
>> arrow keys. I appreciated it, like I appreciate your "Space to pause" !
>
> Arrow keys are funny. They produce a zero value by the "key" function, so
> detecting them is ... impossible.
>
> However, I was able to correct this behavior. Version 1.2 (just released right
> now) will cancel the timeout on ANY keypress, including keys that produce NULL
> keycodes (such as arrows, navigational keys, command sequences, and special key
> combinations).

OK, I'll test it, now the behavior is more like the previous loader,
or grub. It's ok (for me) not to reset the timer if at least it stops
on all keys !

>> Do you know why this loader displays "ACPI Support: Disabled" on my 9-CURRENT
>> amd64 computer when it really seems to be enabled ? Note acpi.ko is not
> loaded,
>> it's in the GENERIC kernel.
>
> The previous version (1.0) had a hard-coded "set acpi_load=YES" in
> /boot/menu-commands.4th. This has been removed in favor of dynamically detecting
> "acpi_load" at boot time.
>
> This version (1.1) works nearly identically to the standard menu that ships with
> FreeBSD in that it detects whether ACPI is enabled (truth be told, I actually
> re-used the "acpienabled?" function verbatim from /boot/beastie.4th by Scott
> Long and Aleksander Fafula). The ACPI detection of my boot loader (version 1.1
> or higher) should be identical to the detection of the current boot-loader.
>
> I would be willing to bet that your workstation -- while running the default
> boot loader -- displays "Boot FreeBSD with ACPI enabled" for option #2
> (indicating that ACPI appears to be disabled from your system's perspective).

No, it displays "Boot FreeBSD with ACPI disabled". I didn't know this
text was dynamic, are you sure it's not hard-coded ?
I can provide screenshots of both loaders.

> As far as I know, the loader does not know that ACPI is compiled into your
> kernel. Rather the ACPI menuitem (both in the default boot-loader menu and in my
> version 1.1) hinges on whether "acpi_load" is defined (and is enabled).
>
> On a side-note, the same exact code is displaying ACPI as enabled for me
> (running under Parallels 4 on Mac OS X 10.6.7) at boot time. Yet, I do not have
> acpi_load in loader.conf(5), though I do have a kernel with ACPI built-in. My
> guess is that loader(8) is setting load_acpi="YES", which I verify immediately
> after executing loader(8) and the loader.4th start-word (which reads
> loader.conf(5) among other things).
>
>> > loader_menu_timeout="N"
>> >
>> >        Timeout in seconds (N) until the menu aborts, causing the
>> > system to
>> >        autoboot with the displayed options. Default is 10 seconds.
>> > Pressing
>> >        any key during the duration will cancel the timeout.
>>
>> Could you add a compatibility shim for the actual autoboot_delay variable ?
>
> I've decided to simply do-away with loader_menu_timeout and have it simply use
> autoboot_delay. This is effective as of version 1.2 (released today).
>
>> > dc_seconds="N"
>> >
>> >        By default, loader_menu introduces a 2-second delay before
>> > launching
>> >        the menu for improved debugging abilities. This option
>> > customizes the
>> >        duration (setting it to zero disables the delay). However, it
>> > is worth
>> >        noting that pressing ENTER anytime during the delay will
>> > preempt the
>> >        duration, launching the menu immediately upon keypress.
>>
>> For consistency with all the logo_* variables, what would you think of using
>> something like loader_delay instead of dc_seconds ? (and yes, I know,
>> autoboot_delay doesn't begin with "loader_", but it was there before ;)
>
> I agree, however this will require a rewrite of that module. I'll try to get to
> that later this week.

Thanks again, I'll test 1.2 version in a few hours :)

-- 
Olivier Smedts                                                 _
                                        ASCII ribbon campaign ( )
e-mail: olivier at gid0.org        - against HTML email & vCards  X
www: http://www.gid0.org    - against proprietary attachments / \

  "Il y a seulement 10 sortes de gens dans le monde :
  ceux qui comprennent le binaire,
  et ceux qui ne le comprennent pas."