Re: MySQL Performance 6.0rc1

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