Daniel Carosone wrote:

>There are two areas where we should look closely at how timecounters
>and the rnd(4) driver could interact:
>
> a) the rnd code presently tests for a cpu cycle counter
>    (__HAVE_CPU_COUNTER), and uses that if possible, otherwise it uses
>    microtime().
>
microtime() with timecounters is nice as it already uses up to
then available high resolution counters. but nanotime or bintime
would even be better when high resolution counters have been
registered and selected at the point.

> While I think continuing to use the cycle counter is
>    probably the right thing if present, it seems that timecounters
>    could have something better to offer in the microtime case at
>    least.  This is especially true as we presently don't call
>    microtime while cold, and on some platforms this leaves us even
>    shorter of startup seeding.
>  
>
we should be able to use a time seed in the absense of
a cycle counter while being cold in a timecounter environment.

> b) each time we detect a new timecounter, even though we may not
>    actually attach it as the active timecounter, we should look at
>    feeding the current counter value into rnd to help seed it with
>    initial entropy.
>
easy.

>  Perhaps also when we change timecounter
>    selection,
>
easy.

> as seems to happen several times through the boot
>    process on some machines, though perhaps that's redundant because
>    they change as they're probed anyway.
>  
>
they are only changed if they seem better by quality or frequency
(@same quality).

>More generally, it's been a few years now since I last had a campaign
>for adding rnd hooks into various drivers, and perhaps its time for
>another.  While people are reviewing drivers for powerhooks, could
>they also give consideration as to whether the device has anything to
>offer for rnd - especially at startup time.
>
>--
>Dan.
>  
>
Frank