Subject: Re: timecounters and rnd(4)
To: Frank Kardel <kardel@netbsd.org>
From: Daniel Carosone <dan@geek.com.au>
List: tech-kern
Date: 06/23/2006 18:47:25
--VbXIs2ae+j0NhctA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Jun 23, 2006 at 09:11:33AM +0200, Frank Kardel wrote:
> 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.
My initial guess was that getnanotime() was probably what was wanted,
then trying to understand the difference between the get* and plain
variants led me on the manpage search discussed elsewhere.
I'd also like to better understand some of the boundary conditions
early in boot: how soon is it safe/sensible to call timecounters, what
do i get if no sources have been registered yet, etc. Note that for
this usage, I don't necessarily care ifI get back a time of 0 (or
whatever), as long as I don't cause a panic as microtime apparently
can on some platforms.
> we should be able to use a time seed in the absense of
> a cycle counter while being cold in a timecounter environment.
Excellent, I'd hoped so.
> >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.
cool
> > Perhaps also when we change timecounter
> > selection,
> >
> easy.
>=20
> >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.
> >=20
> >
> they are only changed if they seem better by quality or frequency
> (@same quality).
What I meant was that the time sample when the counter is detected,
and the sample when the default is changed immediately after, are
probably going to differ by a ~constant amount each boot, if at all -
so doing both of the above isn't worthwhile.
--
Dan.
--VbXIs2ae+j0NhctA
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)
iD4DBQFEm6qcEAVxvV4N66cRAv1sAKCpVsfI0JEzIOoBpxOjPKZjffAvjwCYlIdw
/Hti09O2b80ckGh5J5ApUQ==
=MzHr
-----END PGP SIGNATURE-----
--VbXIs2ae+j0NhctA--