>> You still need instrumentation in the kernel to intercept the system
>> call, so the amount of kernel code used by ktrace and truss should
>> be pretty much the same.

It's not really fair to compare the two.  ktrace traces more than just
syscalls; in particular, ptrace-style tracing cannot do the equivalent
of GENIO, CSW, or NAMEI ktracing (though with sufficient awareness of
what syscalls handle I/O, it can come pretty close to GENIO).  But
ktrace doesn't trace things like ioctl argument contents or (the one
that annoys me most) bind() and connect() sockaddr contents.

> No - because IIRC all the instructions on how to format the data are
> embedded in the kernel for ktrace, whereas truss only requires that
> the kernel stop the process on system call entry/exit.

But the code to handle that is not entirely trivial.

There are numerous differences between ktrace and ptrace-style tracing;
depending on what your environment and desires are, one or the other
may be a clear winner.  There are times when I definitely want one and
other times when I definitely want the other.  Neither one is large
enough that I'd leave it out of my routine kernels for size reasons
(assuming it's available, which is only marginally true for
PT_SYSCALL).  I don't see any real value in trying to decide which one
is "better" in the absence of a clear description of the relevant
environment.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B