From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 09:38:14 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B3FD416A41F; Thu, 27 Oct 2005 09:38:14 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68F5043D46; Thu, 27 Oct 2005 09:38:14 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 6371E46B93; Thu, 27 Oct 2005 05:38:13 -0400 (EDT) Date: Thu, 27 Oct 2005 10:38:13 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: David Xu In-Reply-To: <436099CE.50401@freebsd.org> Message-ID: <20051027103023.B32255@fledge.watson.org> References: <21137.1130401220@critter.freebsd.dk> <20051027092153.D31152@fledge.watson.org> <436099CE.50401@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: MySQL Performance 6.0rc1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2005 09:38:14 -0000 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