From: Huang Ying <ying.huang@intel.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Akinobu Mita <akinobu.mita@gmail.com>,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
chris.mason@fusionio.com, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 2/9] uuid: use random32_get_bytes()
Date: Wed, 31 Oct 2012 09:35:37 +0800 [thread overview]
Message-ID: <1351647337.31033.13.camel@yhuang-dev> (raw)
In-Reply-To: <20121030044818.GA5972@thunk.org>
On Tue, 2012-10-30 at 00:48 -0400, Theodore Ts'o wrote:
> On Tue, Oct 30, 2012 at 09:49:58AM +0800, Huang Ying wrote:
> > The uuid_le/be_gen() in lib/uuid.c has set UUID variants to be DCE,
> > that is done in __uuid_gen_common() with "b[8] = (b[8] & 0x3F) | 0x80".
>
> Oh, I see, I missed that.
>
> > To deal with random number generation issue, how about use
> > get_random_bytes() in __uuid_gen_common()?
>
> We already have generate_random_uuid() in drivers/char/random.c, and
> no users for lib/uuid.c's equivalent uuid_be_gen(). So here's a
> counter-proposal, why don't we drop lib/uuid.c, and include in
> drivers/char/random.c:
>
> /*
> * Generate random GUID
> *
> * GUID's is like UUID's, but they uses the non-standard little-endian
> * layout, compared to what is defined in RFC-4112; it is primarily
> * used by the EFI specification.
> */
> void generate_random_guid(unsigned char uuid_out[16])
> {
> get_random_bytes(uuid_out, 16);
> /* Set UUID version to 4 --- truly random generation */
> uuid_out[7] = (uuid_out[7] & 0x0F) | 0x40;
> /* Set the UUID variant to DCE */
> uuid_out[8] = (uuid_out[8] & 0x3F) | 0x80;
> }
> EXPORT_SYMBOL(generate_random_guid);
>
> I really don't think it's worth it to have a __uuid_gen_common once we
> are using get_random_bytes(), since there isn't much code to be
> factored out, and it's simpler just to have two functions in one place.
The intention of lib/uuid.c is to unify various UUID related code, and
put them in same place. In addition to UUID generation, it provide some
other utility and may provide/collect more in the future. So do you
think it is a good idea to put generate_rand_uuid/guid into lib/uuid.c
and maybe change the name/prototype to make it consistent with other
uuid definitions?
> Using UUID vs. GUID I think makes things much clearer, since the EFI
> specification talks about GUID's, not UUID's, and that way we don't
> have to worry about people getting confused about whether they should
> be using the little-endian versus big-endian variant. (And I'd love
> to ask to whoever wrote the EFI specification what on *Earth* were
> they thinking when they decided to diverge from the rest of the
> world....)
I think that is a good idea. From Wikipedia, GUID is in native byte
order, while UUID is in internet byte order.
Best Regards,
Huang Ying
next prev parent reply other threads:[~2012-10-31 1:35 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-28 7:18 [PATCH 1/9] random32: introduce random32_get_bytes() and prandom32_get_bytes() Akinobu Mita
2012-10-28 7:18 ` Akinobu Mita
2012-10-28 7:18 ` [PATCH 2/9] uuid: use random32_get_bytes() Akinobu Mita
2012-10-29 20:52 ` Theodore Ts'o
2012-10-30 1:49 ` Huang Ying
2012-10-30 4:48 ` Theodore Ts'o
2012-10-31 1:35 ` Huang Ying [this message]
2012-10-31 2:38 ` Theodore Ts'o
2012-10-31 3:06 ` Huang Ying
2012-10-28 7:19 ` [PATCH 3/9] mtd: mtd_nandecctest: use random32_get_bytes instead of get_random_bytes() Akinobu Mita
2012-10-28 7:19 ` Akinobu Mita
2012-10-28 7:19 ` [PATCH 4/9] mtd: nandsim: use random32_get_bytes Akinobu Mita
2012-10-28 7:19 ` Akinobu Mita
2012-10-28 7:19 ` [PATCH 5/9] ubifs: " Akinobu Mita
2012-10-28 7:19 ` Akinobu Mita
2012-10-28 7:19 ` [PATCH 6/9] mtd: mtd_oobtest: convert to use prandom32_get_bytes() Akinobu Mita
2012-10-28 7:19 ` Akinobu Mita
2012-10-28 7:19 ` [PATCH 7/9] mtd: mtd_pagetest: " Akinobu Mita
2012-10-28 7:19 ` Akinobu Mita
2012-10-28 7:19 ` [PATCH 8/9] mtd: mtd_speedtest: use random32_get_bytes Akinobu Mita
2012-10-28 7:19 ` Akinobu Mita
2012-10-28 7:19 ` [PATCH 9/9] mtd: mtd_subpagetest: convert to use prandom32_get_bytes() Akinobu Mita
2012-10-28 7:19 ` Akinobu Mita
2012-10-29 20:39 ` [PATCH 1/9] random32: introduce random32_get_bytes() and prandom32_get_bytes() Theodore Ts'o
2012-10-29 20:39 ` Theodore Ts'o
2012-10-30 11:01 ` Akinobu Mita
2012-10-30 11:12 ` Akinobu Mita
2012-10-31 3:29 ` Theodore Ts'o
2012-10-31 3:29 ` Theodore Ts'o
2012-10-31 11:53 ` Akinobu Mita
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1351647337.31033.13.camel@yhuang-dev \
--to=ying.huang@intel.com \
--cc=akinobu.mita@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=chris.mason@fusionio.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.