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

Greg KH greg at kroah.com
Fri Dec 9 23:20:41 EST 2005


On Thu, Dec 08, 2005 at 04:31:45PM +0100, Kay Sievers wrote:
> On Wed, Dec 07, 2005 at 06:54:48PM -0800, Jean Tourrilhes wrote:
> > On Wed, Dec 07, 2005 at 06:15:24PM -0800, Pete Zaitcev wrote:
> > > On Wed, 7 Dec 2005 17:23:32 -0800, Greg KH <greg at kroah.com> wrote:
> > > 
> > > >  Would something like the libusual code in
> > > > -mm work better for this instead?
> > > 
> > > I have suggested libusual but Pavel rejected it with ... this:
> > > 
> > > > From: Pavel Roskin <proski at gnu.org>
> > > > To: Pete Zaitcev <zaitcev at redhat.com>
> > > > Subject: Re: Using the "best available" driver
> > > > Date: Sat, 03 Dec 2005 02:59:21 -0500
> > > 
> > > > I think the libusual approach doesn't scale and depends on the good will
> > > > of the maintainers of the device drivers.
> > > 
> > > No comment necessary. :-)
> > > 
> > > -- Pete
> > 
> > 	Ok, I had a look at libusual. I'm sorry, but it won't work
> > with some of my scenario (having both a Prism2 and an Orinoco card
> > active at the same time).
> > 
> > 	Moreover, I don't want to offend you, but I personally don't
> > really like the overall approach. You really want to keep drivers as a
> > self encapsualted entities, as independant as possible from each
> > other. This simplify maintainance and avoid breakage, and allow to add
> > or remove drivers from the kernel tree with minimal disruptions. This
> > approach also force you to unload drivers to change the bias, and is
> > very coarse grained (unless you change the libusual API).
> > 	And it's not generic, you have to hack each driver, which is
> > kernel bloat, whereas this generic issue calls for a generic
> > solution. Potentially, over time, each libusual may develop it's own
> > specific extensions for added "features".
> > 	The generic script from Dominik seems to offer a simpler
> > alternative, which doesn't require extensive changes. An user-space
> > override table keeps the spirit of "Policy in user space, not in the
> > kernel" (devfs vs. udev).
> > 	But all my personal opinions don't really matter, as the
> > libusual simply doesn't support the required scenario.
> 
> Wouldn't it make the most sense to have a generic flag to pass to _any_
> driver to skip the bus probing and wait for a manual bind? This would be
> useful for the storage controllers too, that have 1000's of disks connected,
> cause you don't really want to trigger all that buses at once with
> a modprobe.

Yes, that would be nice to have.

> That way, you would just need to disable all autobinding with the module
> configuration and depend on the bus device events to match a given
> configuration to "manually" enable every device with the udev event.

Crazy distro installer authors have suggested that we have a way to
disable all autobinding for a bus somehow, so they can do the binding
themselves.  They might not be so crazy after all :)

But as the codepaths for the "autobind" and the "manual bind" are almost
identical, it might be tough to disable the automatic stuff...

thanks,

greg k-h



More information about the linux-pcmcia mailing list