Re: 2.6.16-rc4: known regressions

[Greg KH]

On Wed, Feb 22, 2006 at 11:54:10AM -0800, Andrew Morton wrote:
> 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.

But people are currently working right now to make a totally async boot
process that takes advantage of this behavior.  It's the only way we can
make the boot process faster.  They are working on stuff like:
	- only when the network device is reported found by the kernel
	  do the things that rely on networking start up
	- only when the filesystems are found, do the things that rely
	  on them being there (lvm, evms, dm, etc.)

And as others have pointed out, for a lot of busses, we just don't know
how long the device is going to take to be found.  For one of my boxes
with a flaky USB controller, it takes _minutes_ for devices to be
detected (yes, it is broken hardware, but the rest of the system works
just fine while it is off and trying to be detected.)

Another point is that some busses just don't know when all the devices
on it are found, as there is no such state.  USB is one such bus, and I
imagine firewire is another one.  So there is no real way for us to
delay at insmod time for all devices to be found.

thanks,

greg k-h
-
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/