USB serial device naming

[Nick Hibma]

>>>> Maybe you can make PR on the issue and assign it to USB. Currently there is
>>>> no way of knowing which /dev/cuaUXXX belongs to which USB device. Probably
>>>> we can add the USB bus and address number as a part of the device
>>>> coordinates. So that /dev/ugen1.1 only creates /dev/cuaU1.1.xxx entries.
>>>> And then we can also remove the current unit number allocation structure I
>>>> guess, if we use:
>>>> 
>>>> /dev/cuaU1.1.<iface_number>.<optional_sub_modem_unit>
>>>> 
>>>> The only problem is: Will we break any existing applications?
>>>> 
>>> 
>>> Well, yes, to some extent :) Problem with this naming convention is name 
>>> changes with every port change - that is, if you pull USB cable out and plug 
>>> it in another port. There was already some older thread about naming on 
>>> freebsd-usb list (end of April 2009). But if devd receives all necessary 
>>> informations in attach event, then it is possible to rewrite config files or 
>>> create symlink in /dev directory or something like this to handle this 
>>> situation.
> 
> I think better way is use device connection path in name.
> User know to which port of hub they attach device, so name like /dev/cuaU.h0p1.h2p3 (root hub 0, port 1, hub 2, port 3 ) have all
> information user need and this name not changing between reboot`s.
> May by we have way make naming more simple, but we really need path somewhere in device name.

Two things are needed:

1) path to the device so you can distinguish two identical devices.

2) map u3gN to cuaUX.Y

My problem is the latter:

Processing event '+u3g0 vendor=0x0af0 product=0x7601 devclass=0xff devsubclass=0xff sernum="" release=0x0000 intclass=0xff intsubclass=0xff at port=2 interface=0 vendor=0x0af0 product=0x7601 devclass=0xff devsubclass=0xff sernum="" release=0x0000 intclass=0xff intsubclass=0xff on uhub1'
Pushing table
setting device-name=u3g0
setting vendor=0x0af0
setting product=0x7601
setting devclass=0xff
setting devsubclass=0xff
setting sernum=
setting release=0x0000
setting intclass=0xff
setting intsubclass=0xff
Processing attach event

How do I get to the cuaU10.0 device here? As far as I can see there is no way to do this. 

The main problem is the strange way the minor number is assigned to the cuaU device. But having the major and minor numbers for the cuaU device per u3g instance would be sufficient. Through a sysctl for example, or as extra information in the attach.

If no one objects I will submit a patch to resolve problem 2).

Nick