Re: [PATCH] speedy boot from usb devices

From: Kalin KOZHUHAROV
Date: Tue Aug 03 2004 - 10:42:02 EST


David N. Welton wrote:
Paulo Marques <pmarques@xxxxxxxxxxxx> writes:


David N. Welton wrote:


Works like so: whenever a block device comes on line, it
signals this fact to a wait queue, so that the init
process can stop and wait for slow devices, in particular
things such as USB storage devices, which are much slower
than IDE devices. The init process checks the list of
available devices and compares it with the desired root
device, and if there is a match, proceeds with the
initialization process, secure in the knowledge that the
device in question has been brought up. This is useful if
one wants to boot quickly from a USB storage device
without a trimmed-down kernel, and without going through
the whole initrd slog.
I find this to be very useful. I always found the "sleep for a while
until the device we want appears" approach very cumbersome.

I hope it works. I tried to hack some delay on my own, but without success :-(
Will try this patch.

Glad to hear someone likes it.


However, after looking at your patch, it seems that having a
get_blkdevs() function that alloc's an array of strings, and return
it to a function that only compares the strings against the name it
is looking for and drops the array altogether, is a little overkill.
Why not have a simple blkdev_exists(char *name) function in genhd.c,
call it directly, and drop the match_root_name() function
completely?


Sure, that's probably better. Maybe "blkdev_is_online"? I'll see if
I can do it tommorow.

Waiting :-)
I am planing to run a Gentoo-based small dist off a 128MB USB flash.

I'm also a bit dubious of having the wait queue floating around as a
global, but don't know the kernel well enough to find it a better
home.

Thumbs up!

Kalin.

--
|| ~~~~~~~~~~~~~~~~~~~~~~ ||
( ) http://ThinRope.net/ ( )
|| ______________________ ||

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/