Re: [PATCH 0/13] maps: pagemap, kpagemap, and related cleanups

[Christoph Hellwig <hch@infradead.org>]

On Fri, Apr 13, 2007 at 05:17:00PM -0400, Frank Ch. Eigler wrote:
> It may be worthwhile to remind people that it is easy to use systemtap
> only to the extent of automating the placement of kprobes: just to
> perform the function-name/source-file/line-number triplet to PC
> mapping.  They can use embedded-C code to do all the same stuff they'd
> do with kprobes.  They are not obligated to write any odd script code
> for probing logic, nor indeed use any of this really wrong runtime.

Umm, yes- as long as you write systemtap the runtime gets linked in
currently.  That doesn't mean you actually use a lot of it in the end,
but the maintaince horror of actually getting all the junk code to
compile still is there.

Now the actual function-name/source-file/line-number triplet to PC is
really useful functionality, and for my tracing work I could really
use this a lot.  Unfortunately systemtap doesn't have a proper layered
approach and you can't use this bit without pulling in all the
junk.  If started some dward based function-name/source-file/line-number
of my own based on acme's work, but it's stalled due to more important
issues going on.

> > We could not really distribute systemtap scripts with the kernel.
> > systemtap is a bloody complicated piece of [software] 
> 
> I don't know if that should be treated a compliment to our team, for
> being able to work quickly on something that a full-grown kernel
> developer finds bloody complicated.  Perhaps your information is
> simply outdated.  Big & bloated?  We have several times asked for
> specifics rather than smears - what about it?

There's a lot of stuff unneeded for basic tasks.  But if you want
a detailed review you could submit your runtime bits for review and
get feedback from everyone.

> > outside the kernel tree that breaks all the time we change kernel
> > internals. [...]
> 
> That's begging the question.  If kernel folks are willing to maintain
> some included systemtap-related code, then by definition it would not
> break all the time.

We'll definitly need a trace transport.  I currently use a hackish
kfifo rinbuffer derived from net/ipv4/tcp_probe.c, but it's showing
it's limitations.  Tom promised long ago to factor our the trace
code from blktrace into generic bits, but as he doesn't deliver
I suspect I'll have to do that myself soon.

The safe dereference bits are a bit questionable, but at least worth
a try to put into the tree proper, because there's no chance they'd
be properly maintained outside.

The register dumps you do would could definitly stand some integration
with the register dumps in panic messages, and would be useful library
functions for proper C language kprobes, but that means detangling
the core from the utterly horrible systemtrap pascal string handling.

Stack backtrace handling could use some integration with the stack
tracing framework in for lockdep and fault injection and be available
more genericly for C kprobes.

With a proper tracing infrastructure we'll need the timing bits for
it aswell, which should superceed the utter mess in systemtap in
that area (I'm hoping for Matthew to come up with something there
as part of lttng)