Messages in this thread |  | | | Date | Fri, 18 Jul 2008 10:07:51 +0200 | | From | Ingo Molnar <> | | Subject | Re: [PATCH 00/23] tracehook |
| |
* Andrew Morton <akpm@linux-foundation.org> wrote:
> On Thu, 17 Jul 2008 00:25:41 -0700 (PDT) Roland McGrath <roland@redhat.com> wrote: > > > This patch series introduces the "tracehook" interface layer of > > inlines in <linux/tracehook.h>. > > Looks sane to me from a quick scan.
same here.
Reviewed-by: Ingo Molnar <mingo@elte.hu>
> A ~200 byte increase in i386 allnoconfig .text is liveable with. But > nothing defines CONFIG_HAVE_ARCH_TRACEHOOK yet. What effect will that > have?
this is the second subtle step towards utrace and next-gen-instrumentation. (regset was the first, by far most risky step)
> I don't like the name! We have ftrace and we have static tracepoints > and we have dynamic tracepoints and we have linux trace toolkit and > whatever is in kernel/trace/trace.c etc, etc. Now this work comes > along with _userspace_ tracing capabilities and it goes and calls it, > of all things, "trace"!
> Apart from that, I think the other big issue with this patchset is > that it doesn't do anything yet. It's effectively a blank cheque. > There's not a lot of point in merging all this work unless we also > merge something which uses it (is this correct?). And afacit the > thing which will use it is utrace and utrace hasn't been sighted for a > year or more and it has met objections. > > If we merge this and then utrace crashes on a rocky shore then there > was no (or little) point in having merged this. > > Or am I wrong about that? Does it have sufficient standalone value to > justify a standalone merge (yet alone to justify such a late merge)?
It has enough standalone value to me - it generally cleans up all things "abstract kernel events", collects them into a single entity and lets tracers interact with the kernel (not just passively observe its events). So it's good for next-gen debuggers too, etc.
And task_current_syscall() avoids us hundreds of crappy hooks in every syscall handler and gives us in-kernel strace in essence. (it's not just useful to sample blocked threads - it could also be used by ftrace&co to sample the currently executing task) That alone makes it worth it IMO ;-)
also in places it cleans up current special-case-for-ptrace code and makes it shorter - like in kernel/exit.c. Well thought out scheme and structure - as we've come to expect from Roland.
Ingo
|  |