Message ID | 1507150827-7858-5-git-send-email-volodymyr_babchuk@epam.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Thu, Oct 05, 2017 at 12:00:20AM +0300, Volodymyr Babchuk wrote: > Added type xen_uuid_t. This type represents UUID as an array of 16 > bytes in big endian format. > > Added macro XEN_DEFINE_UUID that constructs UUID in the usual way: > > XEN_DEFINE_UUID(0x00112233, 0x4455, 0x6677, 0x8899, > 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff) > > will construct UUID 00112233-4455-6677-8899-aabbccddeeff presented as > {0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, > 0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff} > > NB: This is compatible with Linux kernel and with libuuid, but it is not > compatible with Microsoft, as they use mixed-endian encoding (some > components are little-endian, some are big-endian). Oh boy. What a mess. Do we care about Microsoft for this or is this more for information purpose? > > Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> > --- > > * Fixed example for XEN_DEFINE_UUID() usage. Was > XEN_DEFINE_UUID(0x00112233, 0x4455, 0x6677, 0x8899, 0xaabbccddeeff) > > * Added comment to xen.h > > * Used > #if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L > instead of > #if defined(__GNUC__) && !defined(__STRICT_ANSI__) > > * Used generic macro XEN_DEFINE_UUID_ > > --- > xen/include/public/xen.h | 33 +++++++++++++++++++++++++++++++++ > 1 file changed, 33 insertions(+) > > diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h > index 2ac6b1e..1a6255f 100644 > --- a/xen/include/public/xen.h > +++ b/xen/include/public/xen.h > @@ -930,6 +930,39 @@ __DEFINE_XEN_GUEST_HANDLE(uint16, uint16_t); > __DEFINE_XEN_GUEST_HANDLE(uint32, uint32_t); > __DEFINE_XEN_GUEST_HANDLE(uint64, uint64_t); > > +typedef struct > +{ > + uint8_t a[16]; > +} xen_uuid_t; > + > +/* > + * XEN_DEFINE_UUID(0x00112233, 0x4455, 0x6677, 0x8899, > + * 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff) > + * will construct UUID 00112233-4455-6677-8899-aabbccddeeff presented as > + * {0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, > + * 0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff}; > + * > + * NB: This is compatible with Linux kernel and with libuuid, but it is not > + * compatible with Microsoft, as they use mixed-endian encoding (some > + * components are little-endian, some are big-endian). > + */ > +#define XEN_DEFINE_UUID_(a, b, c, d, e1, e2, e3, e4, e5, e6) \ > + {{((a) >> 24) & 0xFF, ((a) >> 16) & 0xFF, \ > + ((a) >> 8) & 0xFF, ((a) >> 0) & 0xFF, \ > + ((b) >> 8) & 0xFF, ((b) >> 0) & 0xFF, \ > + ((c) >> 8) & 0xFF, ((c) >> 0) & 0xFF, \ > + ((d) >> 8) & 0xFF, ((d) >> 0) & 0xFF, \ > + e1, e2, e3, e4, e5, e6}} > + > +/* Compound literals are supported in C99 and later. */ > +#if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L > +#define XEN_DEFINE_UUID(a, b, c, d, e1, e2, e3, e4, e5, e6) \ > + (xen_uuid_t)XEN_DEFINE_UUID_(a, b, c, d, e1, e2, e3, e4, e5, e6) > +#else > +#define XEN_DEFINE_UUID(a, b, c, d, e1, e2, e3, e4, e5, e6) \ > + XEN_DEFINE_UUID_(a, b, c, d, e1, e2, e3, e4, e5, e6) > +#endif /* defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L */ > + > #endif /* !__ASSEMBLY__ */ > > /* Default definitions for macros used by domctl/sysctl. */ > -- > 2.7.4 > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel
Hi Konrad, On 05.10.17 16:03, Konrad Rzeszutek Wilk wrote: > On Thu, Oct 05, 2017 at 12:00:20AM +0300, Volodymyr Babchuk wrote: >> Added type xen_uuid_t. This type represents UUID as an array of 16 >> bytes in big endian format. >> >> Added macro XEN_DEFINE_UUID that constructs UUID in the usual way: >> >> XEN_DEFINE_UUID(0x00112233, 0x4455, 0x6677, 0x8899, >> 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff) >> >> will construct UUID 00112233-4455-6677-8899-aabbccddeeff presented as >> {0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, >> 0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff} >> >> NB: This is compatible with Linux kernel and with libuuid, but it is not >> compatible with Microsoft, as they use mixed-endian encoding (some >> components are little-endian, some are big-endian). > > Oh boy. What a mess. > > Do we care about Microsoft for this or is this more for information > purpose? This is for information. Problem is that XEN already defines EFI_GUID which uses MS-style encoding. It is used in EFI code only, but I think it is worth to explain differences. There was discussion at [1] [...] [1] http://markmail.org/message/cawi6f33spqg4hf5 Thanks, Volodymyr
On 10/05/2017 03:50 PM, Volodymyr Babchuk wrote: > Hi Konrad, > > On 05.10.17 16:03, Konrad Rzeszutek Wilk wrote: >> On Thu, Oct 05, 2017 at 12:00:20AM +0300, Volodymyr Babchuk wrote: >>> Added type xen_uuid_t. This type represents UUID as an array of 16 >>> bytes in big endian format. >>> >>> Added macro XEN_DEFINE_UUID that constructs UUID in the usual way: >>> >>> XEN_DEFINE_UUID(0x00112233, 0x4455, 0x6677, 0x8899, >>> 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff) >>> >>> will construct UUID 00112233-4455-6677-8899-aabbccddeeff presented as >>> {0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, >>> 0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff} >>> >>> NB: This is compatible with Linux kernel and with libuuid, but it is not >>> compatible with Microsoft, as they use mixed-endian encoding (some >>> components are little-endian, some are big-endian). >> >> Oh boy. What a mess. >> >> Do we care about Microsoft for this or is this more for information >> purpose? > This is for information. Problem is that XEN already defines EFI_GUID > which uses MS-style encoding. It is used in EFI code only, but I think > it is worth to explain differences. > There was discussion at [1] > [...] > > [1] http://markmail.org/message/cawi6f33spqg4hf5 So did you perhaps mean to say something like this: "NB: We define a new structure here rather than re-using EFI_GUID. EFI_GUID uses a Microsoft-style encoding which, among other things, mixes little-endian and big-endian. The structure defined in this patch, unlike EFI_GUID, is compatible with the Linux kernel and libuuid." -George
Hi, On 09/10/17 10:40, George Dunlap wrote: > On 10/05/2017 03:50 PM, Volodymyr Babchuk wrote: >> Hi Konrad, >> >> On 05.10.17 16:03, Konrad Rzeszutek Wilk wrote: >>> On Thu, Oct 05, 2017 at 12:00:20AM +0300, Volodymyr Babchuk wrote: >>>> Added type xen_uuid_t. This type represents UUID as an array of 16 >>>> bytes in big endian format. >>>> >>>> Added macro XEN_DEFINE_UUID that constructs UUID in the usual way: >>>> >>>> XEN_DEFINE_UUID(0x00112233, 0x4455, 0x6677, 0x8899, >>>> 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff) >>>> >>>> will construct UUID 00112233-4455-6677-8899-aabbccddeeff presented as >>>> {0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, >>>> 0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff} >>>> >>>> NB: This is compatible with Linux kernel and with libuuid, but it is not >>>> compatible with Microsoft, as they use mixed-endian encoding (some >>>> components are little-endian, some are big-endian). >>> >>> Oh boy. What a mess. >>> >>> Do we care about Microsoft for this or is this more for information >>> purpose? >> This is for information. Problem is that XEN already defines EFI_GUID >> which uses MS-style encoding. It is used in EFI code only, but I think >> it is worth to explain differences. >> There was discussion at [1] >> [...] >> >> [1] http://markmail.org/message/cawi6f33spqg4hf5 > > So did you perhaps mean to say something like this: > > "NB: We define a new structure here rather than re-using EFI_GUID. > EFI_GUID uses a Microsoft-style encoding which, among other things, > mixes little-endian and big-endian. The structure defined in this > patch, unlike EFI_GUID, is compatible with the Linux kernel and libuuid." Volodymyr, do you have any opinions here? This is basically the last patch that needs to be acked before merged (thought there are few nits to fix). I would really like to see this patch merged before the code freeze tomorrow. Cheers,
Hi Julien, On 10.10.17 18:19, Julien Grall wrote: > Hi, > > On 09/10/17 10:40, George Dunlap wrote: >> On 10/05/2017 03:50 PM, Volodymyr Babchuk wrote: >>> Hi Konrad, >>> >>> On 05.10.17 16:03, Konrad Rzeszutek Wilk wrote: >>>> On Thu, Oct 05, 2017 at 12:00:20AM +0300, Volodymyr Babchuk wrote: >>>>> Added type xen_uuid_t. This type represents UUID as an array of 16 >>>>> bytes in big endian format. >>>>> >>>>> Added macro XEN_DEFINE_UUID that constructs UUID in the usual way: >>>>> >>>>> XEN_DEFINE_UUID(0x00112233, 0x4455, 0x6677, 0x8899, >>>>> 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff) >>>>> >>>>> will construct UUID 00112233-4455-6677-8899-aabbccddeeff presented as >>>>> {0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, >>>>> 0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff} >>>>> >>>>> NB: This is compatible with Linux kernel and with libuuid, but it >>>>> is not >>>>> compatible with Microsoft, as they use mixed-endian encoding (some >>>>> components are little-endian, some are big-endian). >>>> >>>> Oh boy. What a mess. >>>> >>>> Do we care about Microsoft for this or is this more for information >>>> purpose? >>> This is for information. Problem is that XEN already defines EFI_GUID >>> which uses MS-style encoding. It is used in EFI code only, but I think >>> it is worth to explain differences. >>> There was discussion at [1] >>> [...] >>> >>> [1] http://markmail.org/message/cawi6f33spqg4hf5 >> >> So did you perhaps mean to say something like this: >> >> "NB: We define a new structure here rather than re-using EFI_GUID. >> EFI_GUID uses a Microsoft-style encoding which, among other things, >> mixes little-endian and big-endian. The structure defined in this >> patch, unlike EFI_GUID, is compatible with the Linux kernel and libuuid." > > Volodymyr, do you have any opinions here? > > This is basically the last patch that needs to be acked before merged > (thought there are few nits to fix). I would really like to see this > patch merged before the code freeze tomorrow. I'm perfectly fine with proposed comment. I'm preparing v8 right now.
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h index 2ac6b1e..1a6255f 100644 --- a/xen/include/public/xen.h +++ b/xen/include/public/xen.h @@ -930,6 +930,39 @@ __DEFINE_XEN_GUEST_HANDLE(uint16, uint16_t); __DEFINE_XEN_GUEST_HANDLE(uint32, uint32_t); __DEFINE_XEN_GUEST_HANDLE(uint64, uint64_t); +typedef struct +{ + uint8_t a[16]; +} xen_uuid_t; + +/* + * XEN_DEFINE_UUID(0x00112233, 0x4455, 0x6677, 0x8899, + * 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff) + * will construct UUID 00112233-4455-6677-8899-aabbccddeeff presented as + * {0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, + * 0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff}; + * + * NB: This is compatible with Linux kernel and with libuuid, but it is not + * compatible with Microsoft, as they use mixed-endian encoding (some + * components are little-endian, some are big-endian). + */ +#define XEN_DEFINE_UUID_(a, b, c, d, e1, e2, e3, e4, e5, e6) \ + {{((a) >> 24) & 0xFF, ((a) >> 16) & 0xFF, \ + ((a) >> 8) & 0xFF, ((a) >> 0) & 0xFF, \ + ((b) >> 8) & 0xFF, ((b) >> 0) & 0xFF, \ + ((c) >> 8) & 0xFF, ((c) >> 0) & 0xFF, \ + ((d) >> 8) & 0xFF, ((d) >> 0) & 0xFF, \ + e1, e2, e3, e4, e5, e6}} + +/* Compound literals are supported in C99 and later. */ +#if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L +#define XEN_DEFINE_UUID(a, b, c, d, e1, e2, e3, e4, e5, e6) \ + (xen_uuid_t)XEN_DEFINE_UUID_(a, b, c, d, e1, e2, e3, e4, e5, e6) +#else +#define XEN_DEFINE_UUID(a, b, c, d, e1, e2, e3, e4, e5, e6) \ + XEN_DEFINE_UUID_(a, b, c, d, e1, e2, e3, e4, e5, e6) +#endif /* defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L */ + #endif /* !__ASSEMBLY__ */ /* Default definitions for macros used by domctl/sysctl. */
Added type xen_uuid_t. This type represents UUID as an array of 16 bytes in big endian format. Added macro XEN_DEFINE_UUID that constructs UUID in the usual way: XEN_DEFINE_UUID(0x00112233, 0x4455, 0x6677, 0x8899, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff) will construct UUID 00112233-4455-6677-8899-aabbccddeeff presented as {0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff} NB: This is compatible with Linux kernel and with libuuid, but it is not compatible with Microsoft, as they use mixed-endian encoding (some components are little-endian, some are big-endian). Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> --- * Fixed example for XEN_DEFINE_UUID() usage. Was XEN_DEFINE_UUID(0x00112233, 0x4455, 0x6677, 0x8899, 0xaabbccddeeff) * Added comment to xen.h * Used #if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L instead of #if defined(__GNUC__) && !defined(__STRICT_ANSI__) * Used generic macro XEN_DEFINE_UUID_ --- xen/include/public/xen.h | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+)