Jon Smirl <[EMAIL PROTECTED]> wrote:Jens is right that this is a user space issue, but how many people are going to find this out the hard way when their root drives stop mounting. Since no one is complaining I have to assume that most kernel developers have their root device drivers built into the kernel. I was loading mine as a module since for a long time Redhat was not shipping kernels with SATA built in.
I don't agree that this is a userspace issue. It's just not sane for a driver to be in an unusable state for an arbitrary length of time after modprobe returns.
What about if I'm booting from a USB drive? In that case, because of the
asynchrony of USB probing, it may take 1 or 2 seconds for my attached hub
to power on, wake up, boot its embedded microprocessor, etc before it will
respond to signals. In such a case, as far as the root hub can tell,
there are _no_ external devices for a couple seconds, and that's ignoring
that my external USB bootdrive may _also_ need time to "boot" before it
will be accessible, and that's only once its parent hub has become
available.
I think that the kernel needs some kind of wait-for-device API that is
accessible from kernel-space for the simple boot sequence, perhaps just
waiting for a specific kobject to be detected and complete initialization.
For an initrd/initramfs in userspace, dnotify on sysfs (For the static /dev case), or dnotify on /dev (For the udev case) should allow it to detect when the device is available.
Cheers, Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r !y?(-)
------END GEEK CODE BLOCK------
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
