Date: Fri, 18 Jul 2008 10:07:51 +0200
From: Ingo Molnar <mingo@elte.hu>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Roland McGrath <roland@redhat.com>,
       Linus Torvalds <torvalds@linux-foundation.org>,
       linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/23] tracehook
Message-ID: <20080718080751.GG6875@elte.hu>
References: <20080717072541.F390E15411D@magilla.localdomain> <20080717015105.f919f615.akpm@linux-foundation.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20080717015105.f919f615.akpm@linux-foundation.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2612
Lines: 61


* 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/