Hello!
> You are solving only a tiny fraction of the problem. The block/char device
> case is far from the entire problem that solving the module problem seperately
> might be a good idea ?
When you raised the question first time, I started to write an e-mail,
but was not satisfied with something in it and put it to backlog.
Now I have already forgotten what is wrong there. 8)
That's it:
The most big mistake with current modules (btw it was more correct
in 1.2, if to ignore bad implemenation. The idea was right and
it is not right now.) is that it has no true reference counting.
The thing known as USE_COUNT is not a reference count, but rather
heuristics allowing to determine when module can be unloaded.
It is theoretically evident that object _cannot_ maintain references
to itself.
So, the fix is:
1. Add a semaphore to module.c eventually.
2. Allow to initiate module deletion when USE_COUNT is _not_ zero.
3. USE_COUNT can be not zero after exit from cleanup().
cleanup() guarantees only one thing: after exit from it,
USE_COUNT never will become not-zero, if it hit zero value.
[ Such scheme is used for object reference counting by networking
and the experience showed that it is very clean and simple in use. ]
4. Unmapping module occurs only after reference count hit zero,
until that time module is in "dead" state.
5. Add new optional method: "destroy_module" to call it before unmapping.
It is allowed to return busy state even if USE_COUNT is zero,
(Some resource allocated outside module references to module resources)
in this case unmap is delayed again.
Do you see? cleanup_module() detaches module from upstream
users: chrdev tables, fs list, netdev list, irq handlers etc.
If module is clever, it will handle interleaved open()s correctly:
f.e. reject open or close device interleaved with cleanup_module().
The rest of work is made by corresponging registry. Networking
already does necessary locking on registries owned by it (socket family,
net devices etc.) Those ones, which still rely on kernel lock
(f.e. register_blkdev etc), may continue to rely on it, but their clients
must guarantee that they do not release kernel lock (and do not sleep,
certainly) between entry to module and incrementing use count,
and between decrementing reference count and leaving module.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:17 EST