Re: 2.6.16-rc4: known regressions

[Andrew Morton]

Joel Becker <Joel.Becker@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/