From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dominik Brodowski Date: Sun, 11 Dec 2005 19:59:20 +0000 Subject: Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver] Message-Id: <20051211195920.GA32308@isilmar.linta.de> List-Id: References: <20051207181524.71dc2d41.zaitcev@redhat.com> In-Reply-To: <20051207181524.71dc2d41.zaitcev@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org Hi, On Sun, Dec 11, 2005 at 05:13:10PM +0100, Kay Sievers wrote: > On Sun, Dec 11, 2005 at 10:48:56AM -0500, Pavel Roskin wrote: > > Quoting Kay Sievers : > > > > > This quick hack works for me, but does it at the driver level, which is > > > nicer to use than a global bus control. > > > > > > If the driver is already loaded, it can be controlled in sysfs or it can > > > be passed to modprobe and the driver gets initialized with that setting. > > > That way, modules/drivers can be set-up in modprobe.conf, to wait for > > > manual bind requests. > > > > Please, let's make "manual bind" independent of modules. In fact, it's less > > needed in case of modules, because you can control the order, in which they are > > loaded. > > No, definitely not. If you have 10 times the same piece of hardware, it > has absolutely nothing to do with module load order, what modprobe will > do with the 10 instances without any control. It is already an issue > with storage controllers with thousends of disks connected. > > > When manual bind is really needed is the case of the monolithic kernel. > > I couldn't care less about monolithic kernels and controlling binding of > devices. These requirements have almost zero overlap. But sure, you can easily > make the module parameters working for that, with prepended driver names. > > > Every driver has a name, so we should be able to refer to it before it's loaded. > > To keep around a predefined list of possible future drivers loaded in the kernel? > I'm sure, we don't want that. > > > There should be a way to tell the kernel not to autobind e.g. orinoco_cs, > > whether it's a module or an in-kernel driver. > > But not that way. You want to compile that list into in the kernel? Or where > should your monolithic kernel get that list from? > > > In the later case, we want some kind of kernel command line support. > > Well, I don't think the former case should happen at all. Kay, I really like your patch and the approach it uses! Many thanks for that! Now, concerning the issue Pavel notices: would it be acceptable if drivers can add a definition for a module parameter using e.g. MODULE_PARAM_AUTOLOAD(orinoco_cs_driver.driver); which then expands to a "normal" module parameter, being available _both_ on module probing and on a monolithic kernel? If so, I'll write a patch which does so. Thanks, Dominik ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel