Re: [PATCH v1] USB:gadget: Fix a warning while loading g_mass_storage

[Andrzej Pietrasiewicz <andrzej.p@samsung.com>]

W dniu 04.06.2014 17:26, Alan Stern pisze:
> On Wed, 4 Jun 2014, Andrzej Pietrasiewicz wrote:
>

<snip>

> What is the difference in purpose between usb_function and
> usb_function_instance?  I can't tell just by reading the header file.
> Does one of them get created dynamically when the host sets the
> appropriate config?
>

Please see below.
   
<snip>

>>
>> Among traditional gadgets there is no gadget which uses mass storage function
>> more than once. On the other hand, when gadgets are created with configfs
>> it is forbidden to link a given function more than once into a given
>> config,
>
> What is the reason for this restriction?

Please see below.

>
>>   that is a struct usb_function_instance can be referenced by more
>> than one config, but can be referenced only once in a given config;
>> each symbolic link corresponds to an instance of struct usb_function
>> (don't confuse with struct usb_function_instance).
>
> It's extremely easy to confuse them, since I don't understand the
> differences between them.  It even seems like you confused them in this
> description: You mentioned "link a given function", "link corresponds
> to an instance of struct usb_function", and "struct
> usb_function_instance can be referenced by more than one config".
> What's the difference between linking a usb_function and referencing a
> usb_function_instance?  Normally "linking" and "referencing" mean more
> or less the same thing.

As I said, I didn't like the naming here. I got used to it, though,
but understand (and agree) that it is confusing. As far as explaining
the difference is concerned, being a non-native speaker of English
has its influence, too, so let me do it again.

I think it is easier to tell the purpose of the two structures taking
gadgets composed with configfs as example.

In each gadget there is "functions" directory. Function directories
are created there:

$ cd $CONFIGFS_ROOT/usb_gadget/our_gadget
$ mkdir functions/mass_storage.0

mass_storage.0 is internally represented as an instance of
struct usb_function_instance, which has its associated
struct fsg_common (the fsg_common is a member of
container_of(struct usb_function_instance)).

It can be referenced from multiple configurations.

$ ln -s functions/mass_storage.0 configs/config.1
$ ln -s functions/mass_storage.0 configs/config.2

Each reference (symbolic link) is internally represented as
an instance of struct usb_function. The struct usb_function here
has its associated struct fsg_dev (the fsg_dev is a
container_of(struct usb_function)).

By the very nature of any file system one cannot do:

$ ln -s functions/mass_storage.0 configs/config.1
$ ln -s functions/mass_storage.0 configs/config.1 => -EEXIST

By design of how configfs is applied to any usb gadget on cannot even do:

$ ln -s functions/mass_storage.0 configs/config.1/my_mass_storage.0
$ ln -s functions/mass_storage.0 configs/config.1/the_same_mass_storage.0 => -EEXIST

However, there should be no problem with this:

$ mkdir functions/mass_storage.0
$ mkdir functions/mass_storage.1
$ ln -s functions/mass_storage.0 configs/config.1
$ ln -s functions/mass_storage.1 configs/config.1

Legacy gadgets (g_mass_storage, g_acm_ms, g_multi) in fact operate in
a somewhat similar manner, the difference is that instead of creating directories
and making symbolic links, usb_get_function_instance() and usb_get_function()
are called, respectively, and composing a gadget happens from beginning to end
at module init.

I hope this clarifies things a bit.

AP