Re: Modules loading modules?

[jnemeth%victoria.tc.ca@localhost (John Nemeth)]

On Nov 17,  5:24am, Paul Goyette wrote:
} On Sun, 1 Aug 2010, Antti Kantee wrote:
} 
} > I'm not sure if it's a good idea to change the size of kmutex_t.  I
} > guess plenty of data structures have carefully been adjusted by hand
} > to its size and I don't know of any automatic way to recalculate that
} > stuff.
} >
} > Even if not, since this is the only user and we probably won't have
} > that many of them even in the future, why not just define a new type
} > ``rmutex'' which contains a kmutex, an owner and the counter?  It 
} > feels wrong to punish all the normal kmutex users for just one use.
} > It'll also make the implementation a lot simpler to test, since it's
} > purely MI.
} >
} > "separate normal case and worst case"
} 
} Round two!  Taking pooka's suggestion, this version is built on top of 
} (rather than beside) the existing non-recursive mutex.  As such, it does 
} not affect any MD code.
} 
} Attached is a set of diffs that
} 
} 1. Adds sys/sys/rmutex.h and sys/kern/kern_rmutex.c to implement
}     recursive adaptive mutexes.  (Conspicuously missing is an rmutex(9)
}     man page...  It will happen before this gets committed.)
} 
} 2. Converts the existing module_lock from a normal kmutex_t to an
}     rmutex_t
} 
} 3. Updates all of the (surprisingly many) places where module_lock
}     is acquired.

     I'm thinking the acquisition of module_lock should be pushed into
module_autoload() instead of having the caller acquire it for this very
reason.  It makes it hard to change the way locking works in the
MODULAR code if you expect the caller to acquire the lock.  I don't
know why it was done this way originally, or what the consequences (if
any) would be for making the change.  Andrew, any thoughts on this?

} Compile-tested on port-amd64 (including rumptest).  Since there are no 
} MD-changes in this version, there "shouldn't be" any issues with 
} building on other ports.
} 
} As previously noted, there is only one known use case for this so far: 
} modules loading other modules from within their xxx_modcmd() routine. 
} The specific use case we have involves loading the acpicpu driver/module 
} which eventually results in an attempt to load acpiverbose.
} 
} It would be really nice if the community could
} 
} A. Compile-test on additional architectures
} B. Test to see that existing mutex operations still work correctly
} C. Exercise the known use case if possible
} D. Identify additional use cases
} 
}-- End of excerpt from Paul Goyette