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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <54F70E3D.20201@citrix.com>
Date:	Wed, 4 Mar 2015 13:53:01 +0000
From:	David Vrabel <david.vrabel@...rix.com>
To:	Juergen Gross <jgross@...e.com>, <linux-kernel@...r.kernel.org>,
	<xen-devel@...ts.xensource.com>, <konrad.wilk@...cle.com>,
	<boris.ostrovsky@...cle.com>, <linux-usb@...r.kernel.org>,
	<gregkh@...uxfoundation.org>, <cyliu@...e.com>
Subject: 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/