This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [PATCH, v4]: xl: randomly generate UUID's

On Wed, 2010-09-01 at 13:22 +0100, Christoph Egger wrote:
> On Monday 30 August 2010 14:51:23 Christoph Egger wrote:
> > On Friday 27 August 2010 19:34:00 Gianni Tedesco wrote:
> > > Changes since v3:
> > >  - Fix LIBXL_UUID_BYTES on NetBSD. Note that the code assumes
> > >    uint8_t[16] to always be interchangeable with libxl_uuid_t.
> uuid_t is a struct in NetBSD. It is defined as:
> #define __UUID_NODE_LEN  6 /* Length of a node address (an IEEE 802 address). 
> */
> struct uuid {
>     uint32_t time_low;
>     uint16_t time_mid;
>     uint16_t time_hi_and_version;
>     uint8_t clock_seq_hi_and_reserved;
>     uint8_t clock_seq_low;
>     uint8_t node[_UUID_NODE_LEN];
> };
> typedef struct uuid uuid_t;
> > >  - Return error messages when uuid_parse fails, spotted by Owen Smith
> > >  - Implement "uuid" parameter in xl and exit with an error if parse
> > >    fails
> > > Changes since v2:
> > >  - Re-based to remove orthogonal concern of UUID string formatting fixed
> > >    in 22001:0b6f82eaaea9 "xl: make libxl_uuid2string internal to
> > > libxenlight" - Incorporated Christoph Egger's suggestions
> >
> > I will test this.
> gcc produces several warnings "return from incompatible pointer type"
> and errors "cannot convert to a pointer type".
> libxl_uuid.h:147: warning: return from incompatible pointer type
> xl_cmdimpl.c:419: error: cannot convert to a pointer type
> The assumption that uuid_t and uint8_t[16] being interchangeable
> is wrong.

It turns out that it's only wrong for uuid_from_string()

> According to the manpage 
> (http://netbsd.gw.com/cgi-bin/man-cgi?uuid++NetBSD-current),
> what you probably want is uuid_enc_* and uuid_dec_* ?
> The question is do want the binary representation in little endian
> or big endian format?

Endian almost does not matter since we are not accessing the integer
fields of this struct we are simply using memcpy/memset/uuid_create.

There are cases where it does matter, ie. uuid_from_string() definitely
produces endian-dependant results. But will uuid_compare() will produce
a different sort order than memcmp() ? uuid_to_string() is
endian-aware ? If this is the case (and I suspect it is) then the UUID
compatibility layer header is not compatible and therefore *broken*.

It needs to be re-implemented libxl_uuid_t as a uint8_t array with
everything open-coded in the inline functions except for uuid_create()
which should be considered nothing more than a RNG.

I will re-submit this patch with netBSD compatibility code stubbed out,
could you take a moment to understand the requirements of the code and
implement that? If not I suppose it will stay stubbed out until I get
round to doing it. I am working on getting my own NetBSD devel box

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>