Subject: Re: lwp id in ktrace
To: matthew green <>
From: Bill Studenmund <>
List: tech-kern
Date: 12/01/2003 15:34:40
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 02, 2003 at 08:28:05AM +1100, matthew green wrote:
>   =20
>    I think the best way to do this is to have ktrace request a newer vers=
>    of the file format. That's the only way you can know what version of t=
>    file format userland can deal with. So it sounds like it's time to ver=
>    the ktrace syscall. :-|
>   =20
>    Oh, I am assuming that kdump will be in sync with ktrace. Since userla=
>    gets updated all-at-once, that assumption seems fine. This way ktrace =
>    never ask for a file format its kdump can't understand.
> it was my understanding that ktrace doesn't actually write the records
> to disk, but the kernel does directly.  one would assume that ktrace/kdump
> would be in sync, yet, but i didn't think that helped...

Right. But ktrace (as I understand it) asks the kernel to write the=20
records to the file. So the idea is that ktrace would have to explicitly=20
request that thread ids be in the file; it would have to ask for something=
different from what the file format's been forever. :-)

Yes, the kernel would need to be able to write two different file formats.=
COMPAT_XX (COMPAT_16 for now) would cover the code to generate the old=20

The ktrace/kdump in sync business is to work on getting you what I think=20
you want when you asked for new kernel + old userland to still work.

Since the kdump binary format left no room for versioning, if we want=20
future kdump formats to be understandable by older kdump programs, we=20
really constrain what we can do. So to litterally support what you said,=20
we're in a corner. Christos has shown us wiggle room, but we're still=20
wiggling around. ;-)

I loosened what you asked for a bit. I assumed you really meant you want=20
to be able to try a new kernel, and still be able to ktrace programs. I=20
think this is an important thing to be able to do. By assuming that ktrace=
and kdump are in sync, I can trust that ktrace won't ask for a file format=
that the in-userland kdump won't understand.

So by making ktrace(2) have to explicitly request lwp_ids, we get around=20
the problem.

Take care,


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

Version: GnuPG v1.2.3 (NetBSD)