RE: revisiting tunables under Safe Mode menu option

> -----Original Message-----
> From: Scott Long [mailto:scottl_at_samsco.org]
> Sent: Thursday, March 01, 2012 9:13 AM
> To: Devin Teske
> Cc: 'Andriy Gapon'; 'John Baldwin'; freebsd-current_at_FreeBSD.org; 'Devin Teske'
> Subject: Re: revisiting tunables under Safe Mode menu option
> 
> 
> On Mar 1, 2012, at 9:52 AM, Devin Teske wrote:
> 
> >
> >
> >> -----Original Message-----
> >> From: Andriy Gapon [mailto:avg_at_FreeBSD.org]
> >> Sent: Thursday, March 01, 2012 12:39 AM
> >> To: Devin Teske
> >> Cc: John Baldwin; freebsd-current_at_FreeBSD.org; Scott Long; Devin Teske
> >> Subject: Re: revisiting tunables under Safe Mode menu option
> >>
> >> on 01/03/2012 03:34 Devin Teske said the following:
> >>>
> >>> +1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe
> >>> Mode knows about ACPI but only acts on it when being enabled).
> >>
> >> Can you explain why?
> >> +1 for having both menu items and each doing its own thing without any
> >> entanglement :-)
> >>
> >
> > First, I realize that this may sound entirely *dumb*, but here-goes:
> >
> > In transitioning from an old release (sans-menu; 4.11 for example) to a
newer
> > release (with menu; 6.x for example), one of the first thing that is noticed
is
> > "Safe Mode".
> >
> > I know that when I first saw this, I scratched my head and wondered what it
did
> > and what it might be useful for. To this day, I still have never used it.
> >
> 
> To be fair, I'm pretty sure that 'Safe Mode' was documented in one of the
> docbook manuals, though the FreeBSD project never, to my knowledge, had a
> "quick install/troubleshooting guide' that documented the loader menu.  The
> name was inspired by Windows, but if you aren't familiar with that side of the
> world, then I can see how the name would have diminished meaning.  So I
> understand where you're coming from.
> 
> I'd like to turn the discussion away from ACPI specifically.  What I'd like to
see
> improved is two things:
> 
> 1.  There are a number of knobs that can be manipulated to help enable a non-
> booting system boot, which in turn gives a system administrator a fighting
chance
> to figure out what's wrong.  ACPI is (or was) one of these options, but there
are
> several others, and up until your re-write of the menu system, they were
opaque
> to the user.  I'd like to explore the idea of having a sub-menu that exposes
these
> knobs and allows them to be individually controlled, but still have an
upper-level
> option that turns them all-on or all-off for ease of use.
> 
> 2.  There are a ton of kenv/TUNABLE knobs in any given kernel, and many of
> them are useful for sysadmins, even beyond just the 'safe mode' subset.  I'd
like
> to see a post-processor run on the kernel build that collects all of the kenv
knobs
> in that kernel and puts them into a file that can be read by the boot menu
> system.  The system then dynamically turns these into another sub-menu of
> knobs that can be manipulated.
> 
> So, how hard would it be to have nested sub-menus?  Would (1) be something
> feasible to do in the near term?  Would (2) be feasible to do in the long
term?
> 

Sub-menus are not hard at all.

The menu.4th module released under 9.0-RELEASE already supports sub-menus and
hierarchical menus.

You don't have to change the Forth code in even the slightest, this can all be
done through "rc" files like "menu.rc".

The magic of-course is achieved through the utilization of the "menu-clear" FICL
word (linked-to below):

http://svnweb.freebsd.org/base/release/9.0.0/sys/boot/forth/menu.4th?revision=22
9286&view=markup

NOTE: menu-clear is the last function in the file at the very bottom.

The comment for which is thus:

"This function unsets all the possible environment variables associated with
creating the interactive menu. Call this when you want to clear the menu area in
preparation for another menu."

Further-more, I have full examples on how to implement (working) sub-menus,
hierarchical menus, and such.

However...

Design discussions would have to follow as we do have serious limitations.

First, each menu can have only 9 items (we are in-fact limited by screen
real-estate as we do indeed want to retain support for serial consoles during
boot).

Also, don't forget that we actually have three different types of menu items
that can be used for each item in each menu:

1. Normal action-items (like "Boot")
2. Toggle items (like "On/Off" or "Yes/No" features)
3. Cyclic items (allowing selection of one kernel out of 5 different ones, for
example)

So creativity can probably find a graceful solution to however many items we
need to support.

(thinking out loud here: maybe such a discussion would be best shunted off to
hackers if/when we get to the point of discussing actual changes, patches, and
code)
-- 
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.