Messages in this thread | | | Date | Wed, 22 Feb 2006 10:59:23 -0800 | From | Joel Becker <> | Subject | Re: 2.6.16-rc4: known regressions |
| |
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/
| |