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

[Fam Zheng <famz@redhat.com>]

On Fri, 08/05 08:31, Markus Armbruster wrote:
> Eric Blake <eblake@redhat.com> 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 <famz@redhat.com>
> >>> ---
> >>>  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.

Fair enough. If QEMUUUID wasn't so UNREADABLE, I'd have used it.

Will change to QemuUUID. It's a bit more acceptable to me.

Fam