Opinions about using USB serial numbers

[Bernd Walter]

On Sat, Mar 20, 2004 at 06:43:36PM -0700, M. Warner Losh wrote:
> In message: <20040320052007.GC33602 at cicely12.cicely.de>
>             Bernd Walter <ticso at cicely12.cicely.de> writes:
> : I have a lot to do with systems using many USB devices of the same
> : kind.
> : Currently device are named acording to their probing order.
> : That result in the problematic that device names can change after
> : reboot or replugging in different order.
> : 
> : I would like to add functionality for creating alias devnodes
> : including the serial numbers (if the device has one setup).
> : E.g. for a ucom(4) device you will get /dev/ucom0 and ucom.serialnumber.
> : If the device has no serial numer there will be just /dev/ucom0
> : as befor.
> : 
> : Another solution could be to create the nodes in a tree form:
> : /dev/usbchannel0/hubport1/pubport2/ucom
> : That would work for devices without serial numbers too, but I
> : personally dislike this way.
> 
> I'd rather that we have a generic binding of a device instance number
> to a pnp location.

Currently we have non really working - even cam binding is evil
because it's a boot time only.

> However, having said that, you can use devd to extract the information
> from the node and then create a symbolic link...

OK - lets try it with devd.
Usefull devd support is required anyway.

That's what I get on plugging in a device:
Processing event '? at  on uhub2'
Pushing table
Processing nomatch event
Popping table
Processing event '+ubser0 at  on uhub2'
Pushing table
device-name=ubser0
Processing attach event

I think the '?' one is because no driver attaches at device level.
ubser is an interface level driver as most USB ones.

What I need is the following for devices:
vendor-id, device-id, device-class, device-protocoll, vendor-string,
device-string, serial-id.
At interface level additionally:
interface-class, interface-subclass, interface-protocoll,
interface-string.

I've seen some places where bus_child_pnpinfo_str() and
bus_child_location_str() was used for extended informations.
Is this all I have to implement?
Can I put the above data in it or are there any restrictions?
It seems that dv_pnpinfo[128] could be to small for all of them.
We can discuss if strings are required, but also USB serial number
is a (unicode)string and strings can be 254 bytes long.
What about whitespace in strings?

Does usbd still serve any usefull purpose after having the above data
via devctl?

-- 
B.Walter                   BWCT                http://www.bwct.de
ticso at bwct.de                                  info at bwct.de