Excuse me, Roman, but that's the central thesis of my [rfc]. If I didn't
express it concisely enough to make that obvious, I apologize.
> So all the module code
> needs to do is some general module management and ask the module somehow,
> whether it's safe to unload, when the user requests it. The easiest way
> for modules to check for this is to use counters, it's very simple and
> covers the majority of modules.
Err, check. In the [rfc].
> The few modules that don't want/can't use counters can use whatever they
> want and they usually know better how to synchronize with the part of the
> kernel where they installed their hooks into, without disturbing too much
> other parts of the kernel.
Check. In the [rfc].
> I really don't like the synchronize calls as general mechanism, either
> they have to to do too much and possibly disturb other parts without good
> reason
Check. In the [rfc].
> or modules have to take care of it (e.g. don't call somehow
> schedule() without extra protection). This makes the whole synchronize
> mechanism very fragile, which I'd prefer to keep it in the modules which
> really need it, where it can be better controlled.
Yuppers. Are there any points at all we disagree on?
-- 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/