> Date: Mon, 9 Nov 2020 14:52:12 +0000 > From: Stuart Henderson <[email protected]> > > 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.
ok, fair enough, I don't really care all that much
