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 <jdelv...@suse.de> --- 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 _______________________________________________ https://lists.nongnu.org/mailman/listinfo/dmidecode-devel
