Hi,
The UUID parsing logic was modified in 2.10 and is the following :
/*
         * As off version 2.6 of the SMBIOS specification, the first 3
         * fields of the UUID are supposed to be encoded on little-endian.
         * The specification says that this is the defacto standard,
         * however I've seen systems following RFC 4122 instead and use
         * network byte order, so I am reluctant to apply the byte-swapping
         * for older versions.
         */
        if (ver >= 0x0206)
                
printf("%02X%02X%02X%02X-%02X%02X-%02X%02X-%02X%02X-%02X%02X%02X%02X%02X%02X",
                        p[3], p[2], p[1], p[0], p[5], p[4], p[7], p[6],
                        p[8], p[9], p[10], p[11], p[12], p[13], p[14], p[15]);
        else
                
printf("%02X%02X%02X%02X-%02X%02X-%02X%02X-%02X%02X-%02X%02X%02X%02X%02X%02X",
                        p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7],
                        p[8], p[9], p[10], p[11], p[12], p[13], p[14], p[15]);


and so the output of dmidecode now depends on the SMBIOS version. This makes it 
more difficult to provide a decoder that is interoperabile with other UUID 
parsers (i.e the Windows WMI provider), that parses the same host UUID. I think 
that in it's current form this duality may cause backward compatbility issue 
with existing apps when SMBIOS 2.6 system go mainline (I don't know if there 
are any yet). So how about the following change:

1.      Add a cmdline paramter uuid-parse-logic={backward-compat|2.6-compat}
default for uuid-parse-logic is backward-compat
2.      Replace the above logic with:

if (uuid-parse-logic==2_6_COMPAT)
                
printf("%02X%02X%02X%02X-%02X%02X-%02X%02X-%02X%02X-%02X%02X%02X%02X%02X%02X",
                        p[3], p[2], p[1], p[0], p[5], p[4], p[7], p[6],
                        p[8], p[9], p[10], p[11], p[12], p[13], p[14], p[15]);
        else
                
printf("%02X%02X%02X%02X-%02X%02X-%02X%02X-%02X%02X-%02X%02X%02X%02X%02X%02X",
                        p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7],
                        p[8], p[9], p[10], p[11], p[12], p[13], p[14], p[15]);


thanks Dori

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel

Reply via email to