Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend

[David Vrabel <david.vrabel@citrix.com>]

On 04/03/15 13:31, Juergen Gross wrote:
> On 03/02/2015 12:39 PM, David Vrabel wrote:
>> On 26/02/15 13:35, Juergen Gross wrote:
>>> Introduces the Xen pvUSB backend. With pvUSB it is possible for a Xen
>>> domU to communicate with a USB device assigned to that domU. The
>>> communication is all done via the pvUSB backend in a driver domain
>>> (usually Dom0) which is owner of the physical device.
>>
>> Why do we need a kernel usb backend instead of a user-space one using
>> libusb?
> 
> Good question. At a first glance libusb seems to offer most/all needed
> interfaces. The main question is whether performance with libusb will
> be okay. There will be one additional copy of the I/O data needed if
> I've read the code in drivers/usb/core/devio.c correctly.
> 
> I haven't worked with user space backends yet. Do you recommend a
> special example I should start with?

Perhaps the block backend in qemu?

>>> Changes from the original version are:
>>> - port to upstream kernel
>>> - put all code in just one source file
>>
>> ?? I'm not sure that was an improvement.  The resulting single file is
>> too large IMO.
> 
> OTOH this reduces overall code size:
> 
> New file has 1845 lines, while old version had in sum 2243 lines with
> the largest file having 1217 lines. So the largest file is 50% larger,
> while overall size is 20% smaller.

I think I would have preferred the original large file split up (if
there's a sensible functional grouping of the resulting bits).

If, after considering a userspace backend, you think that this kernel
one is the way to go I'll give it another look and see if I can suggest
a suitable split.

>>> - move module to appropriate location in kernel tree
>>
>> drivers/xen/ is the correct location for this driver.
> 
> Hmm, so you regard placement of xen-netback under drivers/net and
> xen-blkback under drivers/block as wrong? I've just followed these
> examples.

usbback is just a regular USB device driver and most of these don't live
under drivers/usb/ but in the subsystem for the type of device they're
providing (which in this case is a Xen backend, hence drivers/xen/).

David