Pete Zaitcev wrote:
I have written a user space device driver which does this mapping of device to portOn Mon, 28 Feb 2005 19:20:41 +0530, <[EMAIL PROTECTED]> wrote:
When I connect USB device it gives device information like,
configuration, interface, and endpoint descriptors. I need bus, level,
and port information to map device files to particular USB port. []
OK, I think I came up with an interpretation which makes sense. All this talk about /proc/bus/usb/devices is irrelevant and muddies waters. In reality Shalini is trying to create a (character) device driver, which provides a bunch of device files, each with a separate minor or a block of minors. Opening one of them takes control of a specific port on the bus. Such facility is usually called "geographic addressing".
This is something terminal server vendors or modem bank vendors would really love, because they want to know what external device is opened when their software opens a device file. But the ttyUSB0 can get mapped randomly.
Stern has explained perfectly already how to extract the information from internal kernel structures. So, I am just going to touch upon the mapping function.
First part is mapping between minors and ports. In 2.4, it can not be done in a generic, pre-determined way in 2.4 because its minor space is too small. By my calculations, if we want to address 4 levels of hubs, with 4-port hubs we have about 380 ports, with 5-port hubs we have about 780 ports and so on. And then we may have a bunch of buses. It is possible to load a narrow mapping from user space, or to restrict the tree height. In latter case we can declare that the geographic addressing simply works with a two level tree only (in 2.4): root hub and one external hub. This is limiting, but has advantages: it needs no scripts, mapping files, hotplug. Unfortunately, I don't think it can be made compatible with 2.6, if 2.6 was to be implemented sanely (see below).
Now, about the mapping between minors and drivers. This is something I wish to defer to Greg. But as an example... We can think of /dev/usbNNNN which opens a port. But then it needs to be linked to a driver to work. I don't like this. Alternatively, we can let drivers like usbserial and usblp to expand their minor space dramatically (and have those minors identically mapped). This will lead to /dev/usb/lp/523140 and /dev/usb/serial/523140 which would drive the device if it was plugged in the same port (not in the same time, obviously...) This minor number can be used by usbfs/libusb, too, for user convenience. The example above uses bus 5, root port 2, 1st level port 3, 2nd level port 1, 3rd level port 4 (and a small bunch of minors left in case devices want to have them). This sounds rather nice to me. Notice that old minor space is automatically deconflicted and continues to be supported.
Now we need to find a victim to code this (unless parts of it are already done - I have no idea how libusb addresses devices - I suspect it uses device numbers). Shalini may be bogged in the 2.4 but he sounds like a natural candidate. He should migrate to 2.6 anyway, even if he's a victim of MontaVista.
-- Pete
number using sysfs and libusb. It creates two threads for reading and writing (replace
with processes/select to your taste) and connects them to a pty on one side and a bulk
in and out port on the other. The program takes the sysfs directory for the device
<busnum>-<port-path> as argument so one instance of the program is necessary for
each connection.
This method has the advantage that after reboot of the usb device the same connection
can be restablished which makes the serial port look very much like a standard RS232
port. It seems also to be faster than cdc-acm because this sets the size of the submitted
urbs to the size of the bulk packet and only one of these requests can be serviced every
frame giving a maximal throughput of 64k/s. My driver reads and writes 4k buffers which
seems to allow at least 900k/s throughput (on a high speed bus).
here is a link:
http://www.murphy.dk/files/ptyusb.c
/Brian
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
