David Brownell wrote:
Though I'm not real useful when it comes to contributing code at this time, I'd like to add my voice to those that feel the lack of decent topological names has real user impact and limits usability.Oliver Neukum wrote:Removals? Additions? Comments?Yes, I'll be glad to see more of the usbcore cleanups happen. Here are a random bunch of things - Someone just emailed me for help on that classic, and still unresolved, issue of associating a device from 'lsusb' (etc) with the right /dev/... printer node. This is largely an issue usbcore (or the driver model) should solve; it's not specific to printers (or scanners, or any other driver).Not terribly specific to USB. That's why driverfs was invented, wasn't it?But it's still un-resolved, and we _know_ this is an end-user configurability (usability) issue already. More impact than many other problems that get discussed here... And near as I can tell, NO driverfs hasn't wanted to solve this in any general way; that'd be "devfs", maybe. Though I've seen some block devices showing up through symlinks whose basenames match /dev/... node basenames, and that might be useful.
For us it isn't printers, but rather serial ports.
I've been told that driverfs will do this. I don't know its state.
We can use /proc/tty stuff in 2.4.20 (not sure when it was added) but would _MUCH_ rather see something that looks like the symlinks of devfs. This way COTS software will work properly without modification.
Currently we are using a 2.4.17 kernel with a disgusting hack to the usb serial driver that puts symlinks in /dev (hard coded) when usb serial ports come and go. This is decidedly sub-optimal but we are getting by.
We are resolving some issues with 2.4.20, but when that is done we will update our software to use a library function to look up the dev name by looking in /proc/tty/driver/usb. But this seems like a hack and requires putting annoying wrappers around software that isn't easily modified. It generally makes programs very Linux/USB/TTY specific. Even wrappers have their limitations.
To generalize what I'd like to see, it would be a tree that starts with the bus type (PCI, USB, etc) and bus number (USB-0, etc) and then a directory path that represents the ports or slot numbers until you get to the device. For USB I'd like to see an entry in that directory for each USB endpoint.
The way devfs works looks very much like what I want.
...but I suppose I can like and want as much as I'd like until I contribute some code. ;-)
Thanks!
Ty
--
Tyson D Sawyer iRobot Corporation
Senior Systems Engineer Military Systems Division
[EMAIL PROTECTED] Robots for the Real World
603-654-3400 ext 206 http://www.irobot.com
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel