Hi,
during the last few weeks/months I've been thinking about a
configuration interface for the gadget framework. During the development
of uasp I think I was able to fill some blanks. This is what banging
through my head so far:
We have no dedicated configuration API for the gadget framework. What we
have is a bunch of module parameters. Gadget's which are using the
composite framework inherit a few of them like iManufacturer or
idProduct. A few gadgets provide their own (gadget specific) module
parameters that is cdrom for instance for the storage gadget or use_eem
for the Ethernet gadget.
Getting support for multiple gadgets (one gadget for one udc so we have
two udcs in one system) at the same time will end up with _long_ module
options and the need for a separator to distinguish between options for
first udc and the second one. "," might appear handy but the storage
gadget is using this for multiple lun configuration. *I* would prefer a
consistent interface for all options. This also extends the kernel
command line in case one decides to have everything built-in.
The next problem we have are the multiple-functions gadgets like the
Nokia gadget which contains a few "different" functions each activated
by a different configuration. And there seem to come more with different
mix like serial/ethernet/obex/...
So what can be done about this? What about this:
Each gadget is providing nothing else but a function. We use then
configfs (I had to use this for uasp and it is not that bad) to
configure a gadget. If your blood pressure is rising please take a break
and continue reading later :)
That means we take the folder:
/sys/kernel/config/gadget_or_what_ever:
and it contains a file:
available_functions
A cat on this will return bot, uasp, obex, for instance. Creating a new
gadget would require:
# create a bare gadget:
mkdir FancyStorageGadget
Upon its creation, the folder will contain a few files representing
descriptor configurable items like VendorID, DeviceID, Manufactor,
Serial, ProductName, ...
Now you create two directories: function0 and function1
in functionX you have a file named "name". You
echo "bot" > name
which means function0 is bot. You do
echo "uasp" > name
and you provide uasp for function1.
In functionX/ you can provide function related configuration. For
instance have now removable=1 for the storage gadget.
You could also add a function2 which would provide a serial gadget and
so on.
Now your gadget is complete and can go ahead and bind the
FancyStorageGadget to an udc.
/sys/kernel/config/gadget_or_what_ever
+
+->FancyStorageGadget
+ VendorID
+ DeviceID
+->function0
+ name (=> ether)
+ qmult
+->function2
+ name (=> bot)
+->function1
+ name (=> uasp)
+ target_device
So. If more than one udc is available in the System they can be
configured the same way. We can remove the Nokia gadget from the kernel
and provide a configuration file how to achieve the same gadget with
this new interface instead. Complex gadget which require bunch of option
don't require long modprobe strings.
Once the gadget is complete in terms of its configuration it can be
bound to an udc and then connected.
I understand that the echo/mkdir like interface is not perfect for
everybody. For target there is a python tool that handles it so you/the
user does not see configfs internals. The problem with python is that
small users which ship just a busybox as their RFS might consider python
as too big. Therefore I would suggest a small C program/library and
everyone could provide bindings for every language that one needs. And
if this is library is considered to much, the shell path is still open.
Those "configration steps" could be saved somewhere and re-used for the
next time. Somewhere could be a shell script or .cfg file which is
re-used the next time.
There is one problem here: I don't see a way how to get this done and
providing compatibility for the modprobe / global variable way. If
someone has an idea, I'm all yours.
The devel plan would look something like this:
- Have more people which like this than disagree and prefer the way it
is done now.
- convert remaining gadgets to the composite framework.
- remove global variables from gadgets/composite
- make composite one file again and forget the #include
- start implementing the gadget configfs interface
- finish it and breath.
I might have forgotten the one or other point in my simple plan :)
What do you think?
Sebastian
--
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
