On Do, 2011-01-20 at 10:26 +0000, Patrick Ohly wrote: > On Mi, 2011-01-19 at 01:46 +0000, Tony wrote: > > I am excited about hearing the good news. > > Could you show me when and where i can get the published code? > > The code is public now. We decided to publish the whole development > history of it instead of just the final state. The history contains > useful information about why things were done and some code which did > not end up in the final revision, but might still be useful in the > future. > > Because of the number of patches, please get the code from: > http://meego.gitorious.org/~pohly/meego-middleware/pohlys-buteo-mtp
For those who did not follow the discussion on the corresponding feature entry (http://bugs.meego.com/show_bug.cgi?id=7990), the decision was to not merge the code because the functionfs API is meant to be used in MeeGo. Paul has written up some thoughts about functionfs and why he focused on gadgetfs as a temporary solution. I'm sharing that here with his permission because it might point towards some issues that need to be resolved before functionfs provides everything needed for MTP: -------------------------------------------------------------------- Functionfs does not support asynchronous I/O at least as of the 2.6.37 kernel. The reason this is a big problem for MTP/USB is as follows: The MTP responder is a big single-threaded QT application with a main-loop that normally sits waiting for events, waking up when they arrive, dispatching to handlers for them, and going back to waiting at the central wait-point. The "normal" QT way to read from the file-descriptors representing gadgetfs endpoints is to attach a QSocketNotifier to each one. Under the covers, the QSocketNotifier sets the file-descriptor to non-blocking (O_NONBLOCK), and sets up a select() to get notified of read-readiness, and links this all up to the QT main loop. When incoming data arrives, the QSocketNotifier forwards the trigger to the main-loop, it wakes up and dispatches, the code does a non-blocking read from the endpoint file-descriptor, and handles the message. The trouble is that the kernel code that supports reads and writes for gadgetfs endpoints doesn't support non-blocking I/O properly. The select() notification and associated QSocketNotifier fires immediately and continuously even without data ready to read, and a read() on the file-desciptor blocks waiting for data even with O_NONBLOCK set. This causes the MTP responder to immediately block on a USB endpoint read instead of at its main-loop waitpoint, with dire consequences. What I did in MTPTransporterGadgetfs was use asynchronous I/O to implement my own non-blocking reads with associated read-to-read notification to the QT main-loop. Works great, and has the side-effect that reads are multiple-buffered for performance if needed. I didn't make writes asyncronous I/O double-buffered but this would be easy to do if required to keep the USB gadget-to-host channel busy. This approach will not work for functionfs! Functionfs has essentially the same blocking I/O code for normal reads and writes with the same non-support for non-blocking I/O. But functionfs doesn't support asynchronous I/O as an alternate option. So if you adapted MTP/USB to functionfs, you would have set up threads doing blocking reads from endpoints, then exposing their results and notifications in a non-blocking fashion to the QT main-loop of MTP Responder. This is more complicated than it sounds since reads from ep0 are overloaded to cause STALL or ACK at certain points in the protocol. You don't want to issue them ahead of time (at the wrong time). Even if you get all this right, you're still in the situation where reads/writes are _not_ multiple-buffered in the kernel, so if this is a performance problem it _cannot_ be fixed with functionfs. The current version of functionfs (2.6.37 kernel) is _not_ suitable for buteo-mtp. The original author's functionfs proposal includes a note regarding asynchronous I/O, suggesting that it could be done in the same way as in gadgetfs, but not including it (for now) until such time as a consensus emerges that it would be a good idea. I think this is (1) feasible, (2) a good idea, and (3) a prerequisite for putting buteo-mtp onto functionfs. However this kernel enhancement is way outside the scope of MeeGo 1.2 and buteo-mtp. -------------------------------------------------------------------- -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
