[U-Boot] GUID/UUID string representation
Palacios, Hector
Hector.Palacios at digi.com
Thu Jul 30 13:19:28 CEST 2015
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
Partition Map for MMC device 0 -- Partition Type: EFI
Part Start LBA End LBA Name
Attributes
Type GUID
Partition GUID
1 0x00001000 0x00020fff "linux"
attrs: 0x0000000000000000
type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
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?
- 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?
- 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?
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.
Thanks
--
Hector
More information about the U-Boot
mailing list