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--