[U-Boot] GUID/UUID string representation

[U-Boot] GUID/UUID string representation

[Palacios, Hector]

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

[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.

[U-Boot] GUID/UUID string representation

[Przemyslaw Marczak]

Hello,

On 07/30/2015 01:19 PM, 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
>
> 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?

Because it's defined by the specification and is the same as in the 
kernel. Please look at Apendix A of UEFI specification[1], which says 
about GUID text representation, which is simply shown in the table.
The binary format of guid is consistent with RFC4122[2], which says that 
both guid and uuid are binary equal, but different represented by text.

[1]: http://www.uefi.org/sites/default/files/resources/UEFI%202_5.pdf
[2]: https://www.ietf.org/rfc/rfc4122.txt

You can check it by printing gpt with:

  'mmc part' - let's store the guids somewhere

Then mount the same disk in linux, and next do:

  'ls -lhgG /dev/disk/by-partuuid/'

You can see, that even if the name is 'by-partuuid', the ids are 
displayed as GUIDs. Probably there is a bug with the path name, since 
uuid is a reserved name for "universally unique identifier".

> - Should the 'part uuid' return the UUID representation instead of the GUID?

It returns a string representation of partition id, which is GUID text 
format.

> - Should there be a 'part uuid' and a 'part guid' commands that return the different
> representations?

I don't think so, because there is only one text format in the standard.

> - 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?

You're right. This is inconsistent for string comparison - we can't just 
compare the UUID string with GUID, even if the 16 bytes binary buffer is 
the same.  I don't know why GPT support was introduced with uuid names, 
we have a functions to convert it in lib/uuid.c, so additional command 
could be added - but I think cleanup is better.

>
> 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
>

Thank you for pointing this issue.

After looking into the code, I found a bug in function 
gpt_fill_header(), which converts string to GUID, but it shouldn't, 
since we pass UUID's to gpt command.

So what can we do to fix this inconsistency:

- change the variable uuid_* to guid_* in the $partitions. This is a 
string representation compatible with specification.

- update str_format argument to UUID_STR_GUID in gen_rand_uuid_str() 
calls in gpt command.

Update uuid format argument in uuid_str_to_bin() calls:
- update UUID_STR_FORMAT_STD to FORMAT_GUID in gpt_fill_pte()

- leave UUID_STR_FORMAT_GUID in gpt_fill_header() - it is bug when UUID 
is generated in gpt command.

Stephen, is that good for you?

Best regards,
-- 
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marczak at samsung.com

[U-Boot] GUID/UUID string representation

[Stephen Warren]

On 07/31/2015 05:31 AM, Przemyslaw Marczak wrote:
> Hello,
>
> On 07/30/2015 01:19 PM, 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
>>
>> 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?
>
> Because it's defined by the specification and is the same as in the
> kernel. Please look at Apendix A of UEFI specification[1], which says
> about GUID text representation, which is simply shown in the table.
> The binary format of guid is consistent with RFC4122[2], which says that
> both guid and uuid are binary equal, but different represented by text.
>
> [1]: http://www.uefi.org/sites/default/files/resources/UEFI%202_5.pdf
> [2]: https://www.ietf.org/rfc/rfc4122.txt
>
> You can check it by printing gpt with:
>
>   'mmc part' - let's store the guids somewhere
>
> Then mount the same disk in linux, and next do:
>
>   'ls -lhgG /dev/disk/by-partuuid/'
>
> You can see, that even if the name is 'by-partuuid', the ids are
> displayed as GUIDs. Probably there is a bug with the path name, since
> uuid is a reserved name for "universally unique identifier".
>
>> - Should the 'part uuid' return the UUID representation instead of the
>> GUID?
>
> It returns a string representation of partition id, which is GUID text
> format.
>
>> - Should there be a 'part uuid' and a 'part guid' commands that return
>> the different
>> representations?
>
> I don't think so, because there is only one text format in the standard.
>
>> - 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?
>
> You're right. This is inconsistent for string comparison - we can't just
> compare the UUID string with GUID, even if the 16 bytes binary buffer is
> the same.  I don't know why GPT support was introduced with uuid names,
> we have a functions to convert it in lib/uuid.c, so additional command
> could be added - but I think cleanup is better.
>
>>
>> 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
>>
>
> Thank you for pointing this issue.
>
> After looking into the code, I found a bug in function
> gpt_fill_header(), which converts string to GUID, but it shouldn't,
> since we pass UUID's to gpt command.
>
> So what can we do to fix this inconsistency:
>
> - change the variable uuid_* to guid_* in the $partitions. This is a
> string representation compatible with specification.
>
> - update str_format argument to UUID_STR_GUID in gen_rand_uuid_str()
> calls in gpt command.
>
> Update uuid format argument in uuid_str_to_bin() calls:
> - update UUID_STR_FORMAT_STD to FORMAT_GUID in gpt_fill_pte()
>
> - leave UUID_STR_FORMAT_GUID in gpt_fill_header() - it is bug when UUID
> is generated in gpt command.
>
> Stephen, is that good for you?

I'm not completely sure what the implications of those changes are 
without tracking down all those functions. However, if it means zero 
changes to the text output of the "part list" and "part uuid" commands, 
then that seems fine.