On Monday, November 26, 2012 5:51 PM Sebastian Andrzej Siewior wrote:
> On 11/23/2012 12:52 PM, Andrzej Pietrasiewicz wrote:
<snip>
> >>> +static struct config_group *ufg_make_function_subgroup(
> >>> + struct config_group *group, const char *name) {
> >>> + struct ufg_function_grp *f_grp;
> >>> + struct config_group *result;
> >>> +
> >>> + /*
> >>> + * TODO:
> >>> + *
> >>> + * This makes "interface" an illegal name for a function.
> >>> + */
> >>> + if (!strncmp(name, "interface", 9)) {
> >>
> >> Can't you use something else to match between function& interface?
> >> After all you know that gadget's parent has to be a "config"-folder,
> >> followed by an interface, followed by the function.
> >>
> >
> > I could have used another level of nesting, where by default there are
> >
> > /cfg...../C1/F1/name
> > /cfg...../C1/F1/function/
> > /cfg...../C1/F1/interfaces/
> >
> > and
> >
> > echo "some_name"> /cfg...../C1/F1/name
> >
> > creates
> >
> > /cfg...../C1/F1/function/some_name
> > /cfg...../C1/F1/function/some_name/function-specific-stuff
> >
> > and later binding the gadget creates
> >
> > /cfg...../C1/F1/interfaces/interface00
> >
> > In such a situation the distinction between a function and an
> > interface is made by construction: a subdirectory of
> >
> > /cfg...../C1/F1/interfaces must be an interface
> >
> > While a subdirectory of
> >
> > /cfg...../C1/F1/function must be a function
> >
> > This can be done. However, I was not sure whether it was desirable to
> > have one more directory level.
> >
> > Now it is
> >
> > /cfg...../C1/F1/name
> > /cfg...../C1/F1/some_name
> > /cfg...../C1/F1/some_name/function-specific-stuff
> > /cfg...../C1/F1/interface00
>
> I would put the interfaces as a child of function and not merge them in
> one folder.
...thus pushing the problem of distinguishing the directory names
deeper in the directory hierarchy?
Let me write something about configfs.
In configfs there are groups and items.
Groups can contain other groups/items. Both groups and items map to
directories. Groups and items can have attributes which correspond to
files. The user creates only groups/items, i.e. it is impossible for
the user to create files (attributes). Groups and items have a "type"
associated with them, which describes, among other things, what attributes
there are in the group/item and what "type" of groups EX-OR items can
be created in the given group by the user; to be precise, each group
uses exclusively one of two operations: either make_group or make_item
to create its child groups/items. The operations are provided by the
user of configfs, e.g. f_mass_storage.c. So whenever a configfs
directory contains subdirectories created by the user, they all
need to be of the same type, unless the name of the directory to be
created is analyzed and based on that the appropriate type is chosen.
This is exactly what happens with the "interfaceXX" directory.
Even if we make it a child of function's directory, we push this analysis
into the function's directory handling code, but not eliminate it.
It does not matter that the directory is created programmatically,
because in this implementation all the programmatic creation does
is _simulating_ user's action invoked through a syscall. That is
why in my opinion we need a better way of programmatic configfs
directories creation/removal and so my proposal to extend configfs.
<snip>
> > @Joel: can you suggest something else for programmatically creating
> > configfs directories and reading/writing configfs files?
>
> I'm not convinced because others made it. So far I see the USB interface
> mostly in the same way as the target interface. Please take a look at
> proposal I made for the hierarchy. Maybe it makes some of the requirements
> go away.
>
Please see my reply to your proposal. IMHO the requirements do not go away.
But creative solutions welcome.
<snip>
> >>
> > ALIAS() to have a string which can be referred to in adapters, which
> > provide the old modprobe + parameters (+ e.g. sysfs) interface and
> > should be able to request_module("usb_functions"); The string could be
> > defined in some header file included both by this module and adapter
> > modules. Simpler solutions welcome.
>
> I don't get. No ever did "modprobe usb_functions" at least on an mainline
> kernel so I don't understand "old modprobe + prameters"
> interface. So why again?
>
I meant adapter modules, like this:
http://www.spinics.net/lists/linux-usb/msg74871.html
please see the msg_init function there. When adapter modules go away,
which is the ultimate goal, any support for them can be removed.
In what I proposed the "support" is the alias in question and the
exported configfs subsystem UFG_SUBSYSTEM.
Andrzej
--
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
