Re: [PATCH] speedy boot from usb devices

[David N. Welton]

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.

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.

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.

Thanks!
-- 
David N. Welton
     Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
   Apache Tcl: http://tcl.apache.org/
       Photos: http://www.dedasys.com/photos/
-
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/