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

On Mon, Dec 01, 2003 at 12:30:32PM -0500, Christos Zoulas wrote:
> On Dec 1,  3:52pm, manu@netbsd.org (Emmanuel Dreyfus) wrote:
> -- Subject: Re: lwp id in ktrace
>=20
> | What's wrong with shortening the name string so that we get enough extra
> | bytes to point to a xheader record? Having the old binary displaying
> | shorter names is better than having it displaying nothing...
>=20
> That is a cute idea. Do we really need the backwards compatibility though,
> at the expense of making the file a lot larger? There is of course the
> following hack that gives backwards compatibility and lwpid if < 64K:

I don't think we need backwards compatability that is that strong.

I don't think we need an old kdump to be able to read a ktrace file with=20
thread info in it. What we need is for an old ktrace running on a new=20
kernel to not generate a file that it and its kdump will choke on. Thus=20
it's ok (I propose) for such a file to be missing information (the thread=
=20
IDs).

So I'm proposing we define different versions of the file format. Version=
=20
0 is the non-thread-id version (what we've had up until now), and version=
=20
1 is the thread-id version. We version the ktrace system call, and the new=
=20
call adds a file version. If you use the old call, you implicitly are=20
asking for version 0 of the file. Version 1 (and later versions) will have=
=20
a version record in it, and a file without a version record is in the=20
version 0 format.

My concerns with what you proposed earlier is that: 1) thread ids can be=20
bigger than 64k. While I admit it will be unlikely any time soon that we=20
will be seeing lwp ids that big, we may, and I'd rather we not paint=20
ourselves into a corner now. 2) We're postponing releasing the pain of=20
changing ktrace file formats. I admit we will do it infrequently, say=20
every 5 to 10 years, but we will do it again. Someday. :-)

Take care,

Bill

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

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

iD8DBQE/y4jNWz+3JHUci9cRAlfEAJ0SCaIHih9jczj6+Thvwgc4BHA+JgCcCva+
pa4XdmQ26FbferHyN4uoC3A=
=c7hS
-----END PGP SIGNATURE-----

--WYTEVAkct0FjGQmd--