Date: Tue, 9 Oct 2012 13:30:47 -0700 From: Devin Teske <devin.teske@fisglobal.com> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: Devin Teske <dteske@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: New Boot Loader Menu Message-ID: <A465608D-31F4-475A-9D2B-A13F1FE2C4DB@fisglobal.com> In-Reply-To: <20121009220325.00006c9d@unknown> References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <20121007183433.000026a6@unknown> <DB1B1B71-84B3-4096-BE52-7630CB74762F@fisglobal.com> <20121007220100.00002d21@unknown> <D2025767-BF06-442D-8A44-316ED91EA0CD@fisglobal.com> <20121009220325.00006c9d@unknown>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 9, 2012, at 1:03 PM, Alexander Leidinger wrote: > On Sun, 7 Oct 2012 14:58:46 -0700 Devin Teske > <devin.teske@fisglobal.com> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A465608D-31F4-475A-9D2B-A13F1FE2C4DB>