[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAC5umyhje4oDtKzw6kYSXw99rVzZJOaeApfizGeDos3SnmUcjA@mail.gmail.com>
Date: Tue, 30 Oct 2012 20:01:01 +0900
From: Akinobu Mita <akinobu.mita@...il.com>
To: "Theodore Ts'o" <tytso@....edu>,
Akinobu Mita <akinobu.mita@...il.com>,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
Artem Bityutskiy <dedekind1@...il.com>,
Adrian Hunter <adrian.hunter@...el.com>,
David Woodhouse <dwmw2@...radead.org>,
linux-mtd@...ts.infradead.org
Subject: Re: [PATCH 1/9] random32: introduce random32_get_bytes() and prandom32_get_bytes()
2012/10/30 Theodore Ts'o <tytso@....edu>:
> On Sun, Oct 28, 2012 at 04:18:58PM +0900, Akinobu Mita wrote:
>> /**
>> + * prandom32_get_bytes - get the requested number of pseudo-random bytes
>> + * @state: pointer to state structure holding seeded state.
>> + * @buf: where to copy the pseudo-random bytes to
>> + * @bytes: the requested number of bytes
>> + *
>> + * This is used for pseudo-randomness with no outside seeding.
>> + * For more random results, use random32_get_bytes().
>> + */
>> +
>> +/**
>> + * random32_get_bytes - get the requested number of pseudo-random bytes
>> + * @buf: where to copy the pseudo-random bytes to
>> + * @bytes: the requested number of bytes
>> + */
>
> This naming scheme is going to be very confusing. If the function is
> going to return a pseudo-random number, it *must* have a "prandom"
> suffix. Otherwise some kernel developer, somewhere, will get confused
> between get_random_bytes() and random32_get_bytes(), and the result
> may be a very embarassing security exposure.
>
> How about prandom32_get_bytes_state() and prandom32_get_bytes() instead?
I agree with your suggestion. I'll rename them and try again.
By the way, should we also rename the existing random32() and
prandom32() in the future?
Specifically, rename random32() to prandom32(), and prandom32() to
prandom32_state(). As a result, it will cause a little confusion
between old and new prandom32(). But the number of arguments will
be changed from 3 to 2, so gcc can detect the misuse of prandom32().
Is there any other idea of renaming? Or should we keep them as is?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists