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.

same here.

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
> 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at