diff mbox

[v7,04/11] public: xen.h: add definitions for UUID handling

Message ID 1507150827-7858-5-git-send-email-volodymyr_babchuk@epam.com (mailing list archive)
State New, archived
Headers show

Commit Message

Volodymyr Babchuk Oct. 4, 2017, 9 p.m. UTC
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(+)

Comments

Konrad Rzeszutek Wilk Oct. 5, 2017, 1:03 p.m. UTC | #1
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
Volodymyr Babchuk Oct. 5, 2017, 2:50 p.m. UTC | #2
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
George Dunlap Oct. 9, 2017, 9:40 a.m. UTC | #3
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
Julien Grall Oct. 10, 2017, 3:19 p.m. UTC | #4
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,
Volodymyr Babchuk Oct. 10, 2017, 3:26 p.m. UTC | #5
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 mbox

Patch

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. */