Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> writes: > 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? > > 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. The differences between GFS and FFS are mostly caused by the functionality composite provides. - With GFS, userspace produced descriptors and strings on demand, with FFS, strings and all other descriptors must be present at the very beginning. - With GFS, userspace program assumed that it is in control of the whole gadget so it could use any IDs it wanted, with FFS, there must be translation done between IDs userspace thinks things have and IDs they really have (most notably endpoint numbers). - Composite handles some of the requests that in GFS are transferred directly to userspace. > 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. Like Felipe and Alan has pointed, GFS API is not compatible with FFS API, so just deleting it could potentially break some existing code. Converting from GFS to FFS is not that hard (and in fact it's mostly just deleting code). I did that with some Samsung's MTP driver years back when I was writing FFS. Having that in mind, I would opt for scheduling deletion for 2-3 years in the future so that everyone (who cares about it) has time to migrate. I don't think that writting compatibility layer is a good idea. The layer would have too much logic for my taste. On top of it, I can imagine that it would not be able to abstract everything anyway (like with GFS you could return different string for the same string ID, not that I see why one would do that, but there may be some other more convoluted use-cases). Having said that, at the moment, FFS does not support asynch IO which GFS has implemented. I have it on my TODO list but never got to implementing it. > 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 :)). -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz (o o) ooo +----<email/xmpp: mpn@xxxxxxxxxx>--------------ooO--(_)--Ooo--
Attachment:
pgpuoitWeNFd9.pgp
Description: PGP signature
