OK. Two devices? A device and a sysfs attribute? A device and a
filesystem? A device and a setsockopt? So I sympathise, but I
disagree here.
> This is what happens with built-in drivers already. Modules are nothing
> but a convenience. They're not "worthy" of complexity.
Agreed. Having an invisible "MUST NOT fail beyond this point" line is
leaving a subtle trap for driver writers.
We *already have* a mechanism to isolate a module: we did it to avoid
a two-stage module destroy policy. We can use the exact same
mechanism to avoid such a two-stage module init policy.
Modulo bugs, I've erred on the side of not breaking the 1500+ modules
in the kernel, and *not* exposing the unload races to them. Please
consider carefully.
Note 1: Al mentioned he wants to fire off userspace before initcalls
are done, introducing the same races in core kernel init. Without
seeing reasons, it's hard to tell why he wants this, but this would
require everyone to do two-stage init anyway.
Note 2: If you really want two-stage init, you're best off making it
explicit: ie. two functions: one which can fail (int module_prep()),
and one which can't (void module_start()). I regarded this as too
invasive a change just for an obscure module race.
Hope that clarifies?
Rusty.
-- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - 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/