Harry Butterworth wrote:
I created a new bus device to represent a virtual bus where each USB
back-end will be represented as a device.
[Harry, not sure I understood your scheme fully, so excuse a few
I'm assuming that means: real USB Device = 1 backend?
Does this need to remain USB specific or could this
virtual bus be generalized to include a broader range
I created a new device for the above bus to represent a USB back-end.
So this is something present only on dom0/driver domains?
I'm a little confused by what the guest domains (front-end
domains) see as a device(?).
I created a new driver to drive instances of the above devices. The
driver creates a new virtual USB host controller for each device
instance (i.e. one per back-end). The virtual USB host controller is
created using the USB hc_driver interface which is new to 2.6 and
eliminates redundancy in the host controller driver implementations.
This framework is all present in a single loadable module and currently
loads into 2.6, installs the bus and driver and a dummy device, the
Also works compiled into the kernel?
driver gets matched to the device and successfully creates a virtual USB
host controller. All the objects appear in sysfs OK.
Next step is to create a test machine with a 2.4 dom0 and working USB
devices and construct the 2.6 front end within the new 2.6 framework by
porting forwards the remaining function from the 2.4 code.
Will 2.4 backends be compatible with your new 2.6 frontends?
After that I'll work on the 2.6 back end which I expect to be easier.
Did you mean 2.6 backend (which you said you had) or 2.4?
I'm expecting to have to make changes to this new code for the new
persistent store mechanism for discovery and hotplug. Specifically, I'm
expecting that the new bus device will probably be moved out of the usb
front end driver and made common between all xen virtualised devices and
that this bus will perform discovery using the persistent store.
Ah, good. Is anyone working on a new virtual bus infrastructure?
Once I'm done with both the 2.6 back and front end code I'll look at
commoning up code between the 2.4 and 2.6 drivers.
The expectation is that all the following permutations:
2.4 be <-> 2.4 fe
2.6 be <-> 2.4 fe
2.4 be <-> 2.6 fe
2.6 be <-> 2.6 fe
Any comments on approach etc welcome.
Very interesting so far, Harry.
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.
Xen-devel mailing list