Hi, >-----Original Message----- >From: ext Patrick Ohly [mailto:[email protected]] >Sent: Friday, January 14, 2011 9:22 PM >To: Kavuri Sateesh (Nokia-MS/Bangalore); [email protected]; >Kodihalli Deepak (Nokia-MS/Bangalore); Puranik Santosh >(Nokia-MS/Bangalore); [email protected]; >[email protected]; [email protected]; >[email protected]; Duggirala Karthik.2 (Nokia-MS/Helsinki) >Cc: MeeGo-dev; Drews, Paul >Subject: Buteo MTP + gadgetfs > >Permissions >=========== > >Currently the code runs as part of mtp_test when started as >root. That's necessary because /dev/gadget must be >read/writable. But eventually the code needs to run as plugin >as normal user inside msycnd. Initially the process accesses >/dev/gadget/<driver> to configure USB, then some new entries >(like /dev/gadget/ep-a) which are created by gadgetfs based on >that configuration. We could do a "chmod" as root to grant the >msyncd process read/write permission for /dev/gadget/<driver>, >but that doesn't help with the additional files, which are >exclusively for root. If anyone knows how to solve this, >ideally without patching the kernel, please speak up...
This can be done by writing a udev script where you can set the required permissions, add the files to a group, etc. >Starting the MTP server plugin >============================== > >mtp.xml specifies: ><profile name="mtp" type="server" > > <key name="usb_transport" value="true"/> </profile> > >Under which circumstances will that server be activated right >now in MeeGo's msyncd? If I read the buteo-syncfw code >correctly, it would be activated if USB gets connected, which >in turn is detected if usbmoded support is enabled - which as >far as I know, is not the case in MeeGo because usbmoded is >not in MeeGo. Yes, usb_moded is not in meego, but I hope that doesn't mean that USB connectivity can't be determined. >Would it be acceptable to create a pseudo >Sync::CONNECTIVITY_ALWAYS transport? A server plugin >specifying that in its XML config then would be activated as >soon as msyncd starts and remain active as long as msyncd >runs, and mtp.xml could be changed to use that. That's already there, but it would be pointless to load the MTP plug-in always. >Paths, configuration >==================== > >Why is /usr/share/mtp/deviceinfo.xml copied to >/home/user/.mtpdeviceinfo.xml? The code says that it must be >writable, but it did not become clear to me why the file must be >writable: That's because device properties can be get/set by the initiator. We need to store them persistently if there's a change. >How can the /home/user/MyDocs path be made >configurable? Would deviceinfo.xml be a good place? /home/user/MyDocs represents the "root" of a storage, as defined in the MTP1 spec. We can have multiple storages, and each would have their own root. The root can even be an abstraction, for eg if we have a contacts storage. However, deviceinfo.xml would not be the right place for this. I agree that a storage plug-in should declare it's root, so we need a confguration scheme for storage plug-in's now. As of now, as you know, we have only one storage plug-in. >"media" and "Phone Memory" are also hard-coded as description >of that directory. Are these presented to the MTP host? Yes, they form part of the storage info as specified in MTP1. >What about providing access to more than one directory? Sorry, I didn't understand. Do you mean more than one root, if so that's possible of course via multiple MTP storages, or do you mean multiple directories under the root? The latter works of course, because everything under the root is enumeratable. >Are symbolic links followed? In other words, if I set up > ~/MyDocs/ > Videos -> ~/Videos > Pictures -> ~/Pictures > Music -> ~/Music > ... >would that provide access also to the content of ~/Videos and >~/Pictures? Yes, it could be prevented by the storage though. The initiator wouldn't know, as the purpose of the MTP storage is to abstract the internals. >The code currently tries to load the libfsstorage.so module >from /usr/share/mtp, but it is installed in /usr/lib/mtp, >which is indeed where it should be. Okay to change the code? Yes. >MTP transport API >================= > >This is from an email that Paul sent privately earlier, still >needs an answer as far as I know. > >---------------------> snip <-------------------------- > >I [Paul] ran into a design issue around Zero-Length-Packets >while doing this. The USB spec (paraphrased) says that >transfers exceeding 1 packet size get transmitted and ended as follows: > >() All packets up to the last shall be the maximum packet >size. If your higher-level protocol lets you know the size of >the transfer ahead of time (e.g., fixed-size, info from a >prior transaction, etc.) then you are done when all the data >is transferred. No additional logic or packets necessary. > >() However, if you don't know the length ahead of time (e.g., >the length is variable, or the sender decides to truncate >early) then the transmission ends when a shorter-than-maximum >packet is transmitted/received. This works great unless the >whole transmission is an exact multiple of the packet size in >which case: > >() A Zero-Length-Packet is transmitted/received to mark the >end. This is really just a special case of the "short packet" >rule preceeding. > >A USB 2.0 clarification document points out that this same >batch of rules apply for bulk, interrupt, and control >endpoint. The issue doesn't really arise for isochronous >endpoints. In the case of MTP protocol, I think only the bulk >endpoint(s) can actually encounter this issue, since all the >control and interrupt messages "fit" into a packet. > >The MTPTransporter super-class defines a defaultable boolean >in its "sendData()" (bulk data) method to call for a a >Zero-Length Packet (comments are a bit ambiguous). In the >MTPTransporter subclasses, this parameter has been turned into >a "isLastPacket" boolean (undocumented). >Apparently the design intentions were as follows: > >(1) Make the MTPResponder layer (above MTPTransporter) be >independent of what sort of transport is underneath. For >example, if it is Bluetooth which supposedly doesn't have this >Zero-Length-Packet nonsense, then MTPResponder shouldn't have >to know the difference or do anything different. > >(2) Make MTPTransporter know strictly about the transport, >with no knowledge of the higher-level protocol that it is transporting. > >The trouble with this is that MTPTransporter (subclasses) then >cannot know when they should send a Zero-Length-Packet. When >sendData() gets called with "isLastPacket" set to true, the >implementation does not know whether this is (1) the end of a >known-length transmission so no ZLP is required, or (2) the >end of a unknown-length transmission so a ZLP is required if >we're right at a packet-size boundary. > >I'm starting to come around to the belief that the >MTPTransporter (sub) class can't figure this out on its own. >I think the higher-level MTPResponder really needs to know >about the Zero-Length-Packet requirement and tell >MTPTransporter about it when needed. > >I'm flexible how this could happen. It could be (1) MTPResponder calls >sendData() with a pre-formatted Zero-Length-Packet when needed, (2) >sendData() adds a new "please add a ZLP" parameter and the >Transporter creates and sends one, (3) a whole new >"sendZeroLengthPacket()" function gets added to the >MTPTransporter superclass, called by MTPResponder when needed, >and subclasses either send such packets or do a no-op >depending on actual underlying medium, (4) or some other cool >solution. Opinions? > >---------------------> snip <-------------------------- The MTP stack (MTPResponder, MTPTransporter) doesn't know about ZLPs/SLPs, nor should it care. All the stack should take care of is that the underlying transport shouldn't alter the integrity of the MTP packets. For eg if the reponser is sending data for a GetObject operation, once the data is sent, it sends a response. Both the data and the response go over the bulk pipe in USB. Now if the USB driver were to combine the data and response packets, due to buffering for eg, and for the fact that the driver can't distinghuish between these packets, then the initiator wouldn't make sense of this combined packet it receives, So the stack is responsible for asking the transport to do an "fsync", if I can put it in that way, basically send everything that it might have buffered before proceeding to send the next packet (so the stack has to do this after sending data for a GetObject). Currently we do call fsync this way, and our USB MTP driver checks whethet the packet it sends lies on the USB max packet size boundary (a multiple of 512 bytes), in which case a ZLP is needed, otherwise we automatically have a SLP, and nothing extra needs to be done. >-- >Best Regards > >Patrick Ohly >Senior Software Engineer > >Intel GmbH >Open Source Technology Center >Pützstr. 5 Phone: +49-228-2493652 >53129 Bonn >Germany Regards, Deepak _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
