From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755985AbbCDNbN (ORCPT ); Wed, 4 Mar 2015 08:31:13 -0500 Received: from cantor2.suse.de ([195.135.220.15]:42037 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751195AbbCDNbL (ORCPT ); Wed, 4 Mar 2015 08:31:11 -0500 Message-ID: <54F7091C.1050001@suse.com> Date: Wed, 04 Mar 2015 14:31:08 +0100 From: Juergen Gross User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: David Vrabel , 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 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> In-Reply-To: <54F44BD5.1030008@citrix.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? > >> 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. >> - 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. Juergen