[prev in list] [next in list] [prev in thread] [next in thread] 

List:       grub-devel
Subject:    Parallel kernel loading and keystroke capture in GRUB2
From:       Vlad <vladc6 () yahoo ! com>
Date:       2008-11-28 5:42:47
Message-ID: 904501.20152.qm () web54402 ! mail ! yahoo ! com
[Download RAW message or body]

Hi,

In a recent demonstration of how to boot Linux in 5 seconds [1], PowerTOP developers \
did not use GRUB2, even though GRUB2 is a necessary component of any production and \
consumer Linux system or multi-boot environment. As I see it, the greatest \
disadvantage of GRUB2 is that it needlessly wastes the time in which it gives the \
user the chance to stall the boot sequence in order to make changes to the boot \
settings. Of course, having this option available is a necesity in case the user's \
hardware requires tweaking the parameters passed to the kernel. However, GRUB2 should \
be loading the default kernel during this time, instead of deferring this IO-bound \
task to after the timeout has elapsed.

I'm not familiar with the internals of GRUB2, but I assume that multi-threading is \
impossible. Given this limitation, I have devised the following chain of events which \
should minimize the time needed to boot the default kernel, while still giving the \
user a chance to change the boot settings:

1. Start accepting and recording user keystrokes (background task)
2. Print a message along the lines of "Press any key to change the boot settings". \
(background task) 3. Record the start time (ie. start_timestamp=0)
4. Mount the boot partition and read grub.conf
5. If a key has been pressed, display the boot settings. Else, start loading the \
default kernel into memory. 6. Record the time when the default kernel has finished \
loading (ie. kernel_loaded_timestamp=3) 7. If a key has been pressed, display the \
boot settings. Else, if the time expended so far is less than the "timeout" variable \
set in grub.conf (ie. timeout=10), keep displaying the message and accepting \
keystrokes for the remainder of the time. Else, execute the default kernel which has \
previously been loaded to memory. In pseudo-code, this would be:

if (keystroke_detected){
     display_boot_settings();
} else if (kernel_loaded_timestamp - start_timestamp < timeout){
     keep_displaying_intro_message(timeout - (kernel_loaded_timestamp - \
start_timestamp)); } else {
     execute(default_kernel);
}

8. Once the timeout period has elapsed, if a key has been pressed, display the boot \
settings. Else boot the default kernel.

The advantage of this scheme is that the time-consuming parts of mounting the boot \
partition, reading grub.conf and loading the default kernel are done roughly in \
_parallel_ to the user seeing the intro message. This scheme also ensures that the \
user's keystrokes do not fall through the cracks, because they are checked before \
booting the default kernel at steps 5, 7 and 8.

As GRUB2 is currently set up, time is just wasted displaying the "Press any key to \
change the boot settings" message because GRUB2 is doing nothing beside awaiting user \
input. Instead, GRUB2 should be doing all the necessary preparations for actually \
booting the default kernel during this time.

Since popular Linux distros typically display the GRUB2 intro message for 30 seconds, \
the time being wasted here is astronomical compared to how fast the Linux environment \
can actually boot. Changing GRUB2 as described above would ensure that no time is \
wasted while users are given a chance to change their boot settings.

Thanks,
Vlad

[1] http://lwn.net/Articles/299483


      


[prev in list] [next in list] [prev in thread] [next in thread]