[dmidecode] [PATCH 2/3] dmidecode: Document how the UUID fields are interpreted

[Jean Delvare]

There has always been a lot of confusion about the byte order of UUID
fields. While dmidecode is doing "the right thing", documenting it
can't hurt.

This should address bug #55510:
https://savannah.nongnu.org/bugs/index.php?55510

Signed-off-by: Jean Delvare <address@hidden>
---
 man/dmidecode.8 |   14 ++++++++++++++
 1 file changed, 14 insertions(+)

--- dmidecode.orig/man/dmidecode.8      2019-01-22 10:51:57.672463446 +0100
+++ dmidecode/man/dmidecode.8   2019-01-22 11:25:16.499087809 +0100
@@ -256,6 +256,20 @@ It is crafted to hard-code the table add
 .IP \(bu "\w'\(bu'u+1n"
 The DMI table is located at offset 0x20.
 
+.SH UUID FORMAT
+There is some ambiguity about how to interpret the UUID fields prior to SMBIOS
+specification version 2.6. There was no mention of byte swapping, and RFC 4122
+says that no byte swapping should be applied by default. However, SMBIOS
+specification version 2.6 (and later) explicitly states that the first 3 fields
+of the UUID should be read as little-endian numbers (byte-swapped).
+Furthermore, it implies that the same was already true for older versions of
+the specification, even though it was not mentioned. In practice, many hardware
+vendors were not byte-swapping the UUID. So, in order to preserve
+compatibility, it was decided to interpret the UUID fields according to RFC
+4122 (no byte swapping) when the SMBIOS version is older than 2.6, and to
+interpret the first 3 fields as little-endian (byte-swapped) when the SMBIOS
+version is 2.6 or later. The Linux kernel follows the same logic.
+
 .SH FILES
 .I /dev/mem
 .br

-- 
Jean Delvare
SUSE L3 Support