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

[Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>]

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
setup...


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel