On Sun, Oct 30, 2005 at 01:26:57PM -0500, Christos Zoulas wrote:
> On Oct 30,  9:42am, chuq@chuq.com (Chuck Silvers) wrote:
> -- Subject: Re: what is the status of the ktrace-lwp branch?
> 
> | this issue isn't endianness, it's 32-vs-64.  the ktrace file format uses
> | this structure:
> | 
> | struct ktr_header {
> | 	int	ktr_len;		/* length of ktr_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 */
> | 	const void *ktr_buf;
> | };
> | 
> | and then can be a variable-length blob after that.  the timeval, buf pointer
> | (what the heck is a kernel pointer doing in a file format anyway?), and the
> | contents of the variable blob will all be different when written by 32-bit
> | vs. 64-bit kernels.  there's no good way to tell which format the file is,
> | so they're basically not portable between platforms.   (oh, the implicit
> | padding in this structure is bound to cause compatibility problems as well.)
> 
> Yes, but I am not sure if it is worth-while providing cross platform
> portability for ktrace records. It is not very easy to achieve and will
> bloat the 32 bit ktrace files.

Well, I agree with Chuck here. Having a working 32bit vs. 64bit ktrace
is important even on the most common architecture: x86. It would be
annoying at best to have e.g. a 32bit chroot in which the ktrace can't
work.

Joerg