Hi, On Wed, Oct 30, 2013 at 03:28:43PM +0100, Krzysztof Opasiak wrote: > 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 not entirely true. not at all!!! We have provided stubs for the gadget drivers which were already in tree and you can still use modprobe g_mass_storage, etc. For new gadgets, then sure, they need to be done via configfs. > 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. there's already libgadget [1] which Matt Porter has been working on, how about you help him out ? I'd really like to see libgadget bindings for ruby, for example. As well as some default examples for current, in-tree gadget drivers. > 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? this all sounds like it should be a tool using Matt's libgadget. > === 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? right, this is a nice feature which I'd actually expect from such a tool. [1] https://lwn.net/Articles/565724 -- balbi
Attachment:
signature.asc
Description: Digital signature
