Skip site navigation (1)Skip section navigation (2)
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>