Hi, On Sat, Jun 11, 2011 at 12:04:32PM -0400, Alan Stern wrote: > > Why was g_file_storage done differently, I don't know ;-) > > I know, because it was at my request. :-) During the initial > development of f_mass_storage I didn't want to eliminate a working > driver in favor of one that was still buggy and under development. > > Also, there must be a lot of people and distributions using > g_file_storage now; doing what you suggest would force them to change > over to g_mass_storage. Not too difficult (as the drivers are highly > compatible), but also not something to be done very quickly. 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 :-) > > > > keep reading. The idea is to move the otg notifier to be a UDC notifier. > > > > Most of the notifications are from the gadget anyway: Suspend, Resume, > > > > Enumerated with xxx mA configuration, etc. > > > > > > But what does this have to do with all the inline operations in > > > gadget.h? For example, what is the connection between otg notifiers > > > and usb_ep_enable()? > > > > Well, I'm not sure adding a notification to all those inlines will be > > nice. But that's up to interpretation. > > I'm still confused. Why do you want to get rid of _all_ the inlines in > gadget.h just so you can add notifications to _some_ of them? 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(). > And why does adding a notification to an inline function call require > getting rid of the inline? It doesn't require... I just think that the function will start doing too many things to stay as an inline... Currently, they are inline because they don't _do_ anything other than a check for a valid pointer, that's fine. After we add a notification, they _do_ something. Namely they'll traverse the list of notifications until they find the correct one and then call all registered notifiers. (well, the atomic_notifier_call_chain() will do that). > > If you want simultaneous access to the media via USB and via the device > > itself, you should be using something like MTP instead. > > Indeed. Or else switch to a USB-based network connection and a proper > file server, like Samba or NFS. aaa true... MTP-over-IP also sounds nice, then the API for userland is always the same no matter if it's USB, WiFi, ethernet or what... -- balbi
Attachment:
signature.asc
Description: Digital signature
