From owner-freebsd-hackers@FreeBSD.ORG Tue May 3 08:15:22 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E924B1065670 for ; Tue, 3 May 2011 08:15:22 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id C80618FC23 for ; Tue, 3 May 2011 08:15:22 +0000 (UTC) Received: by pzk27 with SMTP id 27so4457993pzk.13 for ; Tue, 03 May 2011 01:15:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.14.37 with SMTP id m5mr1719800pbc.474.1304410522235; Tue, 03 May 2011 01:15:22 -0700 (PDT) Received: by 10.68.40.4 with HTTP; Tue, 3 May 2011 01:15:22 -0700 (PDT) In-Reply-To: <013201cc092b$d3c7c470$7b574d50$@vicor.com> References: <9B387DE4-6866-4208-A8FC-6516D651F6A5@vicor.com> <013201cc092b$d3c7c470$7b574d50$@vicor.com> Date: Tue, 3 May 2011 10:15:22 +0200 Message-ID: From: Olivier Smedts To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 08:15:23 -0000 2011/5/3 Devin Teske : >> The previous loader behavior when an unknown key was pressed was to rese= t >> the delay to the autoboot_delay value. > > I wasn't aware of that functionality (I'd always pressed SPACE to pause t= he > timer). > > Maybe a dumb question, but why would anybody want to reset the timer? I c= an't > think of a single scenario where I'd prefer a timer to be reset on keypre= ss > opposed to just stopping. I'm of the school of thought that there are onl= y 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 resettin= g 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 gu= ilty) > 3. Hackers that want to rewrite rogue(6) in FICL for the boot-loader (wor= k in > progress?) It surprised me and this loader booted the system while I didn't want, beca= use : - 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 speci= al 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-CU= RRENT >> 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=3DYES" in > /boot/menu-commands.4th. This has been removed in favor of dynamically de= tecting > "acpi_load" at boot time. > > This version (1.1) works nearly identically to the standard menu that shi= ps with > FreeBSD in that it detects whether ACPI is enabled (truth be told, I actu= ally > re-used the "acpienabled?" function verbatim from /boot/beastie.4th by Sc= ott > Long and Aleksander Fafula). The ACPI detection of my boot loader (versio= n 1.1 > or higher) should be identical to the detection of the current boot-loade= r. > > I would be willing to bet that your workstation -- while running the defa= ult > boot loader -- displays "Boot FreeBSD with ACPI enabled" for option #2 > (indicating that ACPI appears to be disabled from your system's perspecti= ve). 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 you= r > kernel. Rather the ACPI menuitem (both in the default boot-loader menu an= d 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 no= t 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=3D"YES", which I verify imme= diately > after executing loader(8) and the loader.4th start-word (which reads > loader.conf(5) among other things). > >> > loader_menu_timeout=3D"N" >> > >> > =A0 =A0 =A0 =A0Timeout in seconds (N) until the menu aborts, causing t= he >> > system to >> > =A0 =A0 =A0 =A0autoboot with the displayed options. Default is 10 seco= nds. >> > Pressing >> > =A0 =A0 =A0 =A0any key during the duration will cancel the timeout. >> >> Could you add a compatibility shim for the actual autoboot_delay variabl= e ? > > I've decided to simply do-away with loader_menu_timeout and have it simpl= y use > autoboot_delay. This is effective as of version 1.2 (released today). > >> > dc_seconds=3D"N" >> > >> > =A0 =A0 =A0 =A0By default, loader_menu introduces a 2-second delay bef= ore >> > launching >> > =A0 =A0 =A0 =A0the menu for improved debugging abilities. This option >> > customizes the >> > =A0 =A0 =A0 =A0duration (setting it to zero disables the delay). Howev= er, it >> > is worth >> > =A0 =A0 =A0 =A0noting that pressing ENTER anytime during the delay wil= l >> > preempt the >> > =A0 =A0 =A0 =A0duration, launching the menu immediately upon keypress. >> >> For consistency with all the logo_* variables, what would you think of u= sing >> 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 :) --=20 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas."