This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH tracing/kprobes 0/7] tracing/kprobes: kprobe-based event tracer update and perf support


Christoph Hellwig wrote:
On Fri, Sep 11, 2009 at 09:50:13PM +0200, Mark Wielaard wrote:
On Fri, 2009-09-11 at 15:06 -0400, Christoph Hellwig wrote:
On Fri, Sep 11, 2009 at 03:03:35PM -0400, Frank Ch. Eigler wrote:
Frederic Weisbecker<fweisbec@gmail.com> writes:

[...]  I'm really looking forward seeing this C expression-like
kprobe creation tool.  It seems powerful enough to replace printk +
kernel rebuild.  No need anymore to write some printk to debug,
worrying, [...]

To a large extent, systemtap had delivered this already some years ago, including the cushy ponies dancing in the sunlight. While such low-level machinery is fine, some of our experience indicates that it is dramatically easier to use if high-level, symbolic, debugging data is used to compute probe locations and variable names/types/locations.

No, systemtap has been for years failing to delivers this in a way that it could be usefully integrated into the kernel.

You are saying "No" to a claim Frank didn't even make.

He said systemtap had delivered it, which is not the case. It has implemented it, but not actually delivered it in a useful way.

I assume that he has meant that systemtap had delivered to end-users, and that is certainly true. Systemtap has been released and distributed with many distributions. I know there are many systemtap users nowadays.

However, indeed, that was not so useful way especially for kernel developers.
Systemtap developers have also recognized this problem, and we are trying
to fix it for good relationship with upstream kernel.

I'd like to make my work useful not only for upstream kernel and ftrace,
but also for systemtap. Through this enhancement, knowledge and
experiences of systemtap will be transferred to upstream. I think
systemtap can also use it by re-implementing on in-kernel tracing
functions. I believe we can collaborate on this work, at least
on stabilizing tracing functions.


Thank you,


--
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division

e-mail: mhiramat@redhat.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]