Re: [PATCH 1/5] Renaming weak prng invocations - prandom_bytes_state, prandom_u32_state

On Wed, Dec 14, 2022 at 05:53:52PM +0200, Andy Shevchenko wrote:

On Wed, Dec 14, 2022 at 04:15:49PM +0100, Eric Dumazet wrote:

quoted

On Wed, Dec 14, 2022 at 1:34 PM Stanislaw Gruszka
[off-list ref] wrote:

quoted

On Mon, Dec 12, 2022 at 03:35:20PM +0100, Jason A. Donenfeld wrote:

quoted

Please CC me on future revisions.

As of 6.2, the prandom namespace is *only* for predictable randomness.
There's no need to rename anything. So nack on this patch 1/5.

It is not obvious (for casual developers like me) that p in prandom
stands for predictable. Some renaming would be useful IMHO.

Renaming makes backports more complicated, because stable teams will
have to 'undo' name changes.
Stable teams are already overwhelmed by the amount of backports, and
silly merge conflicts.

Take another example :

u64 timecounter_read(struct timecounter *tc)

You would think this function would read the timecounter, right ?

Well, it _updates_ many fields from @tc, so a 'better name' would also
be useful.

Right, at some point we become into the world of

#define true 0

because... (read below)

quoted

linux kernel is not for casual readers.

P.S. I believe you applied a common sense and in some cases
     the renames are necessary.

And before you become to a wrong conclusion by reading between the lines,
no, I'm not taking either side (to rename or not to rename) in this case.

-- 
With Best Regards,
Andy Shevchenko