New Boot Loader Menu

Sun Oct 7 18:33:22 UTC 2012

On Oct 7, 2012, at 8:53 AM, Garrett Cooper wrote:

> On Sat, Oct 6, 2012 at 4:48 PM, Devin Teske <devin.teske at fisglobal.com> wrote:
>> Hello,
>> 
>> I've been working on a new boot loader menu system.
>> 
>> This is what is in HEAD, CURRENT, and RELENG_9 at the moment:
>> 
>> http://twitpic.com/b1pkll/full
>> in color: http://twitpic.com/b1pkz1/full
>> 
>> I'd like to propose the following replacement to the above:
>> 
>> http://twitpic.com/b1pll5/full
>> in color: http://twitpic.com/b1plxi/full
>> 
>> The boot options have been whisked away into a sub-menu (see below):
>> 
>> http://twitpic.com/b1pm51/full
>> in color: http://twitpic.com/b1pme8/full
>> 
>> What does everybody think?
> 
> A few things:
> 1. It makes things cleaner for humans who want to get essential tasks
> done,

My original thought was: *this* is going to finally allow us to accommodate the additional menu items that iX is planning (like BE integration).

But (similar to the "make things cleaner" thought), my second thought was:
*this* is going to finally get those field engineers to stop asking me "should I change anything on this menu" and if it doesn't, at least now I can say "don't change anything in the options *menu*" (more clear separation of "action items" versus [possibly] vestigial protuberances that should be ignored by the casual observer).

I think we often forget that *everybody* that boots FreeBSD (be it the "field engineer", the "programmer", the "sys admin", or even -- and this is the kicker -- the "remote controlled non-techie sitting on the phone with a techie trying to help solve a problem only because he's the only warm body in the remote site which unfortunately has lost access" person) see this menu. It's that mindset that makes me think that "less is more" and "clear separation so we can say ``don't touch that menu'' versus ``don't touch those 4 items''" is a win, not a loss.

> but it also makes it a little bit harder for automation to "dive
> down" into the next level and test stuff (unless OFC the beastie menu
> was completely bypassed, which might be something that I need to do in
> the future for automation as the bootloader prompt never really
> changes).

Well, if you were automating things, I would hope that you were setting things in loader.conf(5), not relying on a written procedure.

That is to say that, setting boot_verbose="YES" in loader.conf(5) is a better way of automating verbose-booting opposed to requiring someone to hit "v" before booting each time. The effect of these settings (in loader.conf(5)) is not proposed to change -- they would work the same regardless of whether the menu item is in the main menu or a submenu.

Last, but not least, the written procedure would only change slightly. If you want to boot into single-user mode, for example, currently you'd press "s" then "ENTER". With the menu item moved to a submenu, you'd instead press "o" then "s" then ENTER. What's worth noting is that "ENTER" will work on any menu or submenu to boot. There would be no need to go back to the main menu to boot (you can boot directly from the options submenu).

> 2. This makes it harder for people rolling custom patches on the
> bootloader to continue using them, but I suppose porting is "all in a
> day's work", right :)?

How so?

Isn't that true _anytime_ patches are made?

Actually, I've made very little changes to everything that is currently there with the exception of the massive/new "menusets.4th"

What's worth noting about these enhancements are they are only additive in nature. No functionality was removed, only added _and_ existing menu.rc setups will continue to work.

When I give my live demo this coming Thursday at BAFUG, I'll be demonstrating how the existing menu.rc in HEAD can be used with zero changes to the Forth code; then demonstrate 3 _new_ menu.rc files which successively demonstrate more features with more complex setups (but again with zero changes to the Forth code). This shows retention of backward compatibility.

I'll remind the community that the major goal of these enhancements (starting with the enhancements I made 16+ months ago) were to alleviate the need to continually be changing the Forth code. That instead of always implementing new Forth code, that changes in functionality (even additions of new menus) could be done by merely setting a collection of precisely-named environment variables (which can be done in the POSIX C layer, a simple *.rc file, or even loader.conf(5) -- but no Forth modifications). These enhancements follow the same line of thinking and make it even more likely that (if people accept these patches into their own custom distributions down-stream from FreeBSD) patches are less necessary.

> 3. There isn't really a limit on how much the submenus could or should
> grow;

Right now, I've programmed in an upper limit of 65535 possible submenus. Each submenu can have up to 9 maximum (tho we like to keep it at 8 for multiple reasons) menu items. Each of those menu items can be a static-type, toggle type, cycle type, or submenu type (meaning there is a common infrastructure for these types; you can do anything you want for a menu item by creating any call-back you desire and said call-back can be provided either by the Forth layer or the POSIX C layer).

> oh, and Forth can be a black art of sorts.
> 

Yes, it can. That's why I've been working hard on getting call-back systems functioning properly so folks like avg and mav can have fully dynamic menus driven by C-based call-backs (with zero Forth work).

> Even though I can see its merits, I do see where des@ is coming from.
> It's good to see some discussion before commit, but I think it
> deserves a bit more thought and some rough sketches to come up with a
> solid (or at least squishy) plan on how to proceed.
> 

agreed.

>> NOTE: This change is not trivial. It took me nearly a month of hacking to produce this _and_ almost 1,000 changed lines of code are required. Features such as submenus, dynamic menus and menu items, and more were added and I'm at a point where I can commit this back to the tree. I'm sure we want these features, but we have a choice of keeping the menu as-is without any changes _or_ we can choose to use the new features (as exhibited in this proposal -- where the boot options are sidled-off into a submenu).
> 
> That might be harder to work with. sysinstall was usable to a point,
> but then it got unusable after a period of time because of the way
> libdialog was changed, and then unfortunately it was abandoned after a
> while. We'd rather avoid those usability "mistakes" in the future if
> at all possible.
> 

I think you misunderstand. When I say that we have a choice to not make any changes, what I meant was that after all the enhancements are in, there's nothing forcing us to use them. That everything is backward compatible and that the existing menu.rc does not have to change (tho a quick note about that below).

Tho the infrastructure is not losing any functionality, we ought to at least use the new "dynamic menuitem" constructors to fix a bug that currently plagues HEAD -- the fact that setting boot_verbose="YES" (as just one example) in loader.conf(5) will not be reflected in the main boot menu. At the very least, we should use the dynamic initialization feature to fix that bug even if we don't end up pushing the options to a submenu.

> As always, as usable, simple, and maintainable as possible is what we
> should shoot for in the project. if it makes sense, things maybe
> should be split up into separate menus with a common boilerplate
> *shrugs*.
> 

Usable, simple, maintainable _and_ easily extendable was what I was shooting for. I understand a lot of people don't hack on the Forth code -- I've been having fun and excitement with it for over 8 years, but alas I understand a lot of people aren't excited-by or have-fun with it. So I've tried to push all the functionality into the other layers where people are adeptly skilled and there is no shortage of programmers (namely the C and config spaces).

Oh, and with respect to the "boilerplate" comment: that's actually possible. Menus (or submenus) can be wholly static, wholly dynamic, or any percentage thereof. In one demo I'll be giving this Thursday (BAFUG), the root-device selection menu has one static menu item and many dynamically-generated menu items. So this is something that is definitely do-able if we want.

>> P.S. The hope is to one day utilize _all_ of the features I'm adding to one day have something like this (a functioning mock-up, but unfinished currently): http://twitter.com/devinteske/status/254419042104909824
> 
> Hmmm…
> 

You'll have to talk to mav and jpaetzel about their plans for the "BE submenu" -- I hope to pick some brains this Thursday at BAFUG to see what it might look like, how it might function, etc. but right now I don't know how they are going to use my new menuing infrastructure. What I posted was just a mock-up of what I think might be useful (filtering on type and having a menu for setting vfs.root.mountfrom based on lsdev/lszfs output).
-- 
Cheers,
Devin

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