On 2020/11/09 15:28, Mark Kettenis wrote: > > I think it would be correct to change our code to follow the spec, > > but reading the manual of current versions of dmidecode it goes a bit > > further; > > > > 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. > > > > It would seem sensible to follow that lead here I think? Diff for that > > below. > > > > I don't think many people will be making existing use of hw.uuid but it > > is possible, I don't think there's much we can do other than mention it > > in upgrade notes. > > Given that explanation, I'd argue that we should leave things as-is. > Folks interpreted the standard differently and in the end our > interpretation won. Adding more code to "fix" this issue doesn't make
Our interpretation only won for pre-2.6 SMBIOS versions.. > a lot of sense to me. Besides, where in the documentation is it > spelled out that hw.uuid matches the SMBIOS UUID? I suppose this is true, it only says "The universal unique identification number assigned to the machine". But we do also suggest using it in pxeboot(8) and anyone doing this will need the id with the standard interpretation.
