Hi Felipe, On September 19, 2012 2:18 PM Felipe Balbi wrote: <snip> > > I wouldn't make functionN a directory. I think it's better to: > > echo "f_mass_storage" > /cfg/usb-function-gadget/ufg/config0/function0 I'd like to comment a little on your suggestion. In configfs there are config items, which have attributes, and config groups, which are a special kind of items allowed to contain other items (be it config groups or config items). In a filesystem speech this corresponds to directories (items, groups) and files (attributes). The user has control only over creating config items/groups - this is achieved with issuing the "mkdir" command. In contrast, the user has no control over creating the attributes - no possibility to use "touch" or "echo <something>" to create one. @Joel: Could you please correct me if I'm wrong? So IMO the shortcut you propose is not good, because either we would have to have a predefined number of "functionX" attributes in a config, or create them programmatically with doing "echo <new function name>" to a special attribute, like: $ echo mass_storage > /cfg/usb-function-gadget/gadget1/config1/add_fun. > > and that would create all necessary interfaces and expose all knobs from > interfaces and their endpoints. Some after running the command above you > would have: > > ..../config1/intf0/ > ..../config1/intf0/bLength > ..../config1/intf0/bDescriptorType > ..../config1/intf0/bInterfaceNumber > ..../config1/intf0/bAlternateSetting > ..../config1/intf0/bNumEndpoints > ..../config1/intf0/bInterfaceClass > ..../config1/intf0/bInterfaceSubClass > ..../config1/intf0/bInterfaceProtocol > ..../config1/intf0/iInterface > ..../config1/intf0/ep80/ > ..../config1/intf0/ep80/bLength > ..../config1/intf0/ep80/bDescriptorType > ..../config1/intf0/ep80/bInterfaceNumber > ..../config1/intf0/ep80/bAlternateSetting > ..../config1/intf0/ep80/bNumEndpoints > ..../config1/intf0/ep80/bInterfaceClass > ..../config1/intf0/ep80/bInterfaceSubClass > ..../config1/intf0/ep80/bInterfaceProtocol > ..../config1/intf0/ep80/iInterface > ..../config1/intf0/ep81/ > ..../config1/intf0/ep81/bLength > ..../config1/intf0/ep81/bDescriptorType > ..../config1/intf0/ep81/bInterfaceNumber > ..../config1/intf0/ep81/bAlternateSetting > ..../config1/intf0/ep81/bNumEndpoints > ..../config1/intf0/ep81/bInterfaceClass > ..../config1/intf0/ep81/bInterfaceSubClass > ..../config1/intf0/ep81/bInterfaceProtocol > ..../config1/intf0/ep81/iInterface > This is a very strict spec-following structure, which indeed says about configs, interfaces and endpoints rather than functions. I'm not saying this is good or bad. I just want to say that for many functions (all of them?) we need some place to set their specific parameters, like number of luns and names of backing files for mass storage or number of ports and mode (acm, obex) for serial. I think that the concept of a directory lends itself nicely for this purpose. So maybe something on the lines of this should be considered: ..../config1 ..../config1/function1/name [mass_storage] ..../config1/function1/.....[function specific stuff] ..../config1/intf0/..... ..../config1/intf0/epXX/....... ..... ..... ..... What do you think? > of course only few of those would be writeable from userland, but > exposing read-only versions of those might help us find bugs without > needing to read the source code. > > And, you could create as many functionN files as you want under a > particular configuration. Provided they are named differently, as a filesystem won't let two files with the same name. AP -- 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
