On Fri, Jun 21, 2024 at 01:00:51PM +0200, Heinrich Schuchardt wrote: (..)
The current specification is in RFC 9562, 4.1, "Variant field"
"The variant field consists of a variable number of the most significant bits of octet 8 of the UUID.
...
Specifically for UUIDs in this document, bits 64 and 65 of the UUID (bits 0 and 1 of octet 8) MUST be set to 1 and 0 as specified in row 2 of Table 1."
This reference to byte 8 does not depend on endianness.
Hi Heinrich,
Agreed, variant is not concerned by the endianness.
U-Boot's include/uuid.h has:
/* This is structure is in big-endian */ struct uuid {The field time_hi_and_version needs to be stored in big-endian fashion.
Thanks! I thought this structure was used to hold either a big-endian UUID or a little-endian GUID, but now you have convinced me.
This confirms that the generation of the dynamic GUID is missing something:
gen_uuid_v5(&namespace, (struct uuid *)&fw_array[i].image_type_id, compatible, strlen(compatible), fw_array[i].fw_name, u16_strsize(fw_array[i].fw_name) - sizeof(uint16_t), NULL);
It is not possible to cast the little-endian efi_guid_t .image_type_id as the big-endian struct uuid output of gen_uuid_v5() like this; we need to convert the three time fields from big to little endianness.
tools/genguid uses UUID_STR_FORMAT_GUID which prints low-endian which is typical in the EFI context but not understood by 'uuid -d'. Maybe we should add a parameter for the output format.
My understanding is that there is a single universal string format for both UUIDs and GUIDs, which uuid -d understands, and which has no notion of endianness. (Only the structures in memory have an endianness.) This means we do not need an output format parameter.
genguid is calling the new gen_uuid_v5() function, which outputs a big-endian struct uuid. Therefore, genguid should print it with 'STD format, not 'GUID.
Best regards, Vincent.
Best regards
Heinrich