]> git.ipfire.org Git - thirdparty/open-vm-tools.git/commitdiff
Common header file change not applicable to open-vm-tools.
authorJohn Wolfe <jwolfe@vmware.com>
Tue, 27 Oct 2020 00:29:54 +0000 (17:29 -0700)
committerJohn Wolfe <jwolfe@vmware.com>
Tue, 27 Oct 2020 00:29:54 +0000 (17:29 -0700)
open-vm-tools/lib/include/uuid.h

index 6029f6151db6c0bf37b81ff4e1d269b3886c4572..82c530844eab3a16546e438db4fe86ab90e63323 100644 (file)
@@ -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