TRACE_EVENT_ABI

By Jonathan Corbet
September 30, 2009

Tracepoints are proving to be increasingly useful as system development and diagnostic tools. There is one question about tracepoints, though, which has not yet gotten a real answer: do tracepoints constitute a user-space ABI? If so, some serious constraints come into play. An ABI, once exposed, cannot be changed in a way which might break applications. Tracepoints, being tightly tied to the kernel code they instrument, are inherently hard to keep stable. If a tracepoint cannot be modified or removed, it will make modifications to the surrounding code harder. In the worst case, ABI-preservation requirements could block the incorporation of important kernel changes - an outcome which could quickly sour developers on the tracepoint idea as a whole.

Arjan van de Ven's TRACE_EVENT_ABI patch is an attempt to bring some clarity to the situation. For now, it just defines a tracepoint in exactly the same way as TRACE_EVENT; the difference is that it is meant to create a tracepoint which can be relied upon as part of the kernel ABI. Such tracepoints should continue to exist in future kernel releases, and the format of the associated trace information will not change in application-breaking ways. What that means in practice is that no fields would be deleted, and any new fields would be added at the end.

Whether this approach will work remains to be seen. The word from Linus in the past has been that kernel ABIs are created by applications which rely on an interface, rather than any specific marking on the interface itself. So if people start using applications which expect to be able to use a specific tracepoint, that tracepoint may be set in cement regardless of whether it was defined with TRACE_EVENT_ABI. This macro would thus be a good guide to the kernel developers' intent, but it can make no guarantee that only specially-marked tracepoints will be subject to ABI stability requirements.

Index entries for this article
Kernel	Development tools/Kernel tracing
Kernel	Tracing/ABI issues

TRACE_EVENT_ABI

Posted Oct 1, 2009 3:29 UTC (Thu) by davecb (subscriber, #1574) [Link]

To beat a slightly ailing horse, once can have a versioned interface which allows evolution. Paul Stachour (and I) have an upcoming queue article on the subject.

--dave

TRACE_EVENT_ABI

Posted Oct 1, 2009 7:41 UTC (Thu) by ajb (subscriber, #9694) [Link]

Maybe debug features should only be enabled after the user has pressed a magic sysrq key (or equivalent). That way, a user application can't depend on the feature.

Or at least, it would be obvious which applications were dumb enough to depend on debug features, because they would have to put up a requester asking the user to press the key before they used it.

TRACE_EVENT_ABI

Posted Oct 1, 2009 8:11 UTC (Thu) by mjthayer (guest, #39183) [Link] (1 responses)

I would have thought that many uses of tracepoints (like hacking up a script to trace down an immediate issue) would not really need a stable ABI, beyond perhaps one or two kernel versions. Other applications might like a stable ABI, but not necessarily a "forever stable" one (an ABI of the sort "we won't break it if we can reasonably avoid doing so"). Which applications would really need a longterm stable ABI then, and what sort of tracepoints might they need?

TRACE_EVENT_ABI

Posted Oct 2, 2009 14:34 UTC (Fri) by addw (guest, #1771) [Link]

I could not have put this better myself.