This is the mail archive of the
mailing list for the systemtap project.
Re: [PATCH] Linux Kernel Markers
- From: Martin Bligh <mbligh at google dot com>
- To: Vara Prasad <prasadav at us dot ibm dot com>
- Cc: Ingo Molnar <mingo at elte dot hu>, Mathieu Desnoyers <mathieu dot desnoyers at polymtl dot ca>, "Frank Ch. Eigler" <fche at redhat dot com>, Paul Mundt <lethal at linux-sh dot org>, linux-kernel <linux-kernel at vger dot kernel dot org>, Jes Sorensen <jes at sgi dot com>, Andrew Morton <akpm at osdl dot org>, Tom Zanussi <zanussi at us dot ibm dot com>, Richard J Moore <richardj_moore at uk dot ibm dot com>, Michel Dagenais <michel dot dagenais at polymtl dot ca>, Christoph Hellwig <hch at infradead dot org>, Greg Kroah-Hartman <gregkh at suse dot de>, Thomas Gleixner <tglx at linutronix dot de>, William Cohen <wcohen at redhat dot com>, ltt-dev at shafik dot org, systemtap at sources dot redhat dot com, Alan Cox <alan at lxorguk dot ukuu dot org dot uk>
- Date: Tue, 19 Sep 2006 09:14:19 -0700
- Subject: Re: [PATCH] Linux Kernel Markers
- Domainkey-signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:user-agent: x-accept-language:mime-version:to:cc:subject:references:in-reply-to: content-type:content-transfer-encoding; b=c8guur0E/TlTatm5+/66176HmiArjh+6ru71VyCEmONgQavlodS/D6UHrB+3fFWRY vYiREvUNWb/0cEHbD3PfQ==
- References: <20060918234502.GA197@Krystal> <20060919081124.GA30394@elte.hu> <451008AC.firstname.lastname@example.org> <email@example.com>
It is an interesting idea but there appears to be following hard issues
(some of which you have already listed) i am not able to see how we can
1) We are going to have a duplicate of the whole function which means
any significant changes in the original function needs to be done on the
copy as well, you think maintainers would like this double work idea.
No, no ... the duplicate function isn't duplicated source code, only
object code. Either a config option via the markup macros that we've
been discussing, or something I hack up on the fly to debug a problem
dynamically. In terms of how the debugging-type source code is kept,
it's no different than something like systemtap or LTT (either would
work, and a normal diff could be used to keep out of tree stuff),
it's just how it hooks in is different to kprobes.
2) Inline functions is often the place where we need a fast path to
overcome the current kprobes overhead.
You can still instrument inline functions, you just need to hook all
the callers, not the inline itself.
3) As you said it is not trivial across all the platforms to do a switch
to the instrumented function from the original during the execution.
This problem is similar to the issue we are dealing with djprobes.
If we just freeze all kernel operations for a split second whilst we do
this, does it matter? Or even if we don't ... there's a brief race where
some calls are traced, and some are not ... does that even matter?
Doesn't seem like most usages would care.