MySQL Performance 6.0rc1
Robert Watson
rwatson at FreeBSD.org
Thu Oct 27 02:38:14 PDT 2005
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
More information about the freebsd-current
mailing list