> On 8 Sep 2016, at 22:20, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Thu, 8 Sep 2016, Binyamin Sharet (bsharet) wrote:
>
>>> 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
>>>
>>
>> Won’t the user lose the relevant information (e.g. feature
>> structure) by using this model?
>
> What feature structure? Aren't your feature lists just vectors of 64
> bits? They can be stored in the .data field above.
>
> Alan Stern
>
Not “just” - they are platform-dependant uint64_t. which means they
won’t look the same on systems with different endianness. If the
user is unaware of this, it can cause confusion w/r/t which bit is which.
We can use 8-bit vectors instead and skip the endianness issue,
but why define a generic usb_gadgetfs_ioctl_args structure instead
of “features struct” for feature-related ioctls and different structs for
other types of ioctl (if we’ll have such in the future)?
Binyamin Sharet
Cisco, STARE-C
��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
