On Sun, Jun 25, 2000 at 01:04:43PM +0100, Alan Cox wrote:
> > > sleeping in cleanup module
> > > open /dev/hda
> > > ????????
> >
> > Shouldn't be able to happen, because /dev/hda should not exist if the
> > module refcount is zero. Except for the register_netdevice problem.
>
> /dev/hda always exists
>
> The user is opening it so needs to load the module for it. The module for it
> is still being unloaded.
So the driver writer just need to implement normal server
shutdown behavior:
1. Deny all future requests
2. Finish all currently served requests
3. exit server
So in module context:
1.
a) fail on open() now.
b) unregister from subsystem (or unregister file ops)
- The subsystem need to take care that it
registers/unregisters from its subsystem and the other
kernel subystems in the right order (s. registration
order)
2. wait on each exported IPC mechanism (wait queues, sema4, spinlocks, etc.)
3.
a) disable hardware (maybe do this in 1.c before...)
b) exit module
Where is the problem? Many servers do a racefree shutdown like
this.
Registration order:
1. Allocate ressources, which no subsystem relies on.
2. Allocate ressource, which only requires the ressources
allocated in 1.
3. Repeat 1. and 2. to build a bottom-up tree of ressources
4. hand these set of ressource _completely_ to a subsystem by
registration
5. repeat 3. and 4. until we have a the full tree of resources
permanently needed by our driver
Failure path:
If ressource allocation fails, deallocate ressources in inverse
allocation order. If this is not possible, we were allocating
in the wrong order in the first place -> redesign allocation
order!
Unregistration:
1. Unregister from user visible namespace.
1a. Unregister from subsystem (usally the subsystem implies 1.
too, but there might be broken subsystems out there...)
2. Deallocate/unregister ressources in reverse
allocation/registration order. If unregister fails ->
sleep until it would succeed.
3. Exit driver.
Problems:
It might seem nonsense in 2., to sleep for the ressource and
it can mean deadlock. But this a a bug anyway, which should be
catched before occourence by allocation order or by applying
Steps 1. and 1a.
Comments?
Regards
Ingo Oeser
-- Feel the power of the penguin - run linux@your.pc <esc>:x- 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 Jun 26 2000 - 21:00:06 EST