Hello Stephen,

On 03/25/2014 08:28 PM, Stephen Warren wrote:
On 03/19/2014 11:58 AM, Przemyslaw Marczak wrote:
This patch adds support to generate UUID (Universally Unique Identifier)
in version 4 based on RFC4122, which is randomly.

Source: https://www.ietf.org/rfc/rfc4122.txt

Some nits in the comments below, but otherwise:
Acked-by: Stephen Warren <swar...@nvidia.com>

diff --git a/include/uuid.h b/include/uuid.h

+/* This is structure is in big-endian */
+struct uuid {

Not any more; with the introduction of enum uuid_str_t, some of the
fields could be either LE or BE. I would say "See the comment near the
top of lib/uuid.c for details of the endianness of fields in this struct".


No, those fields are always in big-endian. So no matter what is architecture endianess - this data should be stored as big endian. Only string representation has different character order for GUID.

diff --git a/lib/uuid.c b/lib/uuid.c

  /*
   * UUID - Universally Unique IDentifier - 128 bits unique number.
   *        There are 5 versions and one variant of UUID defined by RFC4122
- *        specification. Depends on version uuid number base on a time,
- *        host name, MAC address or random data.
+ *        specification. Depends on version uuid number base on:

I still have no idea what "Depends on version uuid number base on" means.


It means that each UUID version "result" depends on different source data, as listed here...

+ *        - time, MAC address(v1),
+ *        - user ID(v2),
+ *        - MD5 of name or URL(v3),
+ *        - random data(v4),
+ *        - SHA-1 of name or URL(v5),
+ *
+ * This library implements UUID v4.

I think that should say "gen_rand_uuid()" not "This library", since the
source of the data in the UUID fields only matters when creating the
UUID, not when performing str<->bin conversion.


Yes, right notice.

+ *
+ * Layout of UUID Version 4:

I should remove "Version 4" in the comment subject, because layout refers to all uuid versions.

+ * timestamp - 60-bit: time_low, time_mid, time_hi_and_version
+ * version   - 4 bit (bit 4 through 7 of the time_hi_and_version)
+ * clock seq - 14 bit: clock_seq_hi_and_reserved, clock_seq_low
+ * variant:  - bit 6 and 7 of clock_seq_hi_and_reserved
+ * node      - 48 bit
+ * In this version all fields beside 4 bit version are randomly generated.
+ * source: https://www.ietf.org/rfc/rfc4122.txt

gen_rand_uuid() doesn't actually honor that format; it creates pure
random data rather than filling in any timestamps, clock sequence data, etc.


Actually, yes but two fields are NOT set randomly, and this is what comment includes:
"In this version all fields beside 4 bit version are randomly generated."
Moreover the gen_rand_uuid() respects endianess for setting bits,
and this could be checked on linux host by "uuid -d uboot_uuid_string" in shell.

Thanks
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to