Re: [PATCH 00/23] tracehook
From: Ingo Molnar
Date: Fri Jul 18 2008 - 04:08:24 EST
* Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Thu, 17 Jul 2008 00:25:41 -0700 (PDT) Roland McGrath <roland@xxxxxxxxxx> wrote:
> > This patch series introduces the "tracehook" interface layer of
> > inlines in <linux/tracehook.h>.
> Looks sane to me from a quick scan.
Reviewed-by: Ingo Molnar <mingo@xxxxxxx>
> A ~200 byte increase in i386 allnoconfig .text is liveable with. But
> nothing defines CONFIG_HAVE_ARCH_TRACEHOOK yet. What effect will that
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/