Hi, > -----Original Message----- > From: Felipe Balbi [mailto:balbi@xxxxxx] > Sent: Wednesday, October 30, 2013 6:33 PM > To: Krzysztof Opasiak > Cc: linux-usb@xxxxxxxxxxxxxxx; Matt Porter > Subject: Re: Gadget tool proposition > > 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. Ok, fine, but it's done only for backward compatibility. The main method of gadget creation should be configFS. > > 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? > > > 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. -- BR's 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
