| Message ID | 1507662348-12963-1-git-send-email-volodymyr_babchuk@epam.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, 10 Oct 2017, 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: 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. > > Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> > --- > > * Fixed code formatting > * Added parenthess around (xen_uuid_t)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..3d5edc6 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. */ This looks good to me, but I would like to get Jan's opinion on this. Ideally we would commit the series tomorrow before the code freeze.
>>> On 11.10.17 at 01:24, <sstabellini@kernel.org> wrote: > On Tue, 10 Oct 2017, Volodymyr Babchuk wrote: >> --- 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. */ > > This looks good to me, but I would like to get Jan's opinion on this. > Ideally we would commit the series tomorrow before the code freeze. While I can live with it being the way it is now, I've already indicated that I'd prefer __GNUC__ to also be checked for here. As that's a relaxation, it wouldn't be a problem to add later, I think (but I can't exclude I'm overlooking something, so it would feel better if it was done the intended final way from the beginning). Jan
Hi Jan, On 11/10/17 09:54, Jan Beulich wrote: >>>> On 11.10.17 at 01:24, <sstabellini@kernel.org> wrote: >> On Tue, 10 Oct 2017, Volodymyr Babchuk wrote: >>> --- 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. */ >> >> This looks good to me, but I would like to get Jan's opinion on this. >> Ideally we would commit the series tomorrow before the code freeze. > > While I can live with it being the way it is now, I've already > indicated that I'd prefer __GNUC__ to also be checked for > here. As that's a relaxation, it wouldn't be a problem to add > later, I think (but I can't exclude I'm overlooking something, > so it would feel better if it was done the intended final way > from the beginning). To be clear, you ask to do: #if defined(__GNUC__) || (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) am I correct? Cheers,
>>> On 11.10.17 at 11:29, <julien.grall@linaro.org> wrote: > Hi Jan, > > On 11/10/17 09:54, Jan Beulich wrote: >>>>> On 11.10.17 at 01:24, <sstabellini@kernel.org> wrote: >>> On Tue, 10 Oct 2017, Volodymyr Babchuk wrote: >>>> --- 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. */ >>> >>> This looks good to me, but I would like to get Jan's opinion on this. >>> Ideally we would commit the series tomorrow before the code freeze. >> >> While I can live with it being the way it is now, I've already >> indicated that I'd prefer __GNUC__ to also be checked for >> here. As that's a relaxation, it wouldn't be a problem to add >> later, I think (but I can't exclude I'm overlooking something, >> so it would feel better if it was done the intended final way >> from the beginning). > > To be clear, you ask to do: > > #if defined(__GNUC__) || (defined(__STDC_VERSION__) && __STDC_VERSION__ > >= 199901L) > > am I correct? Assuming this works for the range of gcc versions we support (which I assume it does), then yes. (Cosmetic remark: I'd put the compiler specific check last.) Jan
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h index 2ac6b1e..3d5edc6 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: 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. Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> --- * Fixed code formatting * Added parenthess around (xen_uuid_t)XEN_DEFINE_UUID_(..) --- xen/include/public/xen.h | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+)