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

["Frank Ch. Eigler" <fche@redhat.com>]

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