From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757564AbbCDNxG (ORCPT ); Wed, 4 Mar 2015 08:53:06 -0500 Received: from smtp02.citrix.com ([66.165.176.63]:40092 "EHLO SMTP02.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757300AbbCDNxE (ORCPT ); Wed, 4 Mar 2015 08:53:04 -0500 X-IronPort-AV: E=Sophos;i="5.09,687,1418083200"; d="scan'208";a="241353330" Message-ID: <54F70E3D.20201@citrix.com> Date: Wed, 4 Mar 2015 13:53:01 +0000 From: David Vrabel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: Juergen Gross , , , , , , , Subject: Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend References: <1424957717-392-1-git-send-email-jgross@suse.com> <1424957717-392-4-git-send-email-jgross@suse.com> <54F44BD5.1030008@citrix.com> <54F7091C.1050001@suse.com> In-Reply-To: <54F7091C.1050001@suse.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-DLP: MIA1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend Date: Wed, 4 Mar 2015 13:53:01 +0000 Message-ID: <54F70E3D.20201@citrix.com> References: <1424957717-392-1-git-send-email-jgross@suse.com> <1424957717-392-4-git-send-email-jgross@suse.com> <54F44BD5.1030008@citrix.com> <54F7091C.1050001@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54F7091C.1050001@suse.com> Sender: linux-kernel-owner@vger.kernel.org To: Juergen Gross , linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com, boris.ostrovsky@oracle.com, linux-usb@vger.kernel.org, gregkh@linuxfoundation.org, cyliu@suse.com List-Id: xen-devel@lists.xenproject.org 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