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

[Dominik Brodowski]

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

Thanks,
	Dominik