--O3RTKUHj+75w1tg5
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=
ion=20
>    of the file format. That's the only way you can know what version of t=
he=20
>    file format userland can deal with. So it sounds like it's time to ver=
sion=20
>    the ktrace syscall. :-|
>   =20
>    Oh, I am assuming that kdump will be in sync with ktrace. Since userla=
nd=20
>    gets updated all-at-once, that assumption seems fine. This way ktrace =
will=20
>    never ask for a file format its kdump can't understand.
>=20
>=20
> 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=
=20
different from what the file format's been forever. :-)

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

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=
=20
and kdump are in sync, I can trust that ktrace won't ask for a file format=
=20
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,

Bill

--O3RTKUHj+75w1tg5
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE/y9AQWz+3JHUci9cRAqwOAJ4zZdpfUkByuiCj73e7xnRTlzWKrQCeKDLS
Qb2z13X3MkC9PZ5Rhyry6s4=
=8KzB
-----END PGP SIGNATURE-----

--O3RTKUHj+75w1tg5--