Re: 2.6.16-rc4: known regressions

[Joel Becker <Joel.Becker@oracle.com>]

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.

is the "most correct".  It makes perfect technical sense.  If you were
starting from scratch, no one would be complaining, becuase no one would
see a problem.
	We're not starting from scratch.  We have large installed bases
of userspace code that expects a certain behavior from the kernel.
While it sometimes is necessary to say "you need to update", I think the
consensus is clear - only do that when it is necessary.  Don't call
people dumb or say they "need to update" just because you didn't
consider existing users.

Joel

-- 

 "I'm living so far beyond my income that we may almost be said
 to be living apart."
         - e e cummings

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
-
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/