Messages in this thread | | | Date | Mon, 24 Aug 2009 22:12:12 +0200 | From | Frederic Weisbecker <> | Subject | Re: [PATCH v3 2/4] tracing: Make syscall_(un)regfunc arch-specific |
| |
On Mon, Aug 24, 2009 at 01:00:23PM -0700, Josh Stone wrote: > On 08/24/2009 12:58 PM, Frederic Weisbecker wrote: > > On Mon, Aug 24, 2009 at 12:31:26PM -0700, Josh Stone wrote: > >> On 08/23/2009 02:14 PM, Frederic Weisbecker wrote: > >>> I really don't like that. > >>> See how the s390 and x86 version of the above code are completely > >>> identical? > >>> > >>> Please put this in kernel/ptrace.c > >> > >> Yes, I see your point, and I think kernel/ptrace.c is a fine place for > >> it. Making it conditional on CONFIG_TRACEPOINTS and > >> CONFIG_HAVE_FTRACE_SYSCALLS is probably best too, though I think the > >> latter should now be HAVE_SYSCALL_TRACEPOINTS. > > > > > > As you prefer, this new name can be indeed more verbose. > > Actually, now I'm second-guessing the need to move these at all. Since > they only make sense for CONFIG_TRACEPOINTS, can't they stay in > kernel/tracepoint.c and just be conditional on HAVE_SYSCALL_TRACEPOINTS? > The only real change needed is for the tracepoint declarations to also > be conditional. > > Josh >
Both ways make sense to me, although I generally see the role of kernel/tracepoint.c to only host the general core tracepoints mechanism.
And here these two callbacks are more about specific tracepoints coverage, somewhat tied to the ptrace background because we are using a ptrace bridge to reach these tracepoints.
Well, either ways look good:
- tracepoint.c: to solve the lack of a functionnality in very specific cases.
- ptrace.c: because it's part of a ptrace mechanism.
I don't feel strongly about that :-)
| |