On Mon, Jun 30, 2003 at 10:21:20PM -0400, Bill Nottingham wrote:
> David Brownell ([EMAIL PROTECTED]) said: 
> > > For any device X-Y in /sys/bus/usb/devices, it appears
> > > X-Y:Z/name gives either "Hub", or "usb_make_path() interface Z".
> > 
> > Or whatever that interface's iInterface string provides,
> > or that interface's driver puts there.  Those are purely
> > descriptive strings, ideally meant to be read by users,
> > and they're not to be interpreted by programs.
> 
> Great, random strings are always useful. I thought the idea
> of sysfs was for a uniform interface, because /proc was
> full of random nonstandard crap.

sysfs shows the topology of where all of the usb devices are in the
system.  And yes, that topology changes based on what drivers were
loaded in what order, but that's just a usb issue.   You can still
retrieve the physical topology of a usb device, which does not change
(but remember that pci ids can also change, so it's not a perfict
topology.)

> > >>(Any more than "ethN" identifiers are:  they depend on the
> > >>order in which devices are initialized.)
> > > 
> > > That's easily enough fixed, though, for ethernet devices.
> > 
> > Using, as I pointed out, something like "nameif"; or
> > like "ip link ethN set name=newname" ... "nameif" would
> > seem to address the issue you said you'd set out to
> > solve.  Though I don't seem to recall any major distros
> > had started to use it.
> 
> Yes, that's what I was getting at.
> 
> > > 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.
> 
> 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.

Because PCI has a relativly sane way to describe devices as compared to
USB :)

thanks,

greg k-h


-------------------------------------------------------
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

Reply via email to