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

Kay Sievers kay.sievers at vrfy.org
Thu Dec 8 10:31:45 EST 2005


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.

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.

Kay



More information about the linux-pcmcia mailing list