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

On Mon, Dec 01, 2003 at 05:27:10PM +1100, matthew green wrote:
>=20
>    On Nov 27, 10:08am, mrg@eterna.com.au (matthew green) wrote:
>    -- Subject: re: lwp id in ktrace
>   =20
>    Yes, by adding a version record. If that record is absent, then we fall
>    back to the old code.
>   =20
>    christos
>   =20
>    |   =20
>    |    I've been thinking about this, and I cannot see how we can do it =
easily
>    |    in a backwards compatible way. Unfortunately there is no header i=
n the
>    |    ktrace.out files so that we can deduce the version (we could add =
a version
>    |    header now though).=20
>    |=20
>    | is there a way to change the output such that old kdump will simply
>    | fail gracefully with new input?
>    -- End of excerpt from matthew green
>   =20
>   =20
> i don't think you understood what i asked.  can you make it such
> that with:
>=20
> 	- older userland (ktrace/kdump)
>=20
> 	- new kernel
>=20
> running the old kdump on the new ktrace.out file would cause it
> to fail gracefully, rather than report crap.

I think the best way to do this is to have ktrace request a newer version=
=20
of the file format. That's the only way you can know what version of the=20
file format userland can deal with. So it sounds like it's time to version=
=20
the ktrace syscall. :-|

Oh, I am assuming that kdump will be in sync with ktrace. Since userland=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.

Take care,

Bill

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

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

iD8DBQE/y4E5Wz+3JHUci9cRAhSFAJsFjdWaglwMts7FFupoIhZ2pYL9EgCcDJF4
mNcT6lVWZGCSnuhPjAffyk4=
=j9Yk
-----END PGP SIGNATURE-----

--BXVAT5kNtrzKuDFl--