Dear List,
After introduction of ConfigFS composite gadget, there appeared an gap
in the user space. I mean that without this file system, creation of
gadget is as simple as:
$ modprobe g_<gadget_module> [params]
But when we are trying to use ConfigFS we have to write a lot of
commands. The minimal set is:
$ mkdir <gadget name>
$ mkdir configs/<config name>.<config number>
$ mkdir functions/<fucion type>.<instance name>
$ ln -s functions/<fucion> configs/<configuration>
$ echo <udc name> > UDC
+ setting vendorID, productID and others
See [1] for some examples of ConfigFS usage.
With all ConfigFS benefits, flexibility and other advantages, it's 5 or
maybe 10 times more writing than in the old solution to fulfill the most
common use cases. Users are lazy, they will still use the old, bad
solution, unless we will develop some user-space tool for convenient
gadget management.
I was recently thinking about this issue, so I would like to introduce
you my design proposition of gt - flexible gadget tool.
First of all, the name should be short so I have chosen just simply gt
[2].
[Proof of Concept]
I have divided my tool into two parts:
=== Custom gadget manipulation ===
First part is a wrapper for file system manipulations and it allow user
to use the flexibility of ConfigFS and compose their own fully custom
gadget. Some example commands:
Gadget, Function or Configuration creation:
$ gt create <gadget name> [attr=val]
$ gt func create <gadget name> [attr=val]
$ gt config create <gadget name> [attr=val]
Removal is also as simple as creation just use rm instead of create.
When gadget is created you can set it's attributes using:
$ gt set <gadget_name> <attr>=<val>
For function or Config simply add config or func to your call.
Gadget/function/Confiuration may contain additional folders, so the
attribute can have / signs. For example to create a folder you should
use:
$ gt set gadget1 strings/0x415/=1
Above command will create subdir 0x415 in strings directory of gadget1.
After that you can simply set all values below, for example:
gt set gadget1 strings/0x415/manofacturer="Polski producent"
Simple, isn't it?
=== Gadget templates ===
The second part of a gadget tool are gadget templates. It's my idea to
full fill the most standard use case with really simple and convenient
commands.
What is gadget template?
It's a file where in some format (XML looks suitable here) all the
setting of gadget or function etc are stored.
How it will work?
User sets up some custom gadget using commands from first part. The next
step is to store this gadget it gadget template using:
$ gt save gadget1 my_first_gadget_template
Then users can distribute those templates as standard text files. When a
gadget is needed user simply executes:
$ gt load my_first_gadget_template
And the gt will parse the file and create gadget1 in ConfigFS. All the
values of attributes will be restored, and we will get the fully
configured and enabled gadget. It's even simpler than the old method
which used modeprobe, isn't it?
[Details and full commands list]
This project will be fully open source so I have uploaded my design to
github, so if you are interested in full commands list or would like to
participate in the project please visit: [2]
[Action request]
List, please emphasize your opinion about my idea, It's really easier to
change the design when there is no implementation than later.
If you think that this design is good I will get to work and implement
this of course using libusbg introduced by Matt Porter [3]. What do you
think about idea of including gadget templates idea into libusbg
library? Should we do this or not?
Moreover, what about connecting gt and libusbg into one project and
develop it together at github?
[Foot notes]
[1]
https://wiki.tizen.org/wiki/USB/Linux_USB_Layers/Configfs_Composite_Gadg
et
[2] https://github.com/kopasiak/gt
[3] https://lkml.org/lkml/2013/9/11/407
--
Best Regrets,
Krzysiek
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
k.opasiak@xxxxxxxxxxx
--
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
