Well, I have to disagree here. "I have successfully finished my
initialization" is the same logic you're trying to beat into module
author's heads before they commit their interfaces.
> And that's one of the main problems I have with your approach - you
> are trying to make module loader do the stuff that has nothing
> whatsoever with modules.
Or, put another way, I'm trying to ensure that correct code in the
kernel is correct code in a module, by having the module code simulate
the conditions in which the original occurred.
> Moreover, if driver is built into the kernel, you get (at the very least)
> a different mechanism for triggering the same events, if not the outright
> different sequence of events. Which is a Bad Thing(tm) since it leads to
> a shitload of extra problems with debugging.
Speaking of which, what's the long-term plan for hotplug events at
boot? Will you get a shitload of "add" events, or rely on userspace
to scan?
> Double freeing. Forgetting to free. Dereference after freeing. Leaving
> timers active. Leaving pointers to local structures in global arrays.
Hmm, my audit of copy_to/from_user uncovered similar bogosities, and
I've dropped more than one Trivial Patch Monkey patches because they
cleaned up one case in an incurable sewer of problems 8(
The "better to have a bad driver than no driver" becomes less true as
people start copying from it, too. This is where meta-maintainers
like Jeff Garzik make a definite difference as chief shit-kicker.
> On that background all shite you are so concerned about is a noise.
Perhaps. But I can't change the world: that's your job.
> What we _can_ do (and that will be on per-subsystem basis) is providing
> APIs that would cut down on the amount of glue needed in driver init.
Fervently agree: it's hard to get one line wrong, *and* almost any
scheme can be implemented on top of it.
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/