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?

Thanks,
Scott