Re: hotplug arch. and apps

[Johannes Erdfelt <johannes@erdfelt.com>]

My original devfs based patch used a priority number. Basically the the
biggest priority got elected to be the driver to be loaded and bound to
the interface.

It was arbitrary and less than perfect.

The only thing I can think of now is to favor vendor specific alternate
settings over class alternate settings. I'm not sure if this is the best
assumption to make however.

JE

On Thu, Nov 15, 2001, David Brownell <david-b@pacbell.net> wrote:
> Johannes, what sort of policy criteria would you suggest for
> choosing one driver versus another?
> 
> The "usbmodules" command is able to use richer inputs to
> its policy.  Right now what it does is exactly mimic the policy
> that the kernel uses.
> 
> Seems we'd need to start recording (preferably in the kernel
> and then exported) things like "prefer uss720 to printer".
> 
> So far my thought in this area has been that the kernel
> needs to stay simple, and this sort of logic can be done
> in userland given suitable binding/unbinding/rebinding
> hooks in the kernel.
> 
> - Dave
> 
> 
> ----- Original Message ----- 
> From: "Johannes Erdfelt" <johannes@erdfelt.com>
> To: "Greg KH" <greg@kroah.com>
> Cc: <linux-hotplug-devel@lists.sourceforge.net>
> Sent: Thursday, November 15, 2001 5:42 PM
> Subject: Re: hotplug arch. and apps
> 
> 
> > On Thu, Nov 15, 2001, Greg KH <greg@kroah.com> wrote:
> > > On Thu, Nov 15, 2001 at 03:39:58PM -0800, Scott Cuyle Fritzinger wrote:
> > > > yup! from what i've read, it seems like the modules.usbmap has 'first
> > > > dibs' on any device, and then the usb.handmap is referenced if nothing
> > > > matches there.
> > > 
> > > Exactly.
> > 
> > This is something I'd like to fix at some point. We haven't solved the
> > problem of devices with multiple alternate settings that can be handled
> > by multiple drivers.
> > 
> > Like the uss720 chips which have a native mode and a USB printer class
> > alternate setting.
> > 
> > We should prefer to use the native mode in that case.
> > 
> > JE
> > 
> > 
> 
> 

_______________________________________________
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