> OK. Well, the usage he wants is something that is better fitted by > using sysfs info. There, you should have all information to uniquely > identify a device: driver, bus location (on PCI this can be relevant), > MAC (for dvb devices), etc. IMO, the proper way is to add the serial > number at sysfs, and let the bus_info point to the proper bus > location. Having the bus location, an userspace app can seek the > sysfs and look for the udev info. > > For example, on an em28xx analog device I have here, bus_info returns > "1-3". Ok, this is a very bad way to specify the bus. IMO, we should > use usb_make_path() to generate the canonical name for USB buses. > > Anyway, by getting this information, and looking at sysfs, we'll see > lots of very useful information [1]. > > By parsing the info, we know that: > the v4l driver is em28xx; > the audio driver is snd-usb-audio (card1); > the event interface is input10; > this device uses two i2c modules: saa7115 and tuner; > the device has no dvb interface. > > It should be easy to extend it to provide more info, like the serial > number. This will also help udev to create a permanent name for the > known devices, as it does with internet interfaces. > > Cheers, > Mauro Hi, I'm the originator of this topic. Sorry, but I don't agree here. If I start to parse the bus_info string, my app will only work with device-drivers which return a canonical sysfs-path here. To achive this, actually a new field in the capability-struct must be defined, because the specs don't put any contrains on the bus_info-string. (some space is left there) And even if I parse the string to somehow obtain a sysfs-path, then I have to distinguish devices which have a serial-no and which don't. This leads to a unmaintainable situation. What bus_info must be to make it of any use is that it must contain a string that won't change if the device reconnects (at least to the same port; manually or due to system-wakeup) A driver can do its best guess here (serial-no, slot or *constant* USB-port or whatever) I think this is the *only* V4L2-conforming solution to the problem. Regards, Carsten -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
