I've been working on getting modules to load on connect as well as
Configurations being selected and I think I have the process down (as
well as code, but lets work on the process first).
I have implemented this in userspace (via an extension to devfsd) since
this is policy, and policy should not exist in the kernel.
This process is similar to the way Microsoft selects a driver in Windows
(wish I found this webpage before I started working on this):
http://www.microsoft.com/hwdev/busbios/usbpnp.htm
(Netscape has trouble with the page, Mozilla is much better)
I'd like to split the process into a device probing function and interface
probing function.
The default Configuration is the first one in the descriptor dump (or in
the case of the kernel, the first one in the array).
The matching routines look for the most specific match possible (longest).
I've tried to express this in terms of (my funky) pseudo code.
First, the device is matched against a driver.
if ! match idVendor/idProduct/bcdDevice
match idVendor/idProduct
If we match, then we call a driver function. The device probing function
may proactively claim interfaces. It may also change the default
configuration.
Next, the interfaces are matched against a driver.
function matchinterface
if claimed interface
return
for each alternatesetting do
if match bInterfaceClass/bInterfaceSubClass/bInterfaceProtocol
return
if match bInterfaceClass/bInterfaceSubClass
return
if match bInterfaceClass
return
altclaimed[alternatesetting] = driver
rof
driver = findhighestpriority altclaimed
return driver
noitcnuf
if numclaimedinterfaces > 0 then
for each interface do
matchinterface
rof
else
for each interface in configuration[default] do
matchinterface
rof
i = 0
while numclaimedinterfaces == 0 and i < numconfigurations then
if i == default
next configuration
for each interface in configuration[i] do
matchinterface
rof
i = i + 1
elihw
fi
Drivers won't have specific interface probing functions anymore, they will
have a _connect function which gets called after the election process and
a driver has been selected for the interfaces. From the _connect function,
any remaining unclaimed interfaces may be claimed (is this last part
needed?).
If a device probing function claimed some interfaces, _connect will be
called on those interfaces as well.
Here's an pseudo hypothetical example configuration:
Driver audio.o
bInterfaceClass 0x01
Driver printer-unidirectional.o
bInterfaceClass 0x07
bInterfaceSubClass 0x01
bInterfaceProtocol 0x01
Priority 10
Driver printer-bidirectional.o
bInterfaceClass 0x07
bInterfaceSubClass 0x01
bInterfaceProtocol 0x02
Priority 20
Driver uss720.o
idVendor 0x047e
idProduct 0x1001
Driver uss720.o
idVendor 0x0557
idProduct 0x2001
This allows a variety of scenarios:
- A driver can be created to override a class driver if the device isn't
quite to spec (or for other reasons). This is without mandating the
driver get loaded before/after another driver (as with the currently
implemented code does) or has a vendor defined interface which is
preferred over the class defined interface (more features, etc)
- A device specific driver can claim interfaces (which can be set as
vendor class 0xFF) and a class specific driver can claim another
interface. The philips webcam would be an example where this would
be useful (the camera and audio portions).
- An interface with multiple alternate settings, with different
class/subclass/protocol triplets can be elected properly (I have a
printer port which provides a vendor alternate interface, a
unidirectional alternate interface and a bidirection alternate
interface) via the priority
Should we make decisions on which configuration to use based on the MaxPower
(or other attributes) defined by the configuration?
This was a rough first draft. Any comments/opinions?
JE
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
