* Andrzej Pietrasiewicz | 2012-10-22 10:13:48 [+0200]: >Perhaps I should have been more explicit about this: by RFC I mean something >not intended for merging yet but rather a proof of concept or the like. > >However, I am confused taken this: > >http://marc.info/?l=linux-usb&m=132431126927355&w=2 > >into account. I thought we are somewhere around > >"make composite one file again and forget the #include" > >so working on "start implementing the gadget configfs interface" >makes sense to me. Yes but look: you changed a lot of the mass storage gadget to make it work with configfs interface. You had everything more or less hard coded, didn't you? With the recent change you have infrastructure where you don't need to know the names of the functions and their parameters and so on you lost more and more of that code, right? The removal of "include composite.c" was one step. The recent removal of "include f_acm.c" is the next step. With the current configfs code you have, how would you handle two gadgets on two UDCs while they share for instance the same string descriptors? >Given the above, the following questions arise: > >0) What is the right way of doing "configfs-based binding"? I am not sure about the details but: Taking the hiarchy from the email quoted + adding a config descriptor: | /sys/kernel/config/gadget_or_what_ever | + | +->FancyStorageGadget once this is created allocate struct usb_composite_driver. Here we miss a config descriptor. | + VendorID | + DeviceID | +->config0 after a mkdir config0 you should allocate a struct usb_configuration for this. | +->function0 | + name (=> ether) Here I am not sure if we should name it function0 and have name property or just put the name of the the directory into usb_get_function() and request that functions. I am also not sure if the order of the functions is important. *I* think that it does not matter if we first expose the serial function and then the mass storage and next time the other way around. Other opinions? | + qmult qmult and other options could be exposed via the avail_options member. | +->function2 | + name (=> bot) | +->function1 | + name (=> uasp) | + target_device Once you set all this you could link this gadget (FancyStorageGadget) to your udc which needs an entry in configfs as well. The code for all the intermediate steps is missing. >1) What kind of ground work/housekeeping are required before configfs >works can be considered? on top of my head: - the serial gadget family that is acm, obex and the "simple serial" require to know in advance the number of available ports. This limit is shared among all users of u_serial. One should look and see if this limitation could be hidden somewhere in u_serial or removed completely. - if the function API is consider "okay" convert the remaining functions to it. - descriptor allocation / creation rework. Each functions brings a few of their own descriptors. The user might want to change them. Besides the "obvious" VID/PID thingy there are the string descriptors. Currently a bunch of functions allocate the descriptors "once" and check if the of the first id is 0 and if not, they skip the allocation. This is done in order to share the string (and descriptor which contains iSerial for instance) across multiple configurations. This sharing does not work if we plan to use the same function twice on two UDCs where we could have diffent IDs. What I had in mind was: - create a copy of each descriptor. Each descriptor should have a name or something different that can be used as an unique identifier. - after the copy has been done, the function can request the copy by the name and update some fields like the endpoint number in case of an endpoint descriptor. - configfs could also allow to edit some fields here like the string. - each gadget provides now two sometimes three copies of those descriptors. To make things simpler the gadget could provide only set of descriptors (for instance only SS) and composite would create HS and FS from it if desired. - after attaching all functions within a config, the code resets the allocated endpoints. This is done because only one config can be active at a time and therefore the endpoints are shared. Not only the endpoints can be shared among configs but also among alternate interfaces. If you look at the tcm gadget I share the same endpoints between UAS and BOT. Maybe this could be done in a better way. Also I hate that we allocate HS descriptors and fill the blanks in FS descriptors. Each point here is just one of my thought. I currently try hard not to mix everything in one series and get everything NAKed due to one bad thought :) Right now it works. I am not sure how "well" they are. >Can configfs works be done in parallel? You can take what you have and rebase on top of recent code. The problem is that we can't merge incomplete code and stuff that is missing something because we can't change an interface. The rulles are for now that we want a generic interface and it should be possible to attach it to more than just one UDC at a time and we don't want break anything. >2) If only f_* files remain, where will they be used? Now they are >used by their gadget counterparts, e.g. f_sourcesink and f_loopback >are used by zero.c. In other words, if f_* files deal with the >usb functions level and only they remain, then what takes care of >usb configurations and usb devices? The configfs interface. Let me tell you more what I dreaming about while I fall asleep: Now I try to ease the entry pain for configfs. The new code should be used by configfs and by the g_* code and the g_* code shouldn't notice a thing while using it. Once the configfs is stable and working well and people don't complain that it is hard to handle, we can ask all users to switch to it instead of using modprobe g_*. Any why should they use it? Because it is so much more flexible. Then we could provide a script/tool which is named g_zero.sh and does what "modprobe g_zero" would do but via configfs. And then, if nobody is using "modprobe g_*" anymore, we could remove them. >Thanks, > >AP 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
