I have spent a week trying to work out how to shrink the USB code and how to better integrate the xenidc code with the Xen tree. As part of this I''ve done a sketchy port of the blkback driver to xenidc. I thought I''d post it to the list just in case anyone was interested in having a look. It turns out that the significant difference between usbback and blkback from the xenidc point of view is that the blkback driver implements scatter gather support as a zero copy optimisation whereas the usb driver doesn''t (the linux USB stack requires contiguous buffers so there is no point for USB). To maintain the current zero copy blkback implementation xenidc needs to be extended with a scatter gather remote buffer reference type and I''ve assumed this exists for the blkback code below. Split drivers using the xenidc rbr_mapper_pool will have to pass a parameter indicating whether they are scatter gather capable. The pool will map scatter gather remote buffer references as scatter gather local buffers for drivers which are capable. Conceptually, if a front-end sent a scatter gather remote buffer reference to a non-capable back-end driver the pool would be required to stage the data into a contiguous region. The I/O processing and data transfer/bio creation part of the code below is complete aside from a few FIXMEs (blkback2_resource.c) but the configuration and setup code (blkback2_device.c) is incomplete because I''m simultaneously trying to work out what to do about the xenbus<->driver interface which takes 300 loc to pass two parameters to the blkback/usbback drivers. I''m experimenting with a different xenbus interface which looks a bit more promising but isn''t concrete yet. I''ve managed to cut the usbback code by about half by removing the ability to have more than one port per device (you can have more than one device which gives equivalent functionality) and by factoring out some code which was common between the xenbus based usbback and blkback drivers into the somewhat sketchy new xenbus API. There is still some commonality between the xenidc based blkback and newly shrunken usbback code. This might perhaps be expressed as a base device class from which the usb and blk specific stuff could be derived. The common code is only about 25% and fairly simple though so this might not be a net readability win. In passing, I happened to notice that the real blkback code drops error values on intermediate bio completion which makes it unsafe during back-end I/O errors. The fix is to check the uptodate bit in the bio flags. Enjoy the conference. Harry. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel