[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH, v3]: xl: randomly generate UUID's
On Fri, 2010-08-27 at 16:13 +0100, Christoph Egger wrote: > On Friday 27 August 2010 15:56:35 Gianni Tedesco wrote: > > On Thu, 2010-08-26 at 16:41 +0100, Christoph Egger wrote: > > > @@ -2219,8 +2224,11 @@ static void list_domains(int verbose, co > > > info[i].dying ? 'd' : '-', > > > ((float)info[i].cpu_time / 1e9)); > > > free(domname); > > > - if (verbose) > > > - printf(" " LIBXL_UUID_FMT, LIBXL_UUID_BYTES(info[i].uuid)); > > > + if (verbose) { > > > + char buf[LIBXL_UUID_LEN]; > > > + libxl_uuido_string(&info[i].uuid, buf, sizeof(buf)); > > > + printf(" %s", buf); > > > + } > > > putchar('\n'); > > > } > > > } > > > > Really? There's no way to keep the macro approach and get at the thing > > like an array of bytes? > > Yes. gcc complains about 'subscripted value is neither array nor pointer'. Yes, my implementation may have been broken but was there a way to make it work? I assume there must be. Basically this allows us to avoid the use of a temporary buffer when printing UUID strings. > > If that's the case then how can libxl_uuid_bytearray() that I introduced > > work correctly? > > I removed it because its redundant to libxl_uuido_string(). > A bytearray and a string is the same in C unless you use unicode. I think we're talking accross purposes, the point of the libxl_uuid_bytearray is basically to cast the platform specific type to a uint8_t * so that we can access the uuid as a 'string' - this is different to a textual representation of a UUID. I would be willing to bet money that this can always be done since it's the only reasonable way to represent a UUID internally. Gianni _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |