From: Steven Rostedt <rostedt@goodmis.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: mingo@redhat.com, hpa@zytor.com, mathieu.desnoyers@polymtl.ca,
linux-kernel@vger.kernel.org, randy.dunlap@oracle.com,
wcohen@redhat.com, fweisbec@gmail.com, tglx@linutronix.de,
jbaron@redhat.com, mhiramat@redhat.com,
linux-tip-commits@vger.kernel.org, Christoph Hellwig <hch@lst.de>
Subject: Re: [tip:perf/core] tracing: Add DEFINE_EVENT(), DEFINE_SINGLE_EVENT() support to docbook
Date: Wed, 02 Dec 2009 09:28:29 -0500 [thread overview]
Message-ID: <1259764109.12870.37.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <20091202140128.GA2611@elte.hu>
On Wed, 2009-12-02 at 15:01 +0100, Ingo Molnar wrote:
> > DECLARE_CLASS_AND_DEFINE_EVENT()
>
> Hm, that's a bit too long. How about 'DEFINE_CLASS_EVENT()' as a
> compromise? It's similarly short-ish to TRACE_EVENT(), and it also
> conveys the fact that we create both a class and an event there.
>
> The full series would thus be:
>
> DECLARE_EVENT_CLASS
> DEFINE_EVENT
> DEFINE_CLASS_EVENT
>
> hm?
I thought about that too, but it actually makes it more confusing.
Because, looking at this with a fresh POV, I would think that after I
declare a class, I would use DEFINE_CLASS_EVENT with that class.
But that is looking at it out of context. Since the parameters show
exactly what is going on, it may be fine.
I really would like to get a comment from somebody not developing
tracers but using them. Because I think we are so ingrained in this,
that we have lost the outsider's POV.
So, with the above names, this is an example:
DECLARE_EVENT_CLASS(sched_wakeup_template,
TP_PROTO(struct rq *rq, struct task_struct *p, int success),
TP_ARGS(rq, p, success),
TP_STRUCT__entry(
__array( char, comm, TASK_COMM_LEN )
__field( pid_t, pid )
__field( int, prio )
__field( int, success )
__field( int, target_cpu )
),
TP_fast_assign(
memcpy(__entry->comm, p->comm, TASK_COMM_LEN);
__entry->pid = p->pid;
__entry->prio = p->prio;
__entry->success = success;
__entry->target_cpu = task_cpu(p);
),
TP_printk("comm=%s pid=%d prio=%d success=%d target_cpu=%03d",
__entry->comm, __entry->pid, __entry->prio,
__entry->success, __entry->target_cpu)
);
DEFINE_EVENT(sched_wakeup_template, sched_wakeup,
TP_PROTO(struct rq *rq, struct task_struct *p, int success),
TP_ARGS(rq, p, success));
DEFINE_CLASS_EVENT(sched_switch,
TP_PROTO(struct rq *rq, struct task_struct *prev,
struct task_struct *next),
TP_ARGS(rq, prev, next),
TP_STRUCT__entry(
__array( char, prev_comm, TASK_COMM_LEN )
__field( pid_t, prev_pid )
__field( int, prev_prio )
__field( long, prev_state )
__array( char, next_comm, TASK_COMM_LEN )
__field( pid_t, next_pid )
__field( int, next_prio )
),
TP_fast_assign(
memcpy(__entry->next_comm, next->comm, TASK_COMM_LEN);
__entry->prev_pid = prev->pid;
__entry->prev_prio = prev->prio;
__entry->prev_state = prev->state;
memcpy(__entry->prev_comm, prev->comm, TASK_COMM_LEN);
__entry->next_pid = next->pid;
__entry->next_prio = next->prio;
),
TP_printk("prev_comm=%s prev_pid=%d prev_prio=%d prev_state=%s ==> next_comm=%s next_pid=%d next_prio=%d",
__entry->prev_comm, __entry->prev_pid, __entry->prev_prio,
__entry->prev_state ?
__print_flags(__entry->prev_state, "|",
{ 1, "S"} , { 2, "D" }, { 4, "T" }, { 8, "t" },
{ 16, "Z" }, { 32, "X" }, { 64, "x" },
{ 128, "W" }) : "R",
__entry->next_comm, __entry->next_pid, __entry->next_prio)
);
Anyone have any comments to whether or not the above is good or bad?
-- Steve
next prev parent reply other threads:[~2009-12-02 14:28 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-01 17:18 [PATCH v2] tracing: add " Jason Baron
2009-12-01 17:20 ` Randy Dunlap
2009-12-02 10:42 ` [tip:perf/core] tracing: Add " tip-bot for Jason Baron
2009-12-02 13:52 ` Steven Rostedt
2009-12-02 14:01 ` Ingo Molnar
2009-12-02 14:28 ` Steven Rostedt [this message]
2009-12-02 14:43 ` Ingo Molnar
2009-12-02 14:55 ` Steven Rostedt
2009-12-02 16:15 ` Randy Dunlap
2009-12-02 16:27 ` Mathieu Desnoyers
2009-12-02 17:11 ` Steven Rostedt
2009-12-02 18:06 ` Mathieu Desnoyers
2009-12-02 18:19 ` Steven Rostedt
2009-12-02 19:01 ` trace/events: DECLARE vs DEFINE semantic Mathieu Desnoyers
2009-12-02 19:19 ` Steven Rostedt
2009-12-02 19:34 ` Randy Dunlap
2009-12-02 22:36 ` Masami Hiramatsu
2009-12-02 22:46 ` Steven Rostedt
2009-12-02 22:57 ` Mathieu Desnoyers
2009-12-02 23:08 ` H. Peter Anvin
2009-12-02 23:13 ` Steven Rostedt
2009-12-02 23:18 ` H. Peter Anvin
2009-12-02 23:15 ` Mathieu Desnoyers
2009-12-03 3:24 ` Masami Hiramatsu
2009-12-02 23:10 ` Mathieu Desnoyers
2009-12-03 4:00 ` Masami Hiramatsu
2009-12-03 4:07 ` Steven Rostedt
2009-12-03 13:51 ` Masami Hiramatsu
2009-12-03 13:54 ` Steven Rostedt
2009-12-03 14:09 ` Mathieu Desnoyers
2009-12-03 14:24 ` Steven Rostedt
2009-12-03 14:42 ` Mathieu Desnoyers
2009-12-03 15:31 ` Masami Hiramatsu
2009-12-03 15:56 ` Steven Rostedt
2009-12-03 16:11 ` Masami Hiramatsu
2009-12-02 20:11 ` [PATCH][tip/perf/core] tracing: Rename TRACE_EVENT and others to something resonable Steven Rostedt
2009-12-02 20:16 ` Frederic Weisbecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1259764109.12870.37.camel@gandalf.stny.rr.com \
--to=rostedt@goodmis.org \
--cc=fweisbec@gmail.com \
--cc=hch@lst.de \
--cc=hpa@zytor.com \
--cc=jbaron@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=mhiramat@redhat.com \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=randy.dunlap@oracle.com \
--cc=tglx@linutronix.de \
--cc=wcohen@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®