Hi, On Mon, Jun 13, 2011 at 10:33:09AM -0400, Alan Stern wrote: > > you wouldn't have to eliminate g_file_storage at all. See that we still > > have g_ether, g_serial and g_zero. None of those were eliminated when > > they were converted to composite framework. Rather, the functions were > > phased to f_*.c files and [ether | serial | zero].c are just tying > > things together. > > > > The same could've been done for g_file_storage :-) > > It essentially _was_ done; the result was g_mass_storage. The two > drivers are almost but not quite entirely the same (apart from use of > the composite framework). I see, the problem now is that we have two drivers doing somewhat the same thing and while the ARM people already got bashed because of "not sharing enough code" we have duplicate drivers on the gadget framework :-) We also need to a find a better way to get rid of the inclusion of C source files. I understand why Dave did it, but it's been quite some time since those patches were committed - e.g. 7e75bc0f9006e995a0fa25f0a285addc3d5fd5cb - and no progress has been made to fix that up. Probably Clang's link-time optimization would help a lot on that, but Clang still needs quite some work to be usable for us, so we need something else. Any ideas ? On another matter, do you think it's worth moving g_(mass|file)_storage to target ? We asked Tatyana to make UAS use target, but what about the legacy MSC gadgets ? (I have to say I didn't even look into target's code) > > I wouldn't get rid of all inlines... only the ones receiving a > > notification: > > > > static inline int usb_gadget_wakeup() > > static inline int usb_gadget_set_selfpowered() > > static inline int usb_gadget_clear_selfpowered() > > static inline int usb_gadget_vbus_connect() > > static inline int usb_gadget_vbus_draw() > > static inline int usb_gadget_vbus_disconnect() > > static inline int usb_gadget_connect() > > static inline int usb_gadget_disconnect() > > > > To those I would also add suspend() and resume(). > > Okay, now I get it. You can understand why I was confused, seeing as > how your original message said: > > We also need to cleanup all the ->start()/->stop() calls from > all udc controllers, then we need to uninline all the > operations we have on gadget.h ... > > Evidently you didn't really mean "all". the keyword was "operations", now that I read it again it's not clear enough, but it was supposed to refer to struct usb_gadget_ops :-) -- balbi
Attachment:
signature.asc
Description: Digital signature