Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver]

[Kay Sievers <kay.sievers@vrfy.org>]

On Sun, Dec 11, 2005 at 08:59:20PM +0100, Dominik Brodowski wrote:
> 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 <kay.sievers@vrfy.org>:
> > > 
> > > > 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.

If we go that road, we may not want to do the "default modrobe parameter"
handling hack at all and just add a "bind_mode" parameter to every module
which wants to support boot prompt or modprobe parameters. All I care, is
not to have a magic policy list for possibly loaded drivers in the kernel.

It may be a bit cleaner with the normal kernel parameter too and should work
the same way with modular and compiled-in drivers. "bind_mode" setting
init support would not be available then without adding the parameter to
every module which needs it, but that's acceptable I think.

Kay


-------------------------------------------------------
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_id\x16865&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