>>>> 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_______________________________________________ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
