From: Jason Baron <jbaron@redhat.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org, fweisbec@gmail.com,
laijs@cn.fujitsu.com, rostedt@goodmis.org, peterz@infradead.org,
mathieu.desnoyers@polymtl.ca, jiayingz@google.com,
mbligh@google.com, roland@redhat.com, fche@redhat.com
Subject: Re: [PATCH 2/2] convert to syscall tracepoints
Date: Mon, 8 Jun 2009 17:11:50 -0400 [thread overview]
Message-ID: <20090608211150.GC3181@redhat.com> (raw)
In-Reply-To: <20090608204056.GA26832@elte.hu>
On Mon, Jun 08, 2009 at 10:40:56PM +0200, Ingo Molnar wrote:
> * Jason Baron <jbaron@redhat.com> wrote:
>
> > +#ifdef __NR_time
> > +trace_event_syscall(1, time, time_t __user *, tloc);
> > +#endif
> > +
> > +#ifdef __NR_stime
> > +trace_event_syscall(1, stime, time_t __user *, tptr);
> > +#endif
> > +
> > +#ifdef __NR_gettimeofday
> > +trace_event_syscall(2, gettimeofday, struct timeval __user *, tv, struct timezone __user *, tz);
> > +#endif
>
> This could be reduced to a single line: just add a Kconfig entry
> (say TRACE_SYSCALL_TRACEPOINTS) wether an arch supports syscall
> tracepoints, enable it on a sane arch, make sure it has all the
> syscalls and list them ...
>
> As more architectures turn on SYSCALL_TRACEPOINTS, they'll have to
> resolve any deviations in syscall entry points. Ideally we'd have
> one generic table that covers 95% of all syscalls, and the remaining
> 5% in some architecture specific #ifdef section.
>
true, but this implementation works for all arches now, why would want to
slowly add this over time? I think its unnecessary work that could be
error prone.
> But, more generally, i'm not at all convinced that we need _any_ of
> this enumeration. Look how much the above lines duplicate
> DEFINE_SYSCALL macros. Why arent those macros re-used?
>
The DEFINE_SYSCALL() are located all over the code in various .c files.
Thus, if we define the tracpoints via the DEFINE_SYSCALL() macros we are
going to have 'static inline functions' (which is how tracepoints are
implemented) defined in all these .c files. Now, I need to call all these
'static inline functions' from ptrace.c. How do I do that? By defining
these as I've done in syscalls.h I can include that header file and
create an efficient 'case' statement. I've verified in the assembly that
the 'case' statments resolve to jumps. Thus, this implementation is
pretty efficient. Further, by creating a header file other users of the
tracepoints can include that header. If we use DEFINE_SYSCALL() that is
not possible. I'd be more than happy to use the DEFINE_SYSCALL() macros,
if you could explain how to resolve the above issues...We could write a
pre-processor that creates a dynamic header file from the
DEFINE_SYSCALL() points? I'm not sure that's simpler...
> We dont need too smart pretty-printing i think - we only want to
> know the field size and the field name - nothing else. Duplicating
> all those definitions looks outright wrong to me. Do we really,
> really, really have to do it?
>
In terms of pretty-printing, it should be fairly easy to add size and
the field name to what I have without bloating the syscalls.h file at
all.
thanks,
-Jason
next prev parent reply other threads:[~2009-06-08 21:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-05 18:07 [PATCH 0/2] convert ftrace syscalls to TRACE_EVENT Jason Baron
2009-06-05 18:08 ` [PATCH 1/2] allow TP_printk() to have no args Jason Baron
2009-06-05 18:08 ` [PATCH 2/2] convert to syscall tracepoints Jason Baron
2009-06-07 13:29 ` Ingo Molnar
2009-06-08 20:24 ` Jason Baron
2009-06-08 20:40 ` Ingo Molnar
2009-06-08 21:11 ` Jason Baron [this message]
2009-06-08 21:25 ` Ingo Molnar
2009-06-08 21:38 ` Jason Baron
2009-06-08 22:00 ` Ingo Molnar
2009-06-08 23:02 ` Frederic Weisbecker
2009-06-09 14:13 ` Jason Baron
2009-06-09 18:53 ` Frederic Weisbecker
2009-06-09 19:17 ` Jason Baron
2009-06-07 19:19 ` 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=20090608211150.GC3181@redhat.com \
--to=jbaron@redhat.com \
--cc=fche@redhat.com \
--cc=fweisbec@gmail.com \
--cc=jiayingz@google.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=mbligh@google.com \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=roland@redhat.com \
--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