On Tue, Aug 14, 2012 at 10:21:16PM +0200, Sebastian Andrzej Siewior wrote: > The remaining non-composite users are: > - dbgp > very simple, not doing much ep0 > - file_storage > will be removed in v3.8 > - gadgetfs > Here are my problems at a central spot. > > 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. > However, I'm not sure how much sense it would make gadgetfs use > composite. A couple of requests would be moved from userland into kernel > and can not be overridden like USB_REQ_GET_DESCRIPTOR + USB_DT_STRING. > Others have no callback like USB_REQ_SET_INTERFACE. I *guess* it makes > no sense to touch it all. > Now while browsing through the tree I noticed functionfs. This looks > like a different gadget, seems to be a filesystem as well and is using > composite. The API in userland seems to be different between those two. > It seems to have the same ACK only behavior in ffs_func_setup() like > gadgetfs does unless I miss a detail here as well. yeah, functionfs was extracted from gadgetfs. Maybe the different userland API is a result of what you just found. composite doesn't allow for overwrites of some requests. > 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. > 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. -- balbi
Attachment:
signature.asc
Description: Digital signature
