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 -- 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
