| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
setup...
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home