Re: modprobe + request_module() deadlock

[Rusty Russell <rusty@rustcorp.com.au>]

On Fri, 2004-11-19 at 12:50 +0100, Gerd Knorr wrote:
> > > But IMHO Rusty should provide a way to specify those "recommended" install
> > > lines in the modules themselves (so that they finally go
> > > to /lib/modules/`uname -r`/modules.alias or a similar autogenerated file),
> > > like that's already done wih aliases and char-majors.
> > 
> > Well, how about to add a new marker in the driver code such as
> > 
> > 	MODULE_DEPENDS_ON("somemodule");
> > 
> > so that depmod can pick it up?
> 
> Wouldn't work for me as this isn't static.  saa7134 has to look at the
> hardware, then decide whenever it should load saa7134-empress,
> saa7134-dvb or none of them.
> 
> On the other hand I don't depend on request_module() waiting for the
> modprobe being finished.  So maybe we can solve that with a
> request_module_async()?

The problem is fairly simple: we don't let you get at the symbols from a
module which hasn't finished initializing yet.  This means that a
request_module() inside a module's init() will fail if the requested
module depends on this one.  async() will race with init() finishing, so
won't really help.

The traditional way to do this has been to have saa7134-empress do its
own probe, and likewise saa7134-dvb.  Unfortunately, these days modules
are not supposed to fail to load simply because there are no devices, so
wild module loading has a real cost.  Otherwise I'd be tempted to make
multiple aliases load *all* of them, and solve the problem that way.

Thoughts, anyone?
Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman