On Mon, Jul 26, 2010 at 02:49:56PM +0300, Antti Kantee wrote: > On Sun Jul 25 2010 at 15:17:29 -0700, Paul Goyette wrote: > > On Mon, 26 Jul 2010, matthew green wrote: > > > > > > > >it seems to me the root problem is that module_mutex is held while > > >calling into the module startup routines. > > > > > >thus, the right solution is to remove this requirement. > > > > Yes, that's what is needed. > > I'm far from convinced that's a good idea. First, it will probably > make the module code a nightmare -- what happens when you have multiple > interleaved loads, some of which fail at some point in their dependency > stack, and let's just throw in a manual modunload to mix up things > further. Second, and pretty much related to number one, it goes against > one of the most fundamental principles of robust code: atomic actions.
This: atomicity. The atomic behaviour is relied upon to give "all or nothing" semantics upon load and unload, like transactions in a database. Admittely some modules (not of my making) are sloppy about this and so break that bit of the interface contract. > If modload-from-modcmd is found necessary, sounds more like a case for > the infamous recursive lock. Recursive lock is the way to go. I think the same lock should also cover all device configuration activites (i.e. autoconf) and any other heavy lifting where we have chunks of the system coming and going.
