Messages in this thread | | | Date | Wed, 22 Feb 2006 11:54:10 -0800 | From | Andrew Morton <> | Subject | Re: 2.6.16-rc4: known regressions |
| |
Joel Becker <Joel.Becker@oracle.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |