On Tuesday 07 September 2010 21:13:25 Nick Hibma wrote:
> >>>> 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.

I think we should use the following format:


Then you can match by ugenX.Y unit. Possibly we could add this information to 
the processing event.

I would like to avoid having too much information in the device name, which is 
not really needed.

Then we can also remove the unit allocator in usb/serial/usb_serial.c .

> 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.

You mean in the device name, not in the inode?

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

Please send a patch for review.

freebsd-usb@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Reply via email to