Re: [RFC] Create kinst/ or ki/ directory ?

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/