revisiting tunables under Safe Mode menu option

[Devin Teske]

> -----Original Message-----
> From: Andriy Gapon [mailto:avg at FreeBSD.org]
> Sent: Thursday, March 01, 2012 9:07 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 18:52 Devin Teske said the following:
> >
> >
> >> -----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.
> >
> > When I created the new menu for 9.x/higher, I had to rewrite that portion of
> the
> > code and eventually learned what Safe Mode does when used. Still can't say
> that
> > I've ever used it, however, at the point that I saw that it disabled ACPI
among
> > other things, that it is more of a blanket option for anything and
everything
> > that might be useful if/when you're having problems (*cough* still can't say
> > that I've ever used it, as when I have problems I'm usually slogging through
the
> > kernel code, not relying on safe mode to fix some problem).
> >
> > That being said, I felt that it was a huge improvement to the UI to have the
> > Safe Mode option divulge a little bit of its secret by visibly diddling the
ACPI
> > menu item (giving a clue to people that *haven't* read the code that this
> option
> > is indeed not independent but instead conglomerate in-nature).
> >
> > Indeed, I've watched field engineers when exploring the menu options and
> their
> > eyes light-up when they see that "Safe Mode" toggles ACPI off when enabled.
> > Extrapolating on their surprise, they appear to have an "Aha!"-moment as
> > previously... this field engineer had no idea what on God's green Earth what
> > "Safe Mode" did (or didn't) as he didn't know about "kenv" and certainly
> > couldn't read "Forth". At that point, he may not have had a full
understanding
> > of all the options that Safe Mode  diddled, but at that point he at least
knew
> > that Safe Mode is a multi-option that does many things -- which is more than
> > 6.x, 7.x, or 8.x ever offered which simply boots immediately the Safe Mode
> > option is selected and does nothing to explain what it is that Safe Mode is
> > doing (which would in-turn properly calibrate the user's expectations).
> >
> > Making the menu items completely independent would be take away the
> (however
> > slight) above value-add that was brought in by entwining these two menu-
> items.
> > I'm not saying that this would be a grave travesty, but would in-fact be a
> > value-loss.
> 
> Devin,
> 
> you did a great job with boot menu enhancement in general and in this area in
> particular.  You greatly improved usability while preserving the historic
behavior
> and put a lot of work and creativity into that.  Thank you!
> 

Thank you for your kind words! Really!


> But the argument is that the historic behavior is no longer useful.  I see
that
> removing the historic behavior also kills a little bit of your code (and a
little
> bit of magic).  That's true, that's a loss in the code.
> 

(nods)

[snip]

> Having a whole sub-menu where multiple parameters could be tweaked
> individually
> would be even greater improvement.  But that's not as easy to do.
> 

Actually, it is easy to do.

Since day one, menu.4th has supported sub-menus and hierarchical menus.

HINT: see "menu-clear" at the bottom of "menu.4th"

ASIDE: Before I do some mock-ups illustrating multiple "rc" files providing
sub-menus, we'll need to discuss what these menus will look like and how they'll
be generated (I heard of a hint of having build(7) generate something). I'm not
opposed to say, having a "submenu.rc.in" which is processed into "submenu.rc"
(obviously more-appropriately named than "submenu") and hooked into a menu-item
visible in "menu.rc". Mind you, "menu.rc" may have to be forked-off itself (for
reasons we won't discuss until we get down to the nitty-gritty; possibly on
-hackers).
-- 
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.