Date: Thu, 27 Oct 2005 10:38:13 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: David Xu <davidxu@freebsd.org> Cc: current@freebsd.org Subject: Re: MySQL Performance 6.0rc1 Message-ID: <20051027103023.B32255@fledge.watson.org> In-Reply-To: <436099CE.50401@freebsd.org> References: <21137.1130401220@critter.freebsd.dk> <20051027092153.D31152@fledge.watson.org> <436099CE.50401@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 27 Oct 2005, David Xu wrote:
> Sorry, it is a bit OT, can we also dump thread id in ktrace output file?
> it may be useless for libpthread, but is useful for libthr.
I've been wondering about this also. The ktr_header record on face value
is of fixed size and layout, and the file format appears not to have a
notion of versioning:
/*
* ktrace record header
*/
struct ktr_header {
int ktr_len; /* length of buf */
short ktr_type; /* trace record type */
pid_t ktr_pid; /* process id */
char ktr_comm[MAXCOMLEN+1]; /* command name */
struct timeval ktr_time; /* timestamp */
void *ktr_buffer;
};
One can, however, imagine a few possibilities:
(1) Re-use the ktr_buffer field, recasting as intptr_t or the like, as
ktr_buffer is only used in kernel to point to the buffer, and as far
as I can tell, not used in userspace. The in-kernel ktr header can be
divorced from the on-disk version in order to provide a new pointer to
the buffer. This would provide backward and forward compatibility,
although obviously old kdump's wouldn't be able to print the thread
id.
(2) Ignore forward compatibility, but add a heuristic to identify old file
versions. For example, the new file format could begin with a struct
with a magic number, and the magic number could be an unlikely file
size, such as -1.
I prefer (1), I think, if we're just adding a thread id and the thread id
will fit in the pointer field. On the other hand, the existing header
leaves much to be desired, such as missing a version number, spare fields,
etc, and it's easy to imagine we might want more things in the header in
the future, so I'd be willing to go with (2).
Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051027103023.B32255>