From owner-freebsd-arch@FreeBSD.ORG Tue Oct 9 20:30:56 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DB6253FB; Tue, 9 Oct 2012 20:30:55 +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 9CA298FC12; Tue, 9 Oct 2012 20:30:55 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa03.fnfis.com (8.14.4/8.14.4) with ESMTP id q99KUsC0031119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 9 Oct 2012 15:30:54 -0500 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 9 Oct 2012 15:30:53 -0500 Subject: Re: New Boot Loader Menu MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="us-ascii" From: Devin Teske In-Reply-To: <20121009220325.00006c9d@unknown> Date: Tue, 9 Oct 2012 13:30:47 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <20121007183433.000026a6@unknown> <20121007220100.00002d21@unknown> <20121009220325.00006c9d@unknown> To: Alexander Leidinger X-Mailer: Apple Mail (2.1283) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-10-09_05:2012-10-09,2012-10-09,1970-01-01 signatures=0 Cc: Devin Teske , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 20:30:56 -0000 On Oct 9, 2012, at 1:03 PM, Alexander Leidinger wrote: > On Sun, 7 Oct 2012 14:58:46 -0700 Devin Teske > wrote: >=20 >>=20 >> On Oct 7, 2012, at 1:01 PM, Alexander Leidinger wrote: >=20 >>> The first one is a tribute to the >>> poor victim which gives a helping hand, he will not see the boot >>> options in case the request is made to change the root FS. The >>> second one is that the boot options are modifying the behavior of a >>> given kernel (verbose messages, safe mode, acpi), while the >>> root-fs/BE/kernel item is choosing a different kernel to boot. >>>=20 >>=20 >> I wholly agree with the separation into 2 submenus and _why_, >> however... >>=20 >> Let's be careful here. >>=20 >> Be careful to not include "kernel" in that mix. >=20 > I included kernel in that mix, because loading a different BE/FS is > basically loading a different kernel. While it would be nice to be able > to chose a kernel if there are multiple in a given FS, I didn't want to > imply this here. >=20 You make a very astute observation here. I'm really thinking that the "promised land" is to have a [proposed] kernel= selection menu dynamically enumerate all kernels available on the selected= root device. I think we should discuss/explore this further at the up-coming DevSummit. = I'm requesting time in the Talks -- I'm thinking this is perfect to add to = my time-slot. >> In reality, the kernel is loaded by the "start" FICL word provided by >> loader.4th and this is done: >>=20 >> a. before the menu is loaded and >> b. irrespective of the menu (done regardless of whether the menu is >> enabled or not, perhaps via setting beastie_disable=3DYES in >> loader.conf(5)) >>=20 >> So by the time the menu is invoked, the only way to change the kernel >> is to "unload" and subsequently load the new kernel. >>=20 >> It should be noted that DruidBSD does not load a kernel before the >> menu. Thus in DruidBSD, we _do_ have a kernel selection menu (the >> overloaded "boot" FICL word in DruidBSD is coded to load $kernel >> right before doing the real boot whereas FreeBSD's overloaded "boot" >> FICL word simply invokes the already-loaded kernel that was loaded >> before the menu ever started). >=20 > Is it faster to not load the kernel (time from pushing the power > button to the loader menu being reactive to key presses)? Absolutely! > If yes, it > may be beneficial to do it the way DruidBSD is doing it (it does not > cut the time to arrive at multi-user mode, but it improves the > response time and has the psychological effect to let the user think > it boots faster). I like this idea. > And if we want to chose a kernel from a list to boot > from, (which I think we want), we should do it too. >=20 I'm with you. >> It's perhaps good that we're having this discussion out in the open >> now, because I actually (as of yet) do not know if jpaetzel, avg, mav >> and iX company have plans to (attempt) to allow kernel swapping in >> the loader menu. If that is the case, we'll have to broach the topic >> of changing that functionality to match what DruidBSD does (defers >> kernel loading until "boot" is invoked). >=20 > If it is not much work, I don't think we should hesitate to do it. It > offers the possibility to make enhancements later. >=20 Ok, let me put a patch together for review. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.