[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080426203306.2e41fb55@daedalus.pq.iki.fi>
Date: Sat, 26 Apr 2008 20:33:06 +0300
From: Pekka Paalanen <pq@....fi>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
Steven Rostedt <rostedt@...dmis.org>, akpm@...l.org,
Peter Zijlstra <peterz@...radead.org>,
Soeren Sandmann Pedersen <sandmann@...hat.com>,
Steven Rostedt <srostedt@...hat.com>
Subject: Re: [PATCH 2/3] ftrace: add trace pipe header pluggin
On Mon, 21 Apr 2008 17:09:37 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:
> This patch adds a method for open_pipe and open_read to the pluggins
> so that they can add a header to the trace pipe call.
>
> Signed-off-by: Steven Rostedt <srostedt@...hat.com>
In addition to this, I think I need tracer::close method called on
tracing_release_pipe(). Use case: the reader closes the pipe before
I have printed all of my header, i.e. walked through all PCI devices,
so I need to properly destroy trace_iterator::private.
I also intend to use trace_iterator::seq for printing my header, so I
am looking if I can reuse code from tracing_read_pipe(). Looks like I'll
extract the "return any leftover data" part into a separate function.
To check trace_iterator::overrun, I'd like to be able to use
for_each_tracing_cpu(), but that is local to trace.c.
What happens when the tracing cpu mask changes? Mmiotrace does not take
that into account and will continue to record with all CPUs, will this
lead to problems, when mmiotrace starts to support SMP properly?
Now that I think of it, I probably want to use for_each_online_cpu()
in checking for overruns... but that's not good either, if someone
enables/disables a cpu during tracing. I guess you will have to / had to
deal with this case in tracing core, too.
Thanks.
--
Pekka Paalanen
http://www.iki.fi/pq/
--
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