Hi - On Wed, Oct 31, 2007 at 12:36:24PM -0400, Mathieu Desnoyers wrote:
> [...] That's right, Systemtap uses symbols, thanks for the > clarification. But my point is still valid: SystemTAP expects > function names and argument names to stay unchanged, therefore using > the kernel code itself as an API to userspace tools. [...] To be precise, this applies *kprobes*-based probes only. In acceptance of this fragility, systemtap includes constructs (aliases, version-dependent conditionals) to make it reasonably easy to adapt to different kernel versions. > I think that SystemTAP's [kprobes-based probes'] flexibility is > great, but leads to fagileness wrt kernel code changes. If the "core > events" required by SystemTAP (and also by LTTng by the way) could > be turned into markers, I think it would gain in robustness. Yes. > Providing the ability to instrument code locations with breakpoints, in > addition to this, will help users unsatisfied with the information > they have, unwilling to recompile their kernel or modules with their > own markers, ready to accept the two limitations : > - performance hit of a breakpoint > - unability to access variables within optimized functions That latter point has been repeatedly overstated. Markers provides a fixed set of values. kprobes/dwarf provides access to any statements and any values (including locals) that a compiler did not altogether elide. While the latter set is by its nature variable, it will be much bigger than anything a reasonable set of markers will ever expose. > So yes, both approaches seems to be complementary. Indeed. > > > About extending on ptrace, I am sorry to say that this solution has > > > the same downsides as kprobes: it is too slow for high performance > > > applications, especially if turned on system-wide. [...] > > > > Roland McGrath's ptrace-replacement (utrace) should help with this. > > Yes, I think he did a good job at it. However, it is not a replacement > for the markers [...] Right, not as a whole, but it *could* be an alternative way to hook into system call type events. > [...] > So I would say : I'll try to submit a core set of markers patches for > review on LKML and see what people have to say. Thank you. Our team is already in contact to help. - FChE - 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/
