Date: Tue, 9 Oct 2012 22:03:25 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: Devin Teske <dteske@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: New Boot Loader Menu Message-ID: <20121009220325.00006c9d@unknown> In-Reply-To: <D2025767-BF06-442D-8A44-316ED91EA0CD@fisglobal.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 7 Oct 2012 14:58:46 -0700 Devin Teske <devin.teske@fisglobal.com> wrote: > > On Oct 7, 2012, at 1:01 PM, Alexander Leidinger wrote: > > 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. > > > > I wholly agree with the separation into 2 submenus and _why_, > however... > > Let's be careful here. > > Be careful to not include "kernel" in that mix. 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. > In reality, the kernel is loaded by the "start" FICL word provided by > loader.4th and this is done: > > 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=YES in > loader.conf(5)) > > So by the time the menu is invoked, the only way to change the kernel > is to "unload" and subsequently load the new kernel. > > 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). Is it faster to not load the kernel (time from pushing the power button to the loader menu being reactive to key presses)? 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). And if we want to chose a kernel from a list to boot from, (which I think we want), we should do it too. > 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). If it is not much work, I don't think we should hesitate to do it. It offers the possibility to make enhancements later. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121009220325.00006c9d>