>> 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 > > 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.
Yes. We need a mapping from vendor/product/rev -> /dev/ entry and from location -> /dev/ entry. Adding this cuaU<bus>.<addr>.<iface> string (not the absence of the sub_unit) to the event would resolve both issues 1) and 2). /me starts handing out paint and pencils for the bike shed painting to come... >> 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? Device name, right. The mknod stuff is too old to be wrong... > Please send a patch for review. Will do in the next two weeks. 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"
