Hi, On Mon, Oct 22, 2012 at 04:26:35PM +0200, Sebastian Andrzej Siewior wrote: > 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? I don't it should matter, what matters though is which configuration we expose first. > >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. correct > 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. note that the string is a separate descriptor :-) configfs should allow for a string descriptor to be linked to e.g. the iManufacturer field of a device descriptor. Maybe a symlink is enough ? > - 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. I don't think that will work. Think about isochronous and interrupt endpoints where wMaxPacketSize can be whatever we want. I'd rather allocate 3 sets of descriptors :-s > - 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. right. -- balbi
Attachment:
signature.asc
Description: Digital signature
