Re: [Qemu-devel] [PATCH 3/7] vdi: Use QEMU UUID API

[Markus Armbruster]

Eric Blake <address@hidden> writes:

> On 08/04/2016 12:58 PM, Stefan Weil wrote:
>> Hi,
>> 
>> On 08/02/16 11:18, Fam Zheng wrote:
>>> The QEMU UUID api, including the data structure (qemu_uuid_t), is fully
>>> compatible with libuuid.  Use it, and remove the unused code.
>>>
>>> Signed-off-by: Fam Zheng <address@hidden>
>>> ---
>>>  block/vdi.c | 49 ++++++++++---------------------------------------
>>>  1 file changed, 10 insertions(+), 39 deletions(-)
>>>
>
>>> @@ -182,10 +153,10 @@ typedef struct {
>>>      uint32_t block_extra;       /* unused here */
>>>      uint32_t blocks_in_image;
>>>      uint32_t blocks_allocated;
>>> -    uuid_t uuid_image;
>>> -    uuid_t uuid_last_snap;
>>> -    uuid_t uuid_link;
>>> -    uuid_t uuid_parent;
>>> +    qemu_uuid_t uuid_image;
>>> +    qemu_uuid_t uuid_last_snap;
>>> +    qemu_uuid_t uuid_link;
>>> +    qemu_uuid_t uuid_parent;
>> 
>> As far as I remember, _t should be avoided because that postfix is
>> reserved by POSIX. Should we use qemu_uuid, or can we ignore POSIX
>> because the type name uses the qemu_ prefix?
>
> Correct that POSIX reserved all _t (which is a bit broad, oh well), and
> also correct that we can take the risk of using it anyways (but if POSIX
> ever standardizes something, we get to keep both of our broken pieces).
>
>
>> Either with qemu_uuid_t or with qemu_uuid:
>
> I thought our coding standard preferred QemuUUID or something similar in
> camelcase, rather than lower case.

Correct.  It's ugly (in my opinion), but we should stick to it, so it's
at least consistently ugly.

>                                     But now we are just painting a
> bikeshed, so I won't strongly object.

I'd prefer QemuUUID.