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

Tue May 3 00:48:27 UTC 2011

UPDATE: New version 1.2 released right now.
Get your update at:
	http://druidbsd.sourceforge.net/
		or
	http://druidbsd.sourceforge.net/download/loader_menu-1.2.tgz

Keep reading for details/discussion below.

> -----Original Message-----
> From: Olivier Smedts [mailto:olivier at gid0.org]
> Sent: Monday, May 02, 2011 2:25 PM
> To: Devin Teske
> Cc: FreeBSD Hackers; mwm at mired.org; Mike at freebsd.org;
> Meyer at freebsd.org; Warner at freebsd.org; Losh at freebsd.org;
> Freddie at freebsd.org; Cash at freebsd.org; Alexander at freebsd.org;
> Leidinger at freebsd.org; Olivier at freebsd.org; SMEDTS at freebsd.org;
> Warren at freebsd.org; Block at freebsd.org; Doug at freebsd.org;
> Barton at freebsd.org; Artem at freebsd.org; Belevich at freebsd.org;
> Dieter at freebsd.org; BSD at freebsd.org; Jason at freebsd.org;
> Hellenthal at freebsd.org; Devin at freebsd.org; Teske at freebsd.org;
> Damien at freebsd.org; Fleuriot at freebsd.org; Zhihao at freebsd.org;
> Yuan at freebsd.org; Paul at freebsd.org; Schenkeveld at freebsd.org;
> Mehmet at freebsd.org; Erol at freebsd.org; Sanliturk at freebsd.org;
> Dave at freebsd.org; Robison at freebsd.org
> Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1
> 
> 2011/5/2 Devin Teske <dteske at vicor.com>:
> > NOTE: Apologies if this comes through multiple times. I'm having problems
> getting this e-mail to appear on the list.
> >
> > Hi again, fellow hackers,
> >
> > First, I'd like to thank all of you for the input and suggestions that you
provided.
> >
> > Things are moving fast and nimble here. With over 1,000 lines of code
changed
> (in one single 24-hour period), I'd like to announce an update to my advanced
> boot-loader menu. This version (1.1) attempts to address all community
> requests.
> >
> > You can grab the updated code here:
> > http://druidbsd.sourceforge.net/
> >        or
> > http://druidbsd.sourceforge.net/download/loader_menu-1.1.tgz
> 
> Using it right now. Great :)

^_^

> What would you think of using the "bw" variant of a logo when
> loader_color="NO" ?
> Oh forget that, I tried without a loader_logo setting, and it seems to be the
case
> with the default orb. It was only strange with my previous setting of
> loader_logo="beastie", without the new "loader_color"
> setting.

Right. I wanted it to function so that if you explicitly set loader_logo, that
it would override the use of loader_color. If you don't set loader_logo, then
playing with loader_color will automatically switch from orbbw to orb, whereas
if you set it to something like "beastie", you'll get that logo regardless of
what loader_color is set to.

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

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

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

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

> Many thanks !
> 
> --
> 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."

_____________

The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
_____________