[Qemu-devel] USB MTP emulation state?

[Qemu-devel] USB MTP emulation state?

[Paolo Bonzini]

I took a quick look at the MTP emulation and the first things I noticed are:

* all I/O is synchronous
	>> I guess this is just a limitation of the code

* it doesn't use the -fsdev infrastructure
	>> Perhaps we should rename the "root" property to
	   x-root to identify it as experimental?

* it doesn't do writes
	>> No idea if this is a limitation of the protocol

Anything we can do before 2.1 is out?

Paolo

Re: [Qemu-devel] USB MTP emulation state?

[Gerd Hoffmann]

On Fr, 2014-07-18 at 15:25 +0200, Paolo Bonzini wrote:
> I took a quick look at the MTP emulation and the first things I noticed are:
> 
> * all I/O is synchronous
> 	>> I guess this is just a limitation of the code

Correct.

USB subsystem allows to kick off I/O & return (with the special return
code USB_RET_ASYNC), then signal completion for the usb packet later,
using usb_packet_complete().

usb-storage does this for example.

> * it doesn't use the -fsdev infrastructure
> 	>> Perhaps we should rename the "root" property to
> 	   x-root to identify it as experimental?
> 
> * it doesn't do writes
> 	>> No idea if this is a limitation of the protocol
> 
> Anything we can do before 2.1 is out?

Given that we are in hard freeze renaming the root property to move it
into experimental namespace is the only reasonable thing IMO.

A while back I've mailed with Stefan (Cc'ed) a bit about fsdev.  Using
fsdev looks obvious.  But when looking closer again it isn't that clear
any more whenever is a good idea or not as there are a few differences
between mtp and a real filesystem.

You'll go read / write complete files with MTP.  Random access to files
is limited.  There also isn't a concept of ownership and access rights
for files, beside the very basic "file is writable/readonly".  So the
uid mapping fsdev provides doesn't buy us much for MTP, especially not
for readonly access.

Write access is in the protocol.  You don't want only read photos off
your phone, you also want copy your music to it ;)  But, again, without
fine-grained access control.  So I'm not sure how to implement that best
in qemu.  Maybe enabling write access is the feature which tips the
balance to favor fsdev as we might be able to offload most of the write
access control handling (+configuration) to fsdev.  Didn't investigate
in detail yet though.

cheers,
  Gerd

Re: [Qemu-devel] USB MTP emulation state?

[Paolo Bonzini]

Il 21/07/2014 11:12, Gerd Hoffmann ha scritto:
> On Fr, 2014-07-18 at 15:25 +0200, Paolo Bonzini wrote:
>> I took a quick look at the MTP emulation and the first things I noticed are:
>>
>> * all I/O is synchronous
>> 	>> I guess this is just a limitation of the code
> 
> Correct.
> 
> USB subsystem allows to kick off I/O & return (with the special return
> code USB_RET_ASYNC), then signal completion for the usb packet later,
> using usb_packet_complete().
> 
> usb-storage does this for example.
> 
>> * it doesn't use the -fsdev infrastructure
>> 	>> Perhaps we should rename the "root" property to
>> 	   x-root to identify it as experimental?
>>
>> * it doesn't do writes
>> 	>> No idea if this is a limitation of the protocol
>>
>> Anything we can do before 2.1 is out?
> 
> Given that we are in hard freeze renaming the root property to move it
> into experimental namespace is the only reasonable thing IMO.

Sounds good, thanks!

Paolo