On Wed, 22 Feb 2006, Gabor Gombas wrote:
>
> I don't think isnmod is broken. It's job is to load a chunk of code into
> the kernel, and it's doing just that.
>
> The asynchronous device discovery is caused/required by hotplug. If you
> can recreate the problem with a kernel that has CONFIG_HOTPLUG disabled,
> then I agree that this is a kernel bug which should be fixed.
I think it currently can happen without HOTPLUG too. In fact,
CONFIG_HOTPLUG is really a "special drivers that do hot-plugging", not
about "devices that show up on their own".
The thing is, "insmod" really just tends to introduce the driver to the
kernel. It leaves it pretty open what that driver will actually _do_. And
a lot of drivers tend to do discovery independently of actually plugging
in the driver.
For example, any USB host driver will always discover its devices
asynchronously, and has no dependency on CONFIG_HOTPLUG. It can take
several seconds for all the hubs to have powered up and discovered what is
behind them.
The same is true of most SCSI buses - CONFIG_HOTPLUG may talk about
whether the actual _controller_ is hotpluggable, but not about whether a
disk is, or how disk discovery takes place.
Now, arguably "insmod" (both the user binary and the kernel side) is doing
the right thing: it's inserting the driver. The fact that all the devices
that the driver uses may not be immediately available is not insmod's
issue. That's a very valid way to look at it.
At the same time, it's also arguable that from an ease of use standpoint,
"insmod" should generally try to wait until the driver has enumerated what
it knows about. That's a totally non-technical argument, but it's an
equally valid standpoint.
Of course, the technical argument is that discovery can take a long long
time (minutes to wait for disks to spin up etc), so if insmod were to wait
for it all, we'd be really screwed and our bootup times would go through
the roof.
The usability argument is that right now we don't have any easy way at all
to wait for bus scanning to have finished, and that's a very valid
argument. You could wait for the hotplug event, but since you don't even
_know_ that you'll get such an event, that's really not a very good answer
either.
We could improve.
I _think_ that in this particular case, the best particular choice might
be for the "mount" binary to be taught to re-try after a few seconds:
either with a command line argument, or with just the early bootup initrd
code being encouraged to have a loop like
if (mounting root failed)
echo "Please press F1 to continue"
do
read-keyboard-with-5-second-timeout
while (mounting root failed)
endif
so that the user would have to press a key (or we'd just re-try every five
seconds).
That way, the boot wouldn't just fail immediately over something that can
be fixed (sometimes the root partition might just be hot-pluggable too:
"insert disk and continue" can be a valid way to handle issues).
Linus
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
