RE: [RFC][PATCH] fs: configfs: programmatically create config groups

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

On Wednesday, November 28, 2012 9:39 AM Sebastian Andrzej Siewior wrote:

<snip>

> >
> > so that we can create the endpoint directories.
> > And now what? What names shall the user use for the endpoint
> > directories? Oh, that's simple: just see what the endpoint
> > directories' names are. But wait, aren't we just creating them?
> >
> > Please also see Michał's point about user interface.
> 
> Yeah I did. Now I'm okay with creating new directories but we should keep
> this to a minimum and encode as much information possible in directory's
> name.
> 

I think I've identified one more case where programmatic creation/removal
of configfs directories is required. There is a general agreement that
binding/unbinding the gadgets will be achieved with using symlinks between
configfs representations of udcs and gadgets. So we need to represent
udcs in configfs. Suppose that the udc driver for user's platform
is modular, e.g. s3c-hsotg.ko. Now, after:

$ modprobe s3c-hsotg

I would _very_ much like the s3c-hsotg or something similar to appear
_automatically_ under $CONFIGFS_ROOT/udcs, e.g.:

$ ls $CONFIGFS_ROOT/udcs

s3c-hsotg

If there can be more instances than 1, then probably I would want

s3c-hsotg.0 	s3c-hsotg.1 ....

or something like that.

It would be _very_ frustrating for the user to have to guess
what name to use _if_ the relevant directory were to be
created manually with mkdir. Conversely, what would

$ rmdir s3c-hsotg

mean? Should it cause the s3c-hsotg.ko to unload?

All the above problems are elegantly solved with programmatic
creation and removal of configfs directories: in the udcs
config_group there is no make_item nor make_group, so mkdir
is not allowed, but instead the directories appear and
disappear as udcs come and go.

Andrzej