From: John Wolfe <jwolfe@vmware.com>
Date: Tue, 27 Oct 2020 00:29:54 +0000 (-0700)
Subject: Common header file change not applicable to open-vm-tools.
X-Git-Tag: stable-11.3.0~283
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=8bc0c0b8e3274cbfacb4ab1ace1a1fb644b66c64;p=thirdparty%2Fopen-vm-tools.git

Common header file change not applicable to open-vm-tools.
---

diff --git a/open-vm-tools/lib/include/uuid.h b/open-vm-tools/lib/include/uuid.h
index 6029f6151..82c530844 100644
--- a/open-vm-tools/lib/include/uuid.h
+++ b/open-vm-tools/lib/include/uuid.h
@@ -62,11 +62,25 @@ typedef enum {
 #define UUID_CREATE_CURRENT  2  /* the current scheme - always the latest */
 
 
+/*
+ * RFC 4122-compliant UUIDs and UEFI/Microsoft GUIDs are essentially
+ * the same thing except for byte-ordering issues.  Although their
+ * fields are named differently, the meanings are the same.  The only
+ * important difference is that RFC 4122 recommends always storing and
+ * transmitting binary UUIDs with the multi-byte fields in network
+ * byte order (big-endian), while binary UEFI/Microsoft GUIDs are
+ * typically stored and transmitted with the first three fields in x86
+ * CPU native order (little-endian).  But both UUIDs and GUIDs use the
+ * same canonical text format representation, in which the hex digits
+ * are in big-endian order.  Details of each are below.
+ */
+
 /*
  * An RFC 4122-compliant UUID.
  *
- * See RFC 4122 section 4.1.2 (Layout and Byte Order). All multi-byte types are
- * stored in big-endian (most significant byte first) order.
+ * See RFC 4122 section 4.1.2 (Layout and Byte Order). The RFC
+ * recommends that multi-byte types be stored in big-endian (most
+ * significant byte first) order.
  *
  * The UUID packed text string
  *    00112233-4455-6677-8899-AABBCCDDEEFF
@@ -84,6 +98,13 @@ typedef enum {
  *    node[5] = 0xFF
  * and the structure is stored as the sequence of bytes
  *    00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF
+ *
+ * Confusingly, some applications use the field names from this
+ * definition but store timeLow, timeMid, and timeHiAndVersion in
+ * little-endian order as UEFI/Microsoft GUIDs do; for example, the
+ * SMBIOS standard does so.  In that case, the structure is stored as
+ * the sequence of bytes
+ *    33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF
  */
 
 typedef