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

[Jean Tourrilhes]

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.

	Have fun...

	Jean