On 12 September 2014 13:48, Eric Blake <ebl...@redhat.com> wrote:
> On 09/12/2014 04:44 AM, Gerd Hoffmann wrote:
>
>>>> +enum virtgpu_ctrl_type {
>>>> + VIRTGPU_UNDEFINED = 0,
>>>> +
>>>> + /* 2d commands */
>>>> + VIRTGPU_CMD_GET_DISPLAY_INFO = 0x0100,
>>>
>>> Please consider also adding:
>>>
>>> #define VIRTGPU_CMD_GET_DISPLAY_INFO VIRTGPU_CMD_GET_DISPLAY_INFO
>>>
>>> and friends. It makes it MUCH nicer for application software to probe
>>> for later extensions if every member of the enum is also associated with
>>> a preprocessor macro.
>>
>> I don't think this will ever be shipped as library header for external
>> users ...
>
> Fair enough. I wasn't sure, so it didn't hurt to ask.
>
>>
>>>> +struct virtgpu_ctrl_hdr {
>>>> + uint32_t type;
>>>> + uint32_t flags;
>>>> + uint64_t fence_id;
>>>> + uint32_t ctx_id;
>>>> + uint32_t padding;
>>>> +};
>>>> +
>>>
>>> Is the padding to ensure that this is aligned regardless of 32-bit or
>>> 64-bit hosts?
>>
>> Yes.
>>
>>> Is it worth adding a compile-time assertion about the
>>> size of the struct to ensure the compiler doesn't add any additional
>>> padding?
>>
>> Makes sense. What is the usual trick to do that?
>
> Among others,
>
> struct dummy {
> int size_check : (sizeof(virtgpu_ctrl_hdr) == 24 ? 1 : -1);
> };
QEMU already has a BUILD_BUG_ON() macro, so you can just say
QEMU_BUILD_BUG_ON(sizeof(virtgpu_ctrl_hdr) != 24);
-- PMM
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
