On 16/06/15 15:56, Juergen Gross wrote:
>
> Hmm, I'm beginning to question the value of that file. May be I should
> just throw it away.
>
> Thanks for the quick feedback.
You could move it to debugfs, but if it's not useful better to get rid
of it.
David
--
To unsubscribe from this list: send
On Tue, Jun 16, 2015 at 04:56:35PM +0200, Juergen Gross wrote:
> Hmm, I'm beginning to question the value of that file. May be I should
> just throw it away.
Given that you are going to have to justify every one of them, and
ensure that you are creating them in a race-free manner (I didn't look
to
On 06/16/2015 04:45 PM, Greg KH wrote:
On Tue, Jun 16, 2015 at 04:32:34PM +0200, Juergen Gross wrote:
Introduces the Xen pvUSB frontend. 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 drive
On Tue, Jun 16, 2015 at 04:32:34PM +0200, Juergen Gross wrote:
> Introduces the Xen pvUSB frontend. 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 o
Introduces the Xen pvUSB frontend. 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.
The pvUSB frontend is a USB hcd for a vir
