Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261794AbUKUIjj (ORCPT ); Sun, 21 Nov 2004 03:39:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261920AbUKUIjh (ORCPT ); Sun, 21 Nov 2004 03:39:37 -0500 Received: from ozlabs.org ([203.10.76.45]:32944 "EHLO ozlabs.org") by vger.kernel.org with ESMTP id S261794AbUKUIjf (ORCPT ); Sun, 21 Nov 2004 03:39:35 -0500 Subject: Re: modprobe + request_module() deadlock From: Rusty Russell To: Gerd Knorr Cc: Takashi Iwai , "Alexander E. Patrakov" , lkml - Kernel Mailing List In-Reply-To: <20041119115042.GA30334@bytesex> References: <20041117222949.GA9006@linuxtv.org> <1100749702.5865.39.camel@localhost.localdomain> <20041118135522.GA16910@linuxtv.org> <20041119115042.GA30334@bytesex> Content-Type: text/plain Date: Sun, 21 Nov 2004 19:39:30 +1100 Message-Id: <1101026370.18919.32.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1822 Lines: 42 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/