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