For keeping track of devices; rather than have one list of network hardware addresses, and one list of usb/pci/pcmcia/etc network devices, it's better to have one list that just has the network hardware address associated with the proper device.
That "one list" is what "nameif" uses: one of all ethernet addresses paired with the link names ("ethN" etc) that some sysadmin said they're supposed to be using.
And no cross-referencing between layers that, by design, are insulated from eacy other ... and remember that not only may "usbfs" not be present, at some point lots of folk hope it will NOT be. It needs replacing; don't build in assumptions that it'll be there forever.
But the layers *are* related. Network devices are, one way or another, directly connected to *some* underlying hardware.
Sure. And the bus_info provides a cookie that identifies that hardware.
To put it a different way:
ethtool for PCI devices has a bus_info field that uniquely describes the associated hardware in a easy-to-access from userspace way. ... ethtool for USB devices has a bus_info field that uniquely describes the associated hardware in a way that's a PITA to assocate from userspace.
Of course, the "usbfs" API itself is the PITA. It's done in terms of a bunch of random identifiers that can (and sometimes do!) change from minute to minute (hub power problems force device re-enumeration, then the IDs change) without user intervention.
The "make_path" IDs are directly comparable to the PCI slot names, in that they relate to the current topology. And they won't change until the hardware reconfigures, so they can be saved and re-used in common configurations.
and the place where it's *easy* in 2.5 to make that association you're telling me I shouldn't rely on.
That is, the "name" field? But as I said, you've been overlooking the true definition of that field, as a "user friendly" name. That's been sysfs, from day one (back when it was "driverfs"). Were you trying to use the "name" field for PCI devices? No? Then why were you trying to do that for USB?
I do agree that and we need something to replace "usbfs", something with better ways to name and address the various components. Heck, just being able to use normal read/write calls to do endpoint I/O would be a major step forward, and it'd involve a complete re-design.
- Dave
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
