--3MwIy2ne0vdjdPXF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 22, 2004 at 08:11:37PM -0700, Andrey Petrov wrote:
> On Fri, Apr 23, 2004 at 07:56:41AM +0900, enami tsugutomo wrote:
> > > , uvm_history seems closest by functionality but too tied to uvm and
> > > somewhat too heavy for .S codes.
> >=20
> > The latter is true but former is not.  I'm curious why do you think
>=20
> Have to agree 'too tied' is overstatement, I looked at uvmhist _after_
> I started using ktr so things like multiple buffers, explicit initializat=
ion,
> strlens and UVMHIST_FUNC presets looked excessive for what I need.

I don't think it's excessive. It's great for the time when you need just a=
=20
little bit more than what you have now.

Multiple buffers are so that different subsystems can log or not log as=20
they see fit. UVMHIST_FUNC lets you name what routine the events come=20
from. I agree you pretty much always want the name of the routine,so=20
__FUNCTION__ would have been fine..

The strlens seemed weird for me at first. But they make sense when you=20
remember that the history's dumped by a libkvm-using program in userland.=
=20
By having explicit lengths, extracting data from the kernel is much more=20
efficient.

Take care,

Bill

--3MwIy2ne0vdjdPXF
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFAiasVWz+3JHUci9cRAh0hAJ0TIxQHqncAGE64On9nVVUmrZaOcACeIPn2
2a6fJtN/9qKVW1LPjUWLgVo=
=TFOq
-----END PGP SIGNATURE-----

--3MwIy2ne0vdjdPXF--