On Wednesday 10 March 2010, Roger Quadros wrote: > Hi, > > ext Greg KH wrote: > > On Tue, Mar 09, 2010 at 01:34:07PM -0600, me@xxxxxxxxxxxxxxx wrote: > >> On Tue, 9 Mar 2010 09:44:23 -0800, Greg KH <greg@xxxxxxxxx> wrote: > >>>> Is it good/possible to have these done in existing TTY framework? > >>> No. What's wrong with the gadgetfs interface for custom things such as > >>> this? You shouldn't need a special kernel driver for it, right? > >> you do if you want to use the composite framework to build all sorts > >> of possible combinations with mtp (which is currently using u_char.c). > > > > Like what kind of combinations? Does gadgetfs not support the composite > > framework? If not, how about just solving that? > > > I don't think gadgetfs supports composite framework. Also it currently supports > only one USB configuration at a time. Both are good points ... the main reason gadgetfs didn't get an early conversion to the composite framework is that its core design precludes it ... gadgetfs wants to be "THE" gadget, in the same way that the composite framework is. Except ... the composite framework can delegate responsibilities to components, where gadgetfs can't. > Our existing Nokia composite driver is heavily based on composite framework and > we needed something that gels well with it and without legacy of tty so we could > add the custom ioctls and event notification for MTP implementation. u_char.c > provides for this. So that's a key motiviation for u_char: getting away from the TTY stack, with its complexities and confusions. I suppose you could say there were a couple motivations for u_serial in the first place. One was to make the serial interface more available, so it could work in composite gadgets ... e.g. a CDC gadget with both ACM and ECM (or EEM!) support. Another motivation was to have a "character device" I/O model available for re-use ... a byte stream I/O model (like TTYs) not packet streams. Perhaps in retrospect that latter part had unforseen issues coming from the TTY stack. It works, but not as smoothly as one would like. > This was easier for us than moving all our stuff to gadgetfs. Or writing a new composite-friendly gadgetfs, with a different programming model ... which may be worth doing, regardless. :) > >> u_char.c would also help on writting a USB HID gadget driver for > >> linux or even a Video Class driver. Wouldn't those want more of a "packet stream" I/O model though, not a "byte stream" model? - Dave > > We have USB HID code already using gadgetfs, right? A video one would > > also not be that difficult from userspace. > > > regards, > -roger > > -- 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
