[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080920071232.46908040@infradead.org>
Date: Sat, 20 Sep 2008 07:12:32 -0700
From: Arjan van de Ven <arjan@...radead.org>
To: Mathieu Desnoyers <compudj@...stal.dyndns.org>
Cc: Steven Rostedt <rostedt@...dmis.org>,
Martin Bligh <mbligh@...gle.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>, od@...ell.com,
"Frank Ch. Eigler" <fche@...hat.com>
Subject: Re: Unified tracing buffer
On Sat, 20 Sep 2008 09:55:48 -0400
Mathieu Desnoyers <compudj@...stal.dyndns.org> wrote:
> How about :
>
> trace_mark(ftrace_evname, "size %lu binary %pW",
> sizeof(mystruct), mystruct);
> or
> trace_mark(sched_wakeup, "target_pid %ld", task->pid);
>
> Note the namespacing with buffers being "ftrace" and "sched" here.
>
> That would encapsulate the whole
> - Event ID registration
> - Event type registration
> - Sending data out
> - Enabling the event source directly at the source
>
> We can then export the markers through a debugfs file and let userland
> enable them one by one and possibly connect systemtap filters on them
> (one table of registered filters, one table for the markers, a command
> file to connect/disconnect filters to/from markers).
I would like to ask for the following from the start: have a field for
a longer description of the marker that describes it's usage and
context. Getting this there from the start is critical, because only
when adding the marker point do people still really remember why/what
(and having to type a good description also helps them to realize if
this is the right point or not). This can then be exposed to the user
so he has a standing chance of knowing what the marker is about.
It also has a standing chance of being updated when the code changes
this way
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
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