* Andrew Morton wrote:
> On Wed, 25 Feb 2009 10:56:23 +0100 Ingo Molnar wrote:
> > Since the concept of a kernel tracing facility being
> > self-sufficient and being easy to use is an integral and key
> > concept to ftrace, dont you see why people take your
> > suggestions as a dismissal of the ftrace concept?
> Nothing I've suggested in any way makes ftrace hard to use.
Note that everything you suggest is _already possible_, if you
switch on the 'make simple output' option. It's just that the
human-readable format is the default one.
So i think your suggestion does make ftrace harder to use, in a
number of ways:
- There's one more extra tool to be installed on the target
machine. That target machine might not even have any build
environment - but tracing on it can still be very useful to
pin down bugs and regressions.
Self-sufficient kernel instrumentation is a key concept to
- That tool will break the current intuitive shell-commands and
scripting flow that is based on human readable text output.
In ftrace we try to strike a good balance between easy
scriptability and pretty-printing. The two go hand in hand
usually so it's not a big task. If you look at the current
/debug/tracing/trace output you'll find a lot of small
details that we've put in there to make it easy to script -
while still being nice to read. [suggestions to improve it
Your suggestion pushes that completely to the 'minimal
output' direction, with no tangible benefit to scripting, and
with a lot of damage to readability and usability. A separate
pretty-printing tool would just add an extra unnecessary step
and would make the workflow more clumsy. This too is a clear
- Plus the extra effort of defining APIs and ABIs to it and the
extra effort to make it work on all kernel versions. It all
takes away resources from making tracing more useful in
practice so it indirectly hurts instrumentation usability.
Tracing development manpower is a zero-sum game. If you force
people to maintain silly APIs you take away time from other,
more important areas. It might even be a negative-sum game:
developing something that looks ugly and is hard to use
attracts less developers. Tracing under Linux was in such a
zombie state for a decade and ftrace clearly changed that
picture. I dont subscribe to the view that tracing has to be
stupid and boring.
I.e. i dont see many upsides of your suggestion, and i see a lot
IMO pretty-printing in the kernel should not be made a religious
argument but a technical argument. Pretty-printing is a tool,
and as a tool it sometimes can be used for silly purposes, and
sometimes it can be used for helpful purposes. You seem to argue
that doing it in the kernel is always silly - and i strongly
disagree with that and consider it an extreme-end position - for
the reasons outlined above.