public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@elte.hu>,
	Jason Baron <jbaron@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] trace_syscalls: add missed field
Date: Fri, 27 Nov 2009 05:15:41 +0100	[thread overview]
Message-ID: <20091127041540.GA5221@nowhere> (raw)
In-Reply-To: <4B0F4F63.6040307@cn.fujitsu.com>

On Fri, Nov 27, 2009 at 12:02:43PM +0800, Lai Jiangshan wrote:
> Frederic Weisbecker wrote:
> > On Thu, Nov 26, 2009 at 03:49:33PM +0800, Lai Jiangshan wrote:
> >> Field syscall number is missed in syscall_enter_define_fields()/
> >> syscall_exit_define_fields().
> >>
> >> syscall number is also needed for event filter or other users.
> >>
> >> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
> > 
> > 
> 
> 
> For all kinds of tracer, all fields are "defined"
> by trace_define_field(), except this one.
> Maybe because I don't like inconsistent codes.


:)


> > 
> > Well, I don't think it's very useful for in-kernel filtering.
> > Filtering a syscall event by its number would mean filtering all
> > event for this syscall. This is the same as not tracing it.
> > 
> > Or do you have other usecases in mind?
> > 
> 
> Current, only filter use struct ftrace_event_call->fields,
> so there is no other usecases ^_^.
> But my next take of "tracing: use defined fields to print formats"
> will use it.


Oh really you are planning such patch? That looks hard to do
considering the tricky things that happen in fields printing
sometimes. Also printing the fields is often a human
interpretation on how to handle them, so... Anyway, I'll just
wait for your patches and see.

That said I really have no opposition against this patch.
For consistency over what is done with every other trace event
fields, and to anticipate any further uses of trace event fields
definition other than filtering:

Acked-by: Frederic Weisbecker <fweisbec@gmail.com>

(Steve, Ingo, should I queue it or...what do you prefer?)


  reply	other threads:[~2009-11-27  4:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-26  7:49 [PATCH] trace_syscalls: add missed field Lai Jiangshan
2009-11-26 22:31 ` Frederic Weisbecker
2009-11-27  4:02   ` Lai Jiangshan
2009-11-27  4:15     ` Frederic Weisbecker [this message]
2009-11-27  5:49 ` [tip:perf/core] trace_syscalls: Add syscall nr field tip-bot for Lai Jiangshan

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=20091127041540.GA5221@nowhere \
    --to=fweisbec@gmail.com \
    --cc=jbaron@redhat.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    /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