Re: [patch] pipe: Don't oops when pipe filesystem isn't mounted

From: Linus Torvalds
Date: Mon Dec 11 2006 - 11:41:40 EST




On Mon, 11 Dec 2006, Al Viro wrote:
>
> FWIW, I really think that this sort of bugs ("oh, I call hotplug,
> rootfs is there but kernel is not ready, woe is me") clearly show
> that many, _many_ users of hotplug are BS. The reason is simple -
> if we have a call of hotplug that early, we have a driver that lives
> with hotplug failures _and_ with different behaviour in built-in
> and modular cases. I would argue that any such driver is broken.

Now, you are probably right that many of them are unnecessary, but I don't
agree in _general_.

It's perfectly normal behaviour to say "I discovered this device".

The fact that device discovery happens during early bootup and nobody even
_cares_ (because early bootup ends up enumerating all discovered devices
on its own) is a separate issue. The fact that many distros don't care
during early bootup doesn't mean that they don't care later on.

Another reason for "unnecessary" hotplug events is that generic functions
like "I added a bus" happen both for static buses _and_ for "hey, somebody
loaded a module that found this bus". Again, the static case may be
something that people don't _care_ about, but we should (a) use common
code and (b) be consistent, so we do a hotplug event regardless.

That said, I definitely agree that people shouldn't expect hotplug events
to be delievered too early. If it's something that runs in a
core_initcall, and is compiled in, no way in *hell* should we actually
expose that to anything - it's just too early.

So it makes perfect sense to say

"you won't be getting any notification by anything built-in, until
'device_initcall' (which is the default module_init, of course)".

which in the case of certain drivers obviously _does_ mean that they had
better not try to use any early initcalls to load firmware.

Linus
-
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/