On Thu, Apr 14, 2022 at 12:38:49AM +0200, Jason A. Donenfeld wrote:
Hi Rob,
On Wed, Apr 13, 2022 at 4:32 PM Rob Herring <robh@xxxxxxxxxx> wrote:
'does not have a usable get_cycles(), ...' as clearly some arches have
get_cycles() and yet still need a fallback.
Why not handle the 'if get_cycles() returns 0 do the fallback' within
a weak random_get_entropy() function? Then more arches don't need any
random_get_entropy() implementation.
No, this doesn't really work. Actually, most archs don't need a
random_get_entropy() function, because it exists in asm-generic doing
the thing we want. So that's taken care of. But weak functions as you
suggested would be quite suboptimal, because on, e.g. x86, what we
have now gets inlined into a single rdtsc instruction. Also, the
relation between get_cycles() and random_get_entropy() doesn't always
hold; some archs may not have a working get_cycles() function but do
have a path for a random_get_entropy(). Etc, etc. So I'm pretty sure
that this commit is really the most simple and optimal thing to do. I
really don't want to go the weak functions route.
Is random_get_entropy() a hot path?
It doesn't have to be a weak function, but look at it this way. We have
the following possibilities for what random_get_entropy() does:
- get_cycles()
- get_cycles() but returns 0 sometimes
- returns 0
- something else
You're handling the 3rd case.
For the 2nd case, that's riscv, arm, nios2, and x86. That's not a lot,
but is 2 or 3 of the most widely used architectures. Is it really too
much to ask to support the 2nd case in the generic code/header?
Rob
