Notes from the LPC scheduler microconference

While "consider everything unstable" is attractive to kernel hacker,s there are some tracepoints it doesn't make sense to erase, mostly those that map to syscalls and to user-visible operations, you'll never have a kernel that doesn't create processes, so tracepoints of that nature are stable; nor will you one that removes already-present syscalls like read(), so that tracepoint is stable too.

More generally, I think, the stability of a tracepoint is the same as the stability of the thing it is tracing. Function-based tracing is totally unstable because nobody expects the names of functions in the kernel to remain the same forever. Syscall tracing or proc:: process-state tracing is stable because, in the one case, there is an explicit guarantee about the stability of syscalls (at least, those that actually get used); in the other case, it is difficult to imagine a Unix-like kernel not implementing a way to create processes, or fork, and you'd attach those tracepoints to wherever it was you did that.

So I think we are in violent agreement here. (DTrace for Linux has gone further: the tracepoints, their type information, and the information about which D types they are translated to -- possibly turning one argument into many -- are all recorded nowhere but in the tracepoint declarations in the source code, and thus in a specialized section which is sucked out and parsed into argument types at DTrace module load time.)