New Boot Loader Menu

[Devin Teske]

On Oct 9, 2012, at 1:03 PM, Alexander Leidinger wrote:

> On Sun, 7 Oct 2012 14:58:46 -0700 Devin Teske
> <devin.teske at 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.
> 

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:
>> 
>> 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)?

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.
> 

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).
> 
> If it is not much work, I don't think we should hesitate to do it. It
> offers the possibility to make enhancements later.
> 

Ok, let me put a patch together for review.
-- 
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.