New Boot Loader Menu

[Devin Teske]

On Oct 7, 2012, at 12:23 PM, Doug Barton wrote:

> On 10/06/2012 16:48, Devin Teske wrote:
> 
>> 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.
> 
> It's generally a good idea to ask for feedback before spending this
> amount of time on something.

I will agree that _generally_ it's a good idea, but in my case feedback makes no difference with respect to how much effort I put into something like this.

The reason being that these features, if not taken into FreeBSD, will simply live on happily in DruidBSD.

The boot loader menu that is currently used in FreeBSD HEAD, CURRENT, and RELENG_9 in-fact was used in DruidBSD for nearly 7 years before it was imported to FreeBSD.



> Coming to the community and saying, "I
> spent so much time on this, you have to accept it" doesn't fly.
> 

I reject your proposed hypothesis that this was my intent (the proper intent is described below).


> 	"But that's not why I mentioned how many hours I spent."
> 	"So why mention it at all?" :)
> 

My precise intent for mentioning this was for the other Forth and/or boot-menu folks (not the casual person).

I didn't want the other Forth hackers to get excited and perhaps form the markedly false impressions that either:

a. the current code allows for submenus
b. that submenus were easy to add
c. that shoving the boot options into a submenu is something that can be done with a "1 line commit"

Rather, I sought to set the stage that if the proposed "end result" is desirable, it would give me impetus to continue working in that direction (which is a tiny fork in the end of a long road of committing ~1000 lines of requisite enhancements).

By providing the information I did at the end, I was not stating "I worked hard on this, you must accept it," but rather I was stating "here's something nice, if you want it I'm prepared to make it happen and this is what you can expect to be committed as-described by said effort."

I did not perceive that anybody would construe my statement-of-effort as anything other than being totally up-front about what went into the final proposed-product versus trying to be sneaky and pull a "bait and switch" (something I definitely would have perceived if somebody _didn't_ itemize the effort that went into something that *looked* simple or *sounded* easy).



>> 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).
> 
> Others have already brought up their favorite items to keep at the top
> level, I think it would be much simpler to leave everything that is at
> the top level now, and make submenus option number 8.

What name would you give this "all submenus" menu item? Because, as previously discussed, if the menu stays as-is, we can really only have one more item and so said-new-item would have to be an "all submenus" option. Somehow, I don't think jpaetzel, avg, and mav are going to like this as a solution for their proposed-new "BE menu" (having "8. Submenus" -> "2. BE Submenu" -> "Select a BE" just seems too deep-a-traversal).



> Bonus points if
> you can make it easy to add a submenu via loader.conf.
> 

Done. There's zero difference in configuring menus in a "menu.rc" file than in "loader.conf" file.

Menus (and submenus alike) are configured via appropriately named environment variables. How these environment variables get set is entirely up to the clients of my framework. You can set them via menu.rc, loader.conf, in the C layer (e.g., sys/boot/ficl/loader.c), or the Forth layer. It makes no difference. However, I implore everybody to stay away from the Forth layer because adding massive amounts of static text to that layer can *quickly* cause dictionary overflow which leads to immediate and fatal BTX halt. Setting the environment variables in menu.rc, loader.conf, or the C layer doesn't suffer from the limitations of the FICL dictionary size (and bumping the dictionary size is not always the right solution).



> Regarding the UI on your submenu example; never, ever, ever use
> Backspace to mean anything other than "delete the character behind the
> cursor."

Seriously? Who made _that_ rule? and moreover, _WHY_?

My reasoning… you want to be able to account for non-responsive systems in which case the user jams on a given key because they don't get a screen-update right-away. In this case, what's the harm in jamming on Backspace? Even if they somehow drop to an interactive prompt and are still jamming Backspace, what's the harm?

I don't understand this out-of-the-blue axiom.

Can you or someone explain its origins and or enlighten me to the edge-case that led to its creation? I'l in-turn become one a staunch follower, I just want to know the pathos behind it.


> Unfortunately you cannot use 'B' or Escape here either since
> they have meaning in the previous menu.

Right-o


> 'Left Arrow' is likely the best
> choice, although Home or even 'Page Up' would be better than Backspace.
> 

Hmmm, I find myself wishing that there could be multiple keycodes associated with a given menuitem, but at this time there's really only one keycode that can be set (without further enhancement).

I'll try playing around, but I'm afraid that backspace just felt so "right" that my hands won't want to do anything else.

I can tell you from playing around with submenus for quite awhile, that it's sometimes annoying (until you get the repetition down) having to hunt for the key to "take me back" (and backspace just seemed "right" as the key to "take me back" no matter where I am). It also seemed to play well because I was logically perceiving a traversal to the right into the submenu, and (perhaps this is strictly because I am a native English speaker that types left-to-right), backspace was the logical correct thing to take me back "to the left" just as it does when typing.
-- 
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.