Hi Jason,
There are two variants only of the CP0 Random register that we can ever
encounter, as it's been de-facto standardised in early 1990s already and
then written down in the MIPSr1 architecture specification ~2000. So I
think it may make sense to actually handle them both explictitly with
individual calculations, possibly conditionalised on a CONFIG setting or
`cpu_has_3kex', because kernels that support the two variants of the MMU
architecture are mutually incompatible.
Okay, I can give this a shot, but this certainly isn't my forté. It
may ultimately wind up being simpler for you to just send some code of
what you envision for this, but if I understand your idea correctly,
what you're saying is something like:
static inline unsigned long random_get_entropy(void)
{
unsigned int prid = read_c0_prid();
unsigned int imp = prid & PRID_IMP_MASK;
unsigned int c0_random;
if (can_use_mips_counter(prid))
return read_c0_count();
if (cpu_has_3kex)
c0_random = (read_c0_random() >> 8) & 0x3f;
else
c0_random = read_c0_random() & 0x3f;
return (random_get_entropy_fallback() << 6) | (0x3f - c0_random);
}
What do you think of that? Some tweak I'm missing?
It certainly looks good to me. Do you have a way I could verify how this
function performs? If so, then I could put it through my systems as I can
cover all the cases handled here.
Any improvements I previously discussed can then be made locally in the
MIPS port as follow-up changes.
Isn't it going to be an issue for an entropy source that the distribution
of values obtained from the CP0 Random bit-field is not even, that is some
values from the 6-bit range will never appear?
It's the same situation without inverting the order: instead of some
bits on the top never happening, some bits on the bottom never happen
instead. In general, counters don't form uniform distributions anyway,
since the lower bits change faster, and neither are they independent,
since one sample in large part depends on the previous. This is just
sort of the nature of the beast, and the code that calls
random_get_entropy() deals with this appropriately (by, at the moment,
just hashing all the bits).
OK then, thanks for your clarification.
Maciej
