Re: gadgetfs, functionfs, composite

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

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?

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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux