On Fri, 04 Sep 2009 16:28:28 +0200, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
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?
They need to share data if it's the indented behaviour. I imagine that in
most cases one would want a single instance in few configurations rather
then several instances each in one configuration. For instance, access to
sysfs files will be easier that way for user space programs -- in
particular, if I have a gadget with mass storage + RNDIS as one config
and mass storage + CDC as another why should anyone see that mass storage
is in two configurations? I think it's more natural to think of it as a
single mass storage function intsance. If one want to have different
instances in each configuration it will be of course possible but IMO
that's less common case.
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.
First we need to get the current patch working well. ;) But ideally
you are right. Freeing resources when function is disabled (different
configuration used) would be ideal situation.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał "mina86" Nazarewicz (o o)
ooo +-<m.nazarewicz@xxxxxxxxxxx>-<mina86@xxxxxxxxxx>-ooO--(_)--Ooo--
--
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
