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 >
Hi, > 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: cuaU<bus>.<addr>.<iface>[.<sub_unit>] 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. --HPS _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"