It wasn't obvious to you, was it. So how can you call it simple. For
modules, we need something that is truly simple, and having __exit return
a flag is it. That is not to say that Al's mechanism is wrong, at least
as far as filesystem modules go. In this case you'd rely on (part of)
it to determine the correct flag to return. It's just that this is not
the most straightforward mechanism for the job, and therefore wrong.
Besides, how much sense does it make for __exit to be incapable of
returning an error code?
> The expected behaviour is as it has always been: rmmod fails if anyone
> is using the module, and succeeds if nobody is using the module. The
> garbage collection of modules is done using "rmmod -a" periodically, as
> it always has been.
Al's analysis is all focussed on the filesystem case, where you can
prove assertions about whether the subsystem defined by the module is
active or not. This doesn't cover the whole range of module applications.
There is a significant class of module types that must rely on sheduling
techniques to prove inactivity. My suggestion covers both, Al has his
blinders on.
Designs are not always correct just because they work.
-- Daniel - 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/