>>You need the ability to reidentify for simple things like setting the >>correct IP on the correct network adapter, or correct resolution >>on the correct camera. > > I agree. Then use something unique in the device like I said in a > different message: device physical path, serial number, mac address, fs > label, etc.
For network devices this is exposed through struct ethtool_drvinfo; there's a bus_info field. In 2.5 most of the USB networking drivers (it should be/become all!) use this to advantage; there's a new API, usb_make_path(), that provides a stable physical path. Admittedly many userspace tools ignore that, as well as the ethernet address, in favor of nasty unstable names like "eth0". But I know that somewhere there's a tool that'll rename interfaces, so that those tools which expect "eth0" style names to be stable won't need to break too badly ... :) > But only use the physical path if that's your last resort, as it's the > most unstable. This is the main reason the USB printer spec started > specifying that all USB printers need to have a serial number. To help > uniquely identify them. Actually in the "typical" suspend/resume case (like powerdown overnight, or over lunch) I think the physical path is unlikely to change. Though there are certainly cases like suspend, carry laptop to new site, hook up to new printer ... so it's certainly true that it's a good idea to use the physical path in conjunction with other data (like device vendor and product IDs) if that's all you have to work with. - Dave _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
