[U-Boot] GUID/UUID string representation

[Stephen Warren]

On 07/30/2015 05:19 AM, Palacios, Hector wrote:
> Hello,
>
> Commit d718ded056eefb6239bd2e0a57b7f6d99c6e9e4b introduced translation of UUID binary
> data to GUID string representation.
>
> So, for example, if I use the 'gpt' command to create a partition table and pass a
> 'uuid' parameter like this:
> => gpt write mmc 0
> "uuid_disk=${uuid_disk};start=2MiB,name=linux,size=64MiB,uuid=43f1961b-ce4c-4e6c-8f22-2230c5d532bd;"
>
> As a result, when I print the partition table I get:
> => part list mmc 0
...
>          guid:   1b96f143-4cce-6c4e-8f22-2230c5d532bd
>
> which prints the GUID string representation of my supplied UUID (with endian change on
> the first three parts).
>
> The command 'part uuid' (despite its name) returns this same GUID representation:
> => part uuid mmc 0
> 1b96f143-4cce-6c4e-8f22-2230c5d532bd
>
> I have some questions:
> - Why is preferred the GUID representation when listing the partition table?

I don't recall being aware of a difference between "GUID" and "UUID" 
representation.

The data format and terminology implemented in "part uuid" and "part 
list" were driven by the Linux kernel's root=PARTUUID command-line 
option, which "part uuid" was implemented to support. I imagine the 
phrase "UUID" in the kernel was intended to mean "a unique ID" rather 
than implying anything about the specific UUID-vs-GUID data format?

> - Should the 'part uuid' return the UUID representation instead of the GUID?
> - Should there be a 'part uuid' and a 'part guid' commands that return the different
> representations?

Perhaps in retrospect given your information about GUID-vs-UUID, the 
command naming might have been chosen differently

> - Isn't it a bit inconsistent that the 'gpt' command reads the 'uuid' parameter in
> UUID string representation and the 'part uuid' and 'part list' represent the number in
> GUID?

True. I would consider this a bug in the gpt command, which IIRC was 
added after the part command.

Is the GUID format useful elsewhere?

Perhaps the solution is to add flags to "gpt" and "part" that tell it 
which format to parse/emit? Presumably we'd also need to add a command 
to convert strings between GUID and UUID formats, since the kernel is 
presumably always going to want what it currently wants for the 
root=PARTUUID command-line option.

> It may all sound as a futile discussion but in v2013.04 I had some variables to store
> the UUID numbers for my partitions that I used to generate the partition table, and
> then compared these variables with the values returned by 'part uuid' (as strings).
> Now on v2015.04 the strings do not match due to this endianness change on the
> representation.