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

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

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.

Thanks,
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