Hi, On Thu, Oct 31, 2013 at 01:35:45PM +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. > > Ok, fine, but it's done only for backward compatibility. The main method > of gadget creation should be configFS. yes, this is what I said on line below > > 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. > > As I wrote in previous message. I would like to use libgadget. There are > some issues, but I will prepare some patches which implements the > missing things, I that Matt will accept them. > > More over I'm not sure if there is a need to have two projects - gt and > libgadget. Maybe create only one and only in distributions provide > separate packages for tool and library. What do you think Matt? sounds good to me. > > > 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. > > > Great, I hope you will enjoy using the new tool when it will be ready. sure, for testing purposes it's awesome, but when building a real device, I'd expect application framework to use libgadget directly and use your tool as a reference implementation. -- balbi
Attachment:
signature.asc
Description: Digital signature
