Would it help to define the tracepoints deeper in the kernel internals as kernel version-dependent APIs, and warn that any application or script using them may be tied to a few kernel versions? It might help if the user space APIs for accessing static tracepoints were able to fail with something equivalent to "tracepoint no longer available", and this was clearly documented. And including the version number of the kernel where the tracepoint first appeared in the tracepoint name might be a hint too. Presumably though most users of these tracepoints would be sufficiently tied to those kernel versions anyway that this would not be such an issue.
Posted Apr 28, 2009 18:13 UTC (Tue) by fuhchee (subscriber, #40059)
[Link]
> It might help if the user space APIs for accessing static tracepoints were
> able to fail with something equivalent to "tracepoint no longer available",
> and this was clearly documented
It's not an API in the sense of a programming interface, but the way
systemtap exposes tracepoints (and indeed any other event source such
as kprobes, utrace events, timers, ....), is that an attempt to attach
to a facility that does not exist/match results in just such an error
message.
Systemtap also has some facilities to adapt to changes in kernels and
elsewhere, using both a preprocessor construct (similar to a #if
KERNEL_VERSION), and a syntax to specify a list of alternative sources
of the same events (the "?" and "!" operators in a probe point sequence).
So systemtap's use of tracepoints in no way imposes a requirement that
they be unmodified and permanent.
On the value of static tracepoints
Posted Apr 28, 2009 19:59 UTC (Tue) by ajb (subscriber, #9694)
[Link]
Maybe these developer-only API's should only get enabled by a magic sysrq key being pressed on the console. That way software which uses them can't become embedded in end-user software.