[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |