Joel Becker <[email protected]> wrote:
>
> On Wed, Feb 22, 2006 at 06:33:54PM +0100, 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.
> >
> > ...
> >
> > But if your kernel has CONFIG_HOTPLUG enabled, then _you_ have asked for
> > this exact behavior, therefore you should better fix userspace to cope
> > with it. Your initrd should use the notification mechanisms provided by
> > the kernel to wait for the would-be root device really becoming
> > available; if it's not doing that, then IMHO you should not use a
> > CONFIG_HOTPLUG enabled kernel.
>
> The issue isn't so much "insmod is right" vs "insmod is wrong".
> It's that the behavior changed in a surprising fashion. Red Hat's
> kernel for RHEL4 (in our example) has CONFIG_HOTPLUG=y, yet it Just
> Works. A more recent kernel (.15 and .16 at least) with
> CONFIG_HOTPLUG=y doesn't work. Same disk drivers. Same initramfs
> script.
> We're discussing this very "kernel change broke userspace
> expectations" issue. You don't need to convince me that
>
> 1. Insmod loads the driver
> 2. Userspace initramfs sleeps waiting for hotplug
> 3. Hotplug completes
> 4. Userspace initramfs continues, using the now plugged devices.
Yes, I tend to think that insmod should just block until all devices are
ready to be used. insmod doesn't just "insert a module". It runs that
module's init function.
The very common case is that userspace wants to use those devices
immediately upon return from insmod, and the handling of these
not-yet-ready devices from userspace is very hard - generally people just
stick lame sleeps in there to get around it.
If, for some strange and rare reason, people _really_ want the
return-when-its-not-ready-yet behaviour, they can do `insmod foo &', or we
give insmod a fork-then-exit option.
But right now the default (and unalterable) behaviour is the oddball,
rarely-desired and hard-to-handle one.
-
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]
