On 3/1/12 9:13 AM, Scott Long wrote:

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?

not only collecting stuff from am kernel build but from a running system.
it would be nice fro example to be able to influence the /etc/rc.d system by disabling some functions.
e.g. come up but don't turn on the window system, or networking..
We can disable a device but how about specifying a different default route than that in /etc/rc.conf?

if we extract the setup tha tthe machine eventually comes up to, we can allow that to be tuned as well.
Thanks,
Scott

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"



_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to