On Fri, 4 Sep 2009, [utf-8] MichaÅ? Nazarewicz wrote: > > On Mon, 31 Aug 2009, [iso-8859-2] Micha³ Nazarewicz wrote: > >> In the final version, many msf structures will refer to a single > >> msf_common structure and so it is required to move common data > >> to another object which can be shared. > > On Thu, 03 Sep 2009 22:52:53 +0200, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > I don't understand this. Are you concerned about situations where a > > single gadget might contain several independent Mass-Storage > > interfaces? If they are independent, how can they share common data? > > I'm concerned about using MSF in several USB configurations. Those > MSFs will need to share various data and that's what msf_common is for. Why do they need to share data? What data do they share? Are you implicitly assuming that a mass-storage interface present in multiple configurations must behave the same way in all those configs? > At to this point, I moved LUNs and some buffers to the msf_common > structure. The former makes it possible to use MSF in several > configurations (while I was testing Android's code I was unable to use > their function in two configurations because each instance tried to > create its own LUN devices and bind files in sysfs) and the later is > just a way to optimize memory usage a bit (ie. one buffer for all > instances instead of one buffer per instance). > > What I haven't solved yet, but am working on, is problem with kernel > thread. At the moment each binding of a MSF to USB configuration > creates a kernel thread (so a gadget with a single MSF in two > configurations create two kernel threads). There are some other > things that need to be done with existing code (at the moment I'm > hunting a bug that somehow appeared) and I will deal with the > thread issue later on (I think I have some basic idea how to do > this). In principle, the thread, buffers, and all the other resources should be destroyed and/or re-created every time the configuration is set. For example, suppose there is a config that doesn't include a mass-storage interface. Then when that config is installed, you will want to get rid of all the unneeded resources. file_storage.c isn't as efficient as it could be in this regard. It regenerates the endpoints and requests whenever there's an interface change, but it doesn't reallocate buffers or start a new thread. You could do the same thing... but if you do, don't create more than one thread. Alan Stern -- 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
