From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Date: Sat, 10 Dec 2005 04:20:41 +0000 Subject: Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver] Message-Id: <20051210042041.GB18714@kroah.com> List-Id: References: <20051207181524.71dc2d41.zaitcev@redhat.com> In-Reply-To: <20051207181524.71dc2d41.zaitcev@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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 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 > > > > To: Pete Zaitcev > > > > 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 ------------------------------------------------------- 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_id865&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