2011/5/3 Devin Teske <dte...@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: oliv...@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." _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"