On Thu, 8 Sep 2016, Felipe Balbi wrote:
> >> >> > +struct usb_gadgetfs_features {
> >> >> > + uint64_t bitmap[4];
> >> >>
> >> >> this should really be:
> >> >>
> >> >> uint64_t features0;
> >> >>
> >> >> /* Keep 24 bytes reserved for possible future usage */
> >> >> uint8_t RESERVED[24];
> >> >
> >> > Isn't this really extreme overkill? I would be surprised if gadgetfs
> >> > ever supports more than 10 features.
> >>
> >> I'm hoping to be extreme overkill :-) I really don't wanna get into a
> >> situation where we run out of bits. What if some features require
> >> arguments in the future? We could just pass them here, right?
> >>
> >> Frankly, I'm afraid of what happened to i2c-dev :-) We can't change
> >> (easily) i2c subsystem's write() to return the amount of bytes written
> >> because its userspace facing ABI has no reserved bits we could use to
> >> return that value. Changing that would be a huge amount of work.
> >>
> >> What do you think?
> >
> > Well, I don't care about it all that much, especially since I don't
> > think you'll ever need to use it. :-)
> >
> > Still, there are approaches that have been used in the past when people
> > wanted to create an extensible interface. Passing a variable-length
> > structure that has a length field at a reserved spot near the beginning
> > (perhaps along with one or two other reserved entries), for example.
>
> something along the like below?
>
>
> /* better names appreciated */
> struct usb_gadgetfs_packet {
> uint16_t length;
> uint8_t reserved[2];
>
> uint8_t *data; /* dynamically allocated by userspace */
> }
>
> I can work with that no problem.
I was thinking more like:
struct usb_gadgetfs_ioctl_arg {
uint16_t length;
uint8_t reserved[2];
uint8_t data[0];
}
but the principle is pretty much the same.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
