Hi -
On Fri, Apr 18, 2008 at 08:46:44AM +0200, Peter Zijlstra wrote:
At least two answers apply. The markers being put in should be chosen
with the concurrence of the subsystem maintainer, who should help
identify those key quantities that are likely to be both long-lived
and good diagnostic value. So that's the discussion we're having
right now: which values should be passed. If they're long-lived, then
they can be given a long-lived name - and it doesn't have to be a
low-level C variable name. (There's no reason why we can't also have
a slew of short-lived pure-debugging sorts of markers compiled in. A
marker naming convention like "__futex..." can be adopted for such
purposes - where nothing is promised for version n+1, just hoping to
help diagnose problems in this version.)
The other answer is that we should ensure that tools do not assume
that the set of markers is fixed. Let's never set such an
expectation. (In systemtap, we have several abstraction and
version-adaptation facilities that aim to hide such changes.)
The kernel guy can choose at least two methods to help tools
without contraining himself too much. He can change
trace_mark(futex_foo, "p1 %d p2 %d", p1, p2);
to a pair:
trace_mark(futex_foo, "p1 %d p2 %d", 0, p2); // backward compat.
trace_mark(futex_foo2, "p2 %d p3 %d", p2, p3); // new marker
or even just drop the backward compatibility one altogether.
It will need judicious choices by the kernel and willingness by the
tools to keep up. Those that don't will simply notice fewer events
coming in, but nothing important *breaking*.
The current crop of tools (lttng, systemtap) are both from friendly
groups who recognize that they have more of an expendable diagnostic
rather than operational role, and thus are willing to carry that
burden. By the time new tools will show up, we will have more
experience with the degree and type of marker changes over time, and
they won't be in a position to place new constraints on the
establishment.
Indeed. This is why it's important for the subsystem maintainer to
wisely influence the markers as they go in.
It's not just that - it's a whole package including easy creation of
new markers, the code that manages their activation and deactivation,
the tool code that connects up to receive new events *and parameters*.
The current approach does not require tight compilation-level
coupling. Indeed, for a new marker, the current approach requires
*no* code changes to anywhere other than the one-line inserted marker,
for tools like systemtap to connect and use them. Cool eh?
- FChE
--
