***********************
Warning: Your file, usb-virt-2.6.tar.bz2, contains more than 32 files after
decompression and cannot be scanned.
***********************
Hi Mark,
Currently I have a working 2.6 USB driver which is based on a
snapshot of Xen unstable from a few months ago (before the big xend
change). I need to update it to the current tree but I''m waiting for
the Xenbus stuff to stabilise a bit.
I was wondering if you''d like to review the code in its current
form
anyway. I think it would be useful for me for someone else to give it a
once over.
The structure of the code is basically as follows:
In the front-end...
The front-end code has a bus type and discovery code which discovers
connections to back-ends.
The discovery code allocates usbfront_device devices on the bus to
represent the connections to the back ends.
The usbfront_device code presents an interface that looks a bit like
a hardware USB host controller device and contains code which detects
the presence of USB back-end devices by polling the back-end.
The bus code matches the usbfront_device devices with the
usbfront_driver device driver.
The device driver drives the devices by allocating an instance of a
USB host controller device driver to each device.
The USB host controller device drivers make use of the
usbfront_device interface to detect connected USB back-end devices and
receive URBs from the Linux USB stack and allocate a
usbfront_hcd_resource to process each URB.
The usbfront_hcd_resource translates the URB into a
usbfront_device_request and submits the request to the usbfront_device.
The usbfront_device sends the request to the back-end.
In the back-end...
The back-end code has a bus type and discovery code which discovers
connections to front-ends.
The discovery code allocates usbback_device devices on the bus to
represent the connections to the front ends.
The bus code matches the usbback_device devices with the
usbback_driver device driver.
The device driver drives the devices by allocating a
usbback_driver_backend for each device.
Each usbback_driver_backend has a number of usbback_driver_ports
each of which can manage one USB device.
Usbback_driver_ports are attached to USB devices according to the
claim and release port messages originating in the xend code.
The usbback_device receives requests from the front-end and forwards
them to the attached usbback_driver_backend which forwards them to the
appropriate usbback_driver_port according to the USB device address.
The usbback_driver_port allocates a usbback_driver_port_resource to
process each request.
The usbback_driver_port_resource makes use of the usbback_mapper
service to map FE domain memory as appropriate and translates the
request into an URB then submits it to the Linux USB stack.
Completions go back the other way.
The python code in the middle (usbif.py) hooks together the FE and
the BE and the xend USB configuration code. Most of the complexity in
this code is in the UsbifBackendInterface state machine which is
generated automatically by compiling and executing
usbif_interface_enumerator.c. The current form of this code was just a
first pass and is pretty ugly---for example, the state machine is about
3x bigger than it could be. I stopped working on it when it was good
enough for testing the driver FE and BE because it''s going to be
discarded during the sync-up with the new xend and Xenbus code.
The usback_callback and usbback_work code is a little bit of
infrastructure to make the rest of the code easier.
Any feedback welcome!
Harry
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel