--Vmb+IyT2VBRvgrJP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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().  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.

 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.  Perhaps also when we change timecounter
    selection, 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.

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.

--Vmb+IyT2VBRvgrJP
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFEmfOGEAVxvV4N66cRAmqaAKCqTzFfmIW0ly9Izjyrr/tPO/9JewCg57zj
eYpKPwvcNqVjQ5HfcK5Qiic=
=y7iP
-----END PGP SIGNATURE-----

--Vmb+IyT2VBRvgrJP--