On Tue, 28 Apr 2009, David Brownell wrote: > On Tuesday 28 April 2009, Guennadi Liakhovetski wrote: > > > > > > > > > and then you would need a user-space daemon to implement the actual > > > > protocol. How would this be any better? > > > > > > It might be easier to do some things in-kernel. I/O wise, > > > doing zerocopy to/from userspace for USB is not easy ... so > > > low overhead filesystem access is easier from the kernel. > > > That matters for handhelds with teensy weensy batteries. > > > > ...running Linux?...:-) > > Is there anything else to run? :) I heard some mentioning of something else they used on some of those "teensy-weensy" devices:-) > > > Doesn't PTP require a byte stream interface? > > > > No, there're no isochronous endpoints, if that's what you mean, no > > streaming. Just commands and data blocks. Even capture of multiple images > > handles each image separately. > > I meant as in contrast to packet boundaries mattering. > If C[01234..][abcd...] are successive parts of commands > labeled C[01234..], consider two packet streams: > > P0: C0a C1a C2a C3a > P1: C3b > P2: C3c C4a > > versus > > P0: C0a > P1: C1a > P2: C2a > P3: C3a C3b > P4: C3c > P5: C4a > > Given a byte stream, it's always "C0a C1a C2a C3a C3b C3c C4a". > > But given a packet stream, you've got to parse packets and cope > with multiple commands per packet, multiple packets per command, > and combinations thereof. Doable, sure. But it complicates > what would otherwise be very simple. It's not that complicated. I seem to remember reading somewhere in the standard, that at least the USB implementation should not (or must not, or may not) queue commands, i.e., it is always request-response. And the host must not send the next request until it gets a response to the previous one, maybe only in timeout cases some sort of a reset. So, at least you do not have to extract multiple commands from one packet. > > > The flexibility would come from being able to hook up to > > > more kernel modules -- simple gadget, or various flavors > > > of composite. > > > > I see, but that would be a different project, I guess:-) > > I suspect you could easily have a common core of code, though. Yes, that might be possible. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@xxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
