Re: Forcing a USB device to "ugen"

[Brad Spencer <brad%anduin.eldar.org@localhost>]

Brian Buhrow <buhrow%nfbcal.org@localhost> writes:

> 	Isn't it possible to do most of what Jason proposes by using the drvctl interface to
> detach a driver from a specific USB device?  Then, some glue could be added to the ugen driver
> to allow it to be attached to arbitrary devices using the same drvctl interface?  That seems a
> lot easier to me than building a registry of devices and device IDs, which will be  woefully
> out of date before it gets published.  It also has the advantage of allowing the user to do
> creative stuff that the developers didn't think of.  Am I missing something obvious?
>
> -thanks
> -Brian


I don't think that the detach part is a problem, but the second part is
murky.  The only thing I know of that can do the second part is a rescan
call against the USB bus.  Unless the ugen driver is allowed to have a
higher priority than the specific device driver, the specific wins
during the rescan of the USB bus.  The use of ugenif was mentioned, and
this is a way to do the "make ugen have a higher priority" game, but
ugenif requires a custom kernel.  See the ugen man page for the hint on
how to use ugenif.

There is the concept of tags that can be passed in a rescan, but to use
those effectively for this problem is messy.  You may end up having to
put the "detect that ugen has a high priority" in every driver or at the
very least the [uoevx]hci drivers and even then, it isn't tied to a
specific device really, just the concept of "on this rescan, have ugen
take priority" and ANY device found would get ugen.

Jason's notion of using ugen as a bus instead of a leaf has merit and
may be the better approach.  The devil will be in the details, however.





-- 
Brad Spencer - brad%anduin.eldar.org@localhost - KC8VKS - http://anduin.eldar.org