qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH 3/7] vdi: Use QEMU UUID API
Date: Thu, 4 Aug 2016 14:34:32 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

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.  But now we are just painting a
bikeshed, so I won't strongly object.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]