How FunctionFS works¶
From kernel point of view it is just a composite function with someunique behaviour. It may be added to an USB configuration only afterthe user space driver has registered by writing descriptors andstrings (the user space program has to provide the same informationthat kernel level composite functions provide when they are added tothe configuration).
This in particular means that the composite initialisation functionsmay not be in init section (ie. may not use the __init tag).
From user space point of view it is a file system which whenmounted provides an “ep0” file. User space driver need towrite descriptors and strings to that file. It does not needto worry about endpoints, interfaces or strings numbers butsimply provide descriptors such as if the function was theonly one (endpoints and strings numbers starting from one andinterface numbers starting from zero). The FunctionFS changesthem as needed also handling situation when numbers differ indifferent configurations.
When descriptors and strings are written “ep#” files appear(one for each declared endpoint) which handle communication ona single endpoint. Again, FunctionFS takes care of the realnumbers and changing of the configuration (which means that“ep1” file may be really mapped to (say) endpoint 3 (and whenconfiguration changes to (say) endpoint 2)). “ep0” is usedfor receiving events and handling setup requests.
When all files are closed the function disables itself.
What I also want to mention is that the FunctionFS is designed in sucha way that it is possible to mount it several times so in the enda gadget could use several FunctionFS functions. The idea is thateach FunctionFS instance is identified by the device name usedwhen mounting.
One can imagine a gadget that has an Ethernet, MTP and HID interfaceswhere the last two are implemented via FunctionFS. On user spacelevel it would look like this:
$ insmod g_ffs.ko idVendor=<ID> iSerialNumber=<string> functions=mtp,hid$ mkdir /dev/ffs-mtp && mount -t functionfs mtp /dev/ffs-mtp$ ( cd /dev/ffs-mtp && mtp-daemon ) &$ mkdir /dev/ffs-hid && mount -t functionfs hid /dev/ffs-hid$ ( cd /dev/ffs-hid && hid-daemon ) &
On kernel level the gadget checks ffs_data->dev_name to identifywhether it’s FunctionFS designed for MTP (“mtp”) or HID (“hid”).
If no “functions” module parameters is supplied, the driver acceptsjust one function with any name.
When “functions” module parameter is supplied, only functionswith listed names are accepted. In particular, if the “functions”parameter’s value is just a one-element list, then the behaviouris similar to when there is no “functions” at all; however,only a function with the specified name is accepted.
The gadget is registered only after all the declared functionfilesystems have been mounted and USB descriptors of all functionshave been written to their ep0’s.
Conversely, the gadget is unregistered after the first USB functioncloses its endpoints.