Despite the similar names, ktr(4) and ktrace(1) are completely unrelated.

KTR just a facility for logging strings in the kernel. It's very primitive, there's just a global ring buffer in the kernel that can be dumped with ktrdump(8) or via ddb. It's not compiled into the kernel by default, so not very convenient to use. It's still handy for some niche purposes, but it's really aimed at kernel developers.

I would maybe drop the "drivers" part since they are a subset of the kernelspace things you can trace.

I have to break this line somewhere and I think this is a good place to do it. Thanks for the heads-up.

Hitting 80 characters there hence the break.

If you combine the whole line it gets to 79 characters.

I considered that, but decided against that for now because dtrace(1) mentions those now and I'd like to avoid bit rot in this manual page by having an outdated list in the future.

Hmm, old news then. Thanks for noticing!

Thanks! I did not know. I addressed that.

This dash was for a parser Warner abandoned

I might add a hedge, like "and potentially on production systems"--some of these features have high overhead.

It's a bit odd to describe truss as an alternative to dtrace when dtrace is in the "kernel tracing" section while here we're in "userland tracing".

I would just explain directly what it does: it traces system calls and pretty-prints arguments. It uses sysdecode(3) for the latter purpose, which would be nice to reference here.

ktrace also belongs here, it's mostly for debugging user programs. Like truss, it mainly traces system calls, but 1) it doesn't use ptrace(2), it asynchronously logs entries to a file (typically ktrace.out), configured with ktrace(2) 2) it can log other types of events, e.g., page faults, name lookups, etc. (see the documentation for -t in the ktrace(1) docs).

I would argue that "one of the classic interfaces" is a bit unclear here: what are the other classic interfaces? What does "classic" mean here? I think this can be phrased more simply.

I think this is supposed to be, "The domain of kernel tracing does not belong solely to dtrace"? I'm not sure this sentence is very useful.

Let's maybe be more specific? "It lets kernel programmers log events to a global ring buffer, which can later be dumped using ktrdump(8)."

Thanks a lot, Mark. It clarifies a lot. I've incorporated your notes into the manual.

Good point. I'll just drop that. I wanted to note here that DTrace can be used for kernel tracing but considering that this manual page is just a short intro to available tracers, there is no need to create those little notes for users. If someone ends up reading tracing(7), they will surely not miss the DTrace section that says DTrace is useful for both kernel and userland tracing.