David Brownell wrote:
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.
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.

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

Reply via email to