HI, On Wed, Aug 15, 2012 at 10:17:46AM +0200, Sebastian Andrzej Siewior wrote: > On 08/15/2012 08:11 AM, Felipe Balbi wrote: > >>So gadgetfs. Its ep0 handling can be done in kernel and some requests > >>can be offloded to userland. Lets assume the host sends > >>USB_REQ_SET_INTERFACE and ->usermode_setup is set. That means it returns > >>with 0 (aka ACKs the request), wakes up the ep0 userland which might take > >>a second. Within this second we might get a second ep0 request which > >>will be processed as well, right? I am asking this because I would > >>expect USB_GADGET_DELAYED_STATUS as the return code. So am I missing > >>something or has the user land no control to stall _this_ request? > > > >returning USB_GADGET_DELAYED_STATUS looks like the real fix here. > > Yeah but this would require userland to enqueue a dummy / empty request > to ACK it. If userland never did it, this request will break it. oh, that's bad :-( > >>At this point the cleaning lady in my woke up: May I please remove > >>inode.c, please? We don't need two APIs for the same thing. > > > >The problem is with current users. We have at least a g_zero-like > >version using gadgetfs. But I'm not sure if there's anyone using > >usermode_setup stuff. > > So we could convert it to functionfs. But there could be many other > were are not aware of… A gadgetfs to functionfs compatiblity layer > might help. But since they have to give up certain things and pass > descriptors in advance instead of writing them on demand there will be > differences. So I guess this compatibility layer makes no sense. correct. > >>Having only composite based gadgets would maybe easy things for future > >>rework and multiple gadgets. Adding USB3 support is probably easier to > >>add this into functionfs (unless I can introduce antother user space > >>API :)). > > > >not another one, please :-) I have not much feelings towards inode.c, > >but we can't simply break compatibility like that, right ? I'm not sure > >how many gadgetfs users we have, but that's a userland API which has > >been around for a loooooooong time. Even before git came around. > > Before git you say? hehe. I've found bits of gadget code in v2.4. > Let me think: > - smbfs > got remove but was replaced cifs. For the user probably only the > module name changed. Not really close to this. > > - jffs > Got removed after it has been scheduled for removal. It was replaced > by jffs2 and had a few users if any. The replacement in our case > requires API changes and we can't say anything about number of users. > > - nfsservctl > This syscall was removed in v3.1. Haven't found more. We don't do > this in general. > > Based on this it looks like we are stuck with this? No cleaning lady > here? Either that or we keep gadgetfs out of the whole configfs rewrite and schedule gadgetfs for removal on v4.8 or something... -- balbi
Attachment:
signature.asc
Description: Digital signature
