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

[Kay Sievers]

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 at 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