From owner-freebsd-current@FreeBSD.ORG Thu Mar 1 21:39:45 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5557106564A; Thu, 1 Mar 2012 21:39:45 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 651D88FC0A; Thu, 1 Mar 2012 21:39:45 +0000 (UTC) Received: from pps.filterd (ltcfislmsgpa03 [127.0.0.1]) by ltcfislmsgpa03.fnfis.com (8.14.4/8.14.4) with SMTP id q21LQe4b012954; Thu, 1 Mar 2012 15:39:44 -0600 Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa03.fnfis.com with ESMTP id 13agh68557-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 01 Mar 2012 15:39:44 -0600 Received: from dtwin (10.14.152.15) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 1 Mar 2012 15:39:42 -0600 From: Devin Teske To: "'Julian Elischer'" , "'Scott Long'" References: <4F26CC5A.2070501@FreeBSD.org> <4F4C0600.2000903@FreeBSD.org> <3BA1B476-ED05-4E8E-8DFA-0B06EFB48867@samsco.org> <201202280846.08966.jhb@freebsd.org> <4F4F35B9.5090308@FreeBSD.org> <06bb01ccf7cb$b255a200$1700e600$@fisglobal.com> <26352740-D897-46CD-BD17-C61334826524@samsco.org> <4F4FE9E1.4020201@freebsd.org> In-Reply-To: <4F4FE9E1.4020201@freebsd.org> Date: Thu, 1 Mar 2012 13:39:54 -0800 Message-ID: <074901ccf7f3$d7ca6160$875f2420$@fisglobal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLEjfzJ7eGDusxFSn76rGzI0P/AwwHL8N43AisSv0ECK+W+iQGLJ1u/AMLV7IACMTn3hwJGY3lpAfRTEqKT7+OyYA== Content-Language: en-us X-Originating-IP: [10.14.152.15] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498, 1.0.260, 0.0.0000 definitions=2012-03-01_04:2012-03-01, 2012-03-01, 1970-01-01 signatures=0 Cc: freebsd-current@freebsd.org, 'Devin Teske' , 'Andriy Gapon' Subject: RE: revisiting tunables under Safe Mode menu option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 21:39:45 -0000 > -----Original Message----- > From: Julian Elischer [mailto:julian@freebsd.org] > Sent: Thursday, March 01, 2012 1:28 PM > To: Scott Long > Cc: Devin Teske; freebsd-current@freebsd.org; 'Devin Teske'; 'John Baldwin'; > 'Andriy Gapon' > Subject: Re: revisiting tunables under Safe Mode menu option > > 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. I'm interested in which path you would choose amongst what I've seen mentioned thus far: a. Modifying the boot menu to offer fine-grain control over each aspect of Safe Mode (wherein perhaps the Safe Mode option becomes a hook for a sub-menu rather than its current setup as an "On"/"Off" toggle). b. Keeping Safe Mode as an On/Off toggle, but shifting the fine-grain control to userland (wherein loader(8) simply sets a safemode Boolean and the user is dropped into something like single-user mode but with prompts for each feature) c. Something else. -- 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.