Messages in this thread | | | Date | Fri, 14 Nov 2008 00:48:14 +0100 | From | "Frédéric Weisbecker" <> | Subject | Re: [PATCH 2/2] tracing/function-return-tracer: Call prepare_ftrace_return by registers |
| |
2008/11/13 Ingo Molnar <mingo@elte.hu>: > > * Frédéric Weisbecker <fweisbec@gmail.com> wrote: > >> That's right, it's much more better for the eyes. I didn't want to >> output such a disposition from the kernel because I thought that >> would result in too much strings work from kernel-space. But >> actually, as you suggest, >> if I append a depth field in the trace that could be easy and not >> so costly. I just have a last thought about post-processing parsing. >> Would it make it harder for that? > > humans are the priority targets for tracer output - tools are a > distant second target. Whatever is nice for humans is also usually > easy to process via tools. A tool can set an option flag just fine. > > To help tooling, add a trace_options flag for more predictable/faster > output. We already have the binary output format for example. > >> Why not a flag that could be set through iter_ctrl (which has >> changed its name yesterday) and that could let the user to choose >> its output? That's where I renew my proposition to make the tracers >> able to propose custom flags for this file with a new callback such >> as tracer_ctrl, or tracer_opt. > > yes, your proposal is fine. > >> But as you say, why not set it through a flag. > > yes - and make the defaults for flags favor human visual parsing. > >> > Easiest would be to add a depth field to the trace entry as well, to >> > make sure we get the right depth in the end, even if we somehow mix up >> > the trace entries. >> >> Yeah, that's good! I will just have to output "\t" * depth to have >> the correct indentation. > > i'd suggest spaces for the function indentation, because we'll also > have quite deep call stacks in practice. > > and i'd suggest you flip around the cost field to something like: > > [...] > getnstimeofday() { > set_normalized_timespec() { > clocksource_read() { > ( 1547 ns) acpi_pm_read() > ( 1951 ns) } clocksource_read() > ( 2200 ns) } set_normalized_timespec() > ( 2354 ns) } getnstimeofday() > > that makes it fixed-width up to the inevitable variable-length field, > the function name. > > Ingo >
Ok, I will add all of these in my workqueue. Thanks :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |