Messages in this thread | | | Date | Mon, 8 Jun 2009 23:25:26 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH 2/2] convert to syscall tracepoints |
| |
* Jason Baron <jbaron@redhat.com> wrote:
> 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? [...]
Because the current solution is butt-ugly ...
> [...] I think its unnecessary work that could be error prone.
This area needs cleanups - making it messier doesnt help. (I've Cc:-ed hpa - he has expressed interest in auto-generating all the syscall related details from another angle ...)
> > 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.
yes, and that's good.
> 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? [...]
And that's bad.
We dont want a per syscall tracepoint call site. AT ALL.
We want to collect the record information, we want to construct /debug/tracing/events/syscalls/ directories with all the proper tracepoint-lookalike entries, and then we want to use the _existing_, _zero overhead_ method implemented by Frederic to get per syscall functionality.
Have you looked at how the syscall attributes information is constructed by using .section tricks? See: kernel/trace/trace_syscalls.c.
Ingo
| |