From owner-freebsd-current@FreeBSD.ORG Thu Mar 1 22:19:14 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 0AA1D106567C; Thu, 1 Mar 2012 22:19:14 +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 BE5B68FC29; Thu, 1 Mar 2012 22:19:13 +0000 (UTC) Received: from pps.filterd (ltcfislmsgpa07 [127.0.0.1]) by ltcfislmsgpa07.fnfis.com (8.14.4/8.14.4) with SMTP id q21MCkpj001835; Thu, 1 Mar 2012 16:18:56 -0600 Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa07.fnfis.com with ESMTP id 13ahps00mw-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 01 Mar 2012 16:18:56 -0600 Received: from dtwin (10.14.152.15) by smtp.fisglobal.com (10.132.206.17) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 1 Mar 2012 16:18:38 -0600 From: Devin Teske To: "'Julian Elischer'" 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> <4F4FE85D.4070205@freebsd.org> <074701ccf7f3$315cca20$94165e60$@fisglobal.com> <4F4FEF85.2050308@freebsd.org> In-Reply-To: <4F4FEF85.2050308@freebsd.org> Date: Thu, 1 Mar 2012 14:18:49 -0800 Message-ID: <075601ccf7f9$47b0fac0$d712f040$@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/AMLV7IACMTn3hwHG4pEjAmyjlPQCXNOZIZPdQRCw 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 22:19:14 -0000 > -----Original Message----- > From: Julian Elischer [mailto:julian@freebsd.org] > Sent: Thursday, March 01, 2012 1:52 PM > To: Devin Teske > Cc: 'Andriy Gapon'; freebsd-current@freebsd.org; 'Devin Teske'; 'John Baldwin' > Subject: Re: revisiting tunables under Safe Mode menu option > > On 3/1/12 1:35 PM, Devin Teske wrote: > > Right, making the assumption that FreeBSD's safe mode will do the same thing > as > > Windows' safe mode is a poor assumption. > > > > As you point out, all those things that Windows safe mode does, FreeBSD does > > not. > > > > X11 drivers are not affected by safe mode. > > > > Network is not affected by safe mode. > > > > Services started at boot, are not affected... > > > > So I would welcome discussions involving development of something better > (and am > > willing to help). > > but, with help from the rc people. it could.. > the kenv framework gives us a much more flexible way to implement the > sysV runlevels that linux inherrited. > > here's what I would envision: > > a single safe mode switch > a way to control what that does (either 'safe mode' drops you to > another menu which includes > "boot safe mode:" and "configure safe mode" (the second one drops you > to yet another menu of check boxes). > > the result of this is a preconfigured set of kenv entries being dumped > into the kenv space. > > The rc system can look at the kenv space for some key entries and act > accordingly. > it can also SAVE to /boot/safe_mode.conf the set of kenv entries > selected when safe mode is used, > and the forth code can load that and use it as a default on next > 'safe' mode usage. > > > BTW do we use the forth boot stuff on all architectures? > what of NFS boots? Glad you asked. There are architectures that don't use beastie.4th at all and thus simply fall to the autoboot sequence after handling loader.conf. These architectures lack a menu, so it would be nice if we accommodated them with (at least) allowing manual configuration through environment variables (later grabbed with kenv by the rc folks). I don't think it's beyond scope to think we couldn't cleanly implement this with (say) a well-crafted /etc/rc.d/safemode Not exactly sure what "service safemode start" should do (BSD doesn't have the same concept of runlevels as Linux does; so it's not exactly intuitive to think we could go from multi-user mode *into* safe mode). But "service safemode status" would be interesting. Interestingly, it would perhaps be nice if "service safemode stop" brought the system back to fully usable without need for reboot (something Windows doesn't offer). -- 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.