[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c62985530811140639k1004a8f9k968c3e0949d1a309@mail.gmail.com>
Date: Fri, 14 Nov 2008 15:39:29 +0100
From: "Frédéric Weisbecker" <fweisbec@...il.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Cc: rostedt@...dmis.org, mingo@...e.hu, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] ftrace: Add debug_print trace to print data from kernel to userspace
2008/11/14 Aneesh Kumar K.V <aneesh.kumar@...ux.vnet.ibm.com>:
> We also want to make sure dp_printk doesn't do anything when tracer
> is disabled. We do
>
> int do_dp_printk(const char *fmt, ...)
> {
> int ret;
> va_list args;
>
> if (!tracer_enabled)
> return 0;
In this case you just have to do
echo 0 > /debug/tracing/tracing_enabled
And the entries will not be printed anymore....
> .........
> .......
>
>>
>>
>>
>> > +static void dp_trace_ctrl_update(struct trace_array *tr)
>> > +{
>> > + /* When starting a new trace, reset the buffers */
>> > + if (tr->ctrl)
>> > + start_dp_trace(tr);
>> > + else
>> > + stop_dp_trace(tr);
>> > +}
>>
>>
>> BTW, ctrl_update() have been removed very recently.
>> Perhaps are you implementing this against the mainline? Its a better idea to
>> submit a new tracer against latest -tip tree.
>
> Yes the patches are against mainline.
> I am looking at this. I don't see TRACE_TYPE_PARTIAL_LINE in other
> places in the code. Will look more.
This return has been set because several entries can be submitted to a
tracer before it finally reach the user.
If the last one submitted didn't fir is the remaining free bytes in
the seq, then we want to tell the tracing api that
the seq is full and we want this entry to be handled later.
If you don't use it, you could loose entries.
Have a look in trace.c, trace_boot.c, trace_mmiotrace.c, all of these
make use of this return value.
See latest -tip:
git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
> What I wanted to get was a dmesg style output. The default output will
> add pid and other information. That is why i did a print_line callback.
I understand...
Why not append a flag to ignore pid/cpu/timestamp on the output in trace.c ?
> I also wanted to drop the header in the trace file. I didn't find a way
> to do that.
This one should be dropped too when the flag I mentioned above is set....
Currently, when one cat /debug/tracing/trace, we have these headers,
whatever the current tracer is.
This thing could be fixed...
Perhaps others would have better ideas....
--
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/
Powered by blists - more mailing lists