Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 21 Mar 2004 08:11:01 +0100
From:      Bernd Walter <ticso@cicely12.cicely.de>
To:        "M. Warner Losh" <imp@bsdimp.com>
Cc:        ticso@cicely.de
Subject:   Re: Opinions about using USB serial numbers
Message-ID:  <20040321071100.GH33602@cicely12.cicely.de>
In-Reply-To: <20040320.184336.88475380.imp@bsdimp.com>
References:  <20040320052007.GC33602@cicely12.cicely.de> <20040320.184336.88475380.imp@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 20, 2004 at 06:43:36PM -0700, M. Warner Losh wrote:
> In message: <20040320052007.GC33602@cicely12.cicely.de>
>             Bernd Walter <ticso@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@bwct.de                                  info@bwct.de



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040321071100.GH33602>