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

From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver]
Date: Thu, 08 Dec 2005 15:31:45 +0000	[thread overview]
Message-ID: <20051208153145.GA15057@vrfy.org> (raw)
In-Reply-To: <20051207181524.71dc2d41.zaitcev@redhat.com>

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@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@gnu.org>
> > > To: Pete Zaitcev <zaitcev@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

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