Re: Question about pseudo filesystems

[Daniel Phillips <phillips@arcor.de>]

On Tuesday 10 September 2002 02:44, Jamie Lokier wrote:
> Typically, your module's resources are protected by a lock or so.
> cleanup_module() could take this lock, check any private reference
> counts, and (because it has the lock) decide whether to proceed with
> unregistering the module's resources.

Actually, there did turn out to be a problem with the code I showed
yesterday, resulting from the fact that cleanup_module wants to be able to 
sleep.  Because of this, there is no good way for module.c to protect 
module->count from try_inc_mod_count, not without changing the spinlock in 
try_inc_mod_count into a semaphore, which isn't nice either, because 
try_inc_mod_count is taken under at least one other spinlock in super.c.

There's a simple solution though: examine the module->count under the same 
spinlock as try_inc_mod_count, which is what sys_delete_module does.  We just 
encapsulate that check in a handy wrapper and define it as part of the 
try_inc_mod_count interface.  At this point the thing is generalized to the 
point where the module count isn't used at all by module.c, so the same 
interface will also accomodate the still-under-construction magic wait for 
quiescent state(), needed for modules that don't fit the mod_count model.

The nice thing is, hardly any work is required to accomplish this, though 
it's hard to look at module.c for more than a few seconds without seeing more 
things that want cleaning up.

-- 
Daniel