[lkml]   [2004]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: modprobe + request_module() deadlock
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?
A bad analogy is like a leaky screwdriver -- Richard Braakman

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:08    [W:0.056 / U:0.084 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site