linux-kernel - Re: [PATCH 2/2] tracing/function-return-tracer: Call prepare_ftrace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 14 Nov 2008 00:48:14 +0100
From:	"Frédéric Weisbecker" <fweisbec@...il.com>
To:	"Ingo Molnar" <mingo@...e.hu>
Cc:	"Steven Rostedt" <rostedt@...dmis.org>,
	"Linux Kernel" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] tracing/function-return-tracer: Call prepare_ftrace_return by registers

2008/11/13 Ingo Molnar <mingo@...e.hu>:
>
> * Frédéric Weisbecker <fweisbec@...il.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/