On Thu, 18 Aug 2016, Felipe Balbi wrote: > >> You mean a ep0 ioctl? Makes sense to me. Then we can add more features > >> later. Perhaps just add a "Get supported features" IOCTL which returns > >> a struct with 256 bits (4x uint64_t). I doubt we will ever need that > >> many bits, but better safe than sorry, I guess. > >> > > Don't we need some "set feature" IOCTL as well? > > Why? Features are enabled at kernel compile time. Userspace issues ioctl > to ask the kernel "which features do you have enabled for > GadgetFS?". Note that we have a backwards compatibility problem here. If > "which features do you have enabled for GadgetFS" ioctl fails, we will > assume that kernel is older than the first kernel where this ioctl was > added. > > To help userland a little more, we can make sure that, from now on, the > ioctl itself is always enabled and bit0 out of the 256 bits we have MUST > always be set. This means that "Forward all requests to userspace" > feature has to be, at least, bit1. > > This mimics what USB descriptors where bit7 of config descriptor's > bmAttributes must always be set. We're just using bit0 instead. Binyamin's question refers to existing userspace drivers for gadgetfs. They don't expect all requests to be forwarded and will fail if that happens. This is undesirable; we would like old programs to continue to work even under kernels built with the EXPERT feature configured in. Therefore the proposal is to have an "enable-feature" ioctl. It would be issued only by userspace drivers that are aware of the forward-all-requests feature. Drivers that aren't aware of it would never issue the ioctl, and so gadgetfs would revert to its original behavior for them. Alan Stern -- 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
