On Sun, Dec 20, 2015 at 05:44:35PM -0500, Thor Lancelot Simon wrote: > > Even without the latter, surely there is value to the former. I > believe it would serve for a number of other CPUs; for example I > believe the RNG on Octeon and its successors is instruction based, > and this way we could have a _single_ rndsource driver for all > such CPUs rather than many drivers.
Not Octeon -- digging around, it must have been a different MIPSy thing I was playing with. So far, the original VIA design, plus the two Intel ones. I personally think it's nice to have an abstraction that covers at least these 3 cases, which I really do think is directly analogous to how we wrap cycle counter instructions with cpu_counter(). I can certainly wrap it in a rndsource, and drop the RNG code from the Padlock driver, though I am not so sure that is better than what I already did (again, please, I would really appreciate it if anyone would _look at the code_ and think about it before commenting!). If one doesn't think CPU RNGs are trustworthy (and many people seem not to) then I would submit one should be happier with what I did than with such a source wrapped in a rndsource, because what I did guarantees that every single CPU RNG sample is mixed with input from another source. And it's cheaper, and it's much less code. I can do it the other way too. But could I get anyone to look at the code and comment? Thor
