Date: Mon, 2 May 2011 17:48:31 -0700 From: "Devin Teske" <dteske@vicor.com> To: <freebsd-hackers@freebsd.org> Cc: Olivier SMEDTS <olivier@gid0.org> Subject: RE: [UPDATE] New Boot-Loader Menu -- version 1.1 Message-ID: <013201cc092b$d3c7c470$7b574d50$@vicor.com> In-Reply-To: <BANLkTinr42HAK4QoVKce8gp7oPQpQstBBQ@mail.gmail.com> References: <9B387DE4-6866-4208-A8FC-6516D651F6A5@vicor.com> <BANLkTinr42HAK4QoVKce8gp7oPQpQstBBQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@gid0.org] > Sent: Monday, May 02, 2011 2:25 PM > To: Devin Teske > Cc: FreeBSD Hackers; mwm@mired.org; Mike@freebsd.org; > Meyer@freebsd.org; Warner@freebsd.org; Losh@freebsd.org; > Freddie@freebsd.org; Cash@freebsd.org; Alexander@freebsd.org; > Leidinger@freebsd.org; Olivier@freebsd.org; SMEDTS@freebsd.org; > Warren@freebsd.org; Block@freebsd.org; Doug@freebsd.org; > Barton@freebsd.org; Artem@freebsd.org; Belevich@freebsd.org; > Dieter@freebsd.org; BSD@freebsd.org; Jason@freebsd.org; > Hellenthal@freebsd.org; Devin@freebsd.org; Teske@freebsd.org; > Damien@freebsd.org; Fleuriot@freebsd.org; Zhihao@freebsd.org; > Yuan@freebsd.org; Paul@freebsd.org; Schenkeveld@freebsd.org; > Mehmet@freebsd.org; Erol@freebsd.org; Sanliturk@freebsd.org; > Dave@freebsd.org; Robison@freebsd.org > Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1 >=20 > 2011/5/2 Devin Teske <dteske@vicor.com>: > > NOTE: Apologies if this comes through multiple times. I'm having proble= ms > 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 adva= nced > boot-loader menu. This version (1.1) attempts to address all community > requests. > > > > You can grab the updated code here: > > http://druidbsd.sourceforge.net/ > > =A0 =A0 =A0 =A0or > > http://druidbsd.sourceforge.net/download/loader_menu-1.1.tgz >=20 > Using it right now. Great :) ^_^ > What would you think of using the "bw" variant of a logo when > loader_color=3D"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=3D"beastie", without the new "loader_color" > setting. Right. I wanted it to function so that if you explicitly set loader_logo, t= hat it would override the use of loader_color. If you don't set loader_logo, th= en playing with loader_color will automatically switch from orbbw to orb, wher= eas 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), al= l 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 guil= ty) 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" ! >=20 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 ri= ght now) will cancel the timeout on ANY keypress, including keys that produce N= ULL 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-CUR= RENT > amd64 computer when it really seems to be enabled ? Note acpi.ko is not loaded, > it's in the GENERIC kernel. >=20 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 dete= cting "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 actual= ly 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=3D"YES", which I verify immedi= ately 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 the > > system to > > =A0 =A0 =A0 =A0autoboot with the displayed options. Default is 10 secon= ds. > > Pressing > > =A0 =A0 =A0 =A0any key during the duration will cancel the timeout. >=20 > 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=3D"N" > > > > =A0 =A0 =A0 =A0By default, loader_menu introduces a 2-second delay befo= re > > 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). Howeve= r, it > > is worth > > =A0 =A0 =A0 =A0noting that pressing ENTER anytime during the delay will > > preempt the > > =A0 =A0 =A0 =A0duration, launching the menu immediately upon keypress. >=20 > For consistency with all the logo_* variables, what would you think of us= ing > 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 ge= t to that later this week. -- Devin > Many thanks ! >=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 / \ >=20 > =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." _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. _____________
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?013201cc092b$d3c7c470$7b574d50$>