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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
