Re: [RFC] systemtap: begin the process of using proper kernel APIs (part1: use kprobe symbol_name/offset instead of address)

[James Bottomley <James dot Bottomley at HansenPartnership dot com>]

On Tue, 2008-07-15 at 15:41 -0400, Frank Ch. Eigler wrote:
> James Bottomley <James.Bottomley@HansenPartnership.com> writes:
> 
> > One of the big nasties of systemtap is the way it tries to embed
> > virtually the entirety of the kernel symbol table in the probe
> > modules it constructs.
> 
> It is a compromise of conflicting requirements. 

Well ... in order to make forward progress, since the systemtap people
expressed a desire to be better integrated with the kernel, the first
order of business is to use the correct APIs ... that has to happen even
before an evaluation can be made of which pieces of the systemtap
runtime should move into the kernel.

> > This is highly undesirable because it represents a subversion of the
> > kernel API to gain access to unexported symbols.
> 
> Please elaborate.  Does the translator or its runtime use unexported
> symbols?  (That would arouse the question about why.)
> 
> Or are you talking about being able to *probe* unexported functions or
> access unexported data?  That would be a deliberate feature.

No ... I'm talking about _stp_module_relocate() at this point.  It's an
unnecessary function, since the kprobes API provides a way to attach to
a symbol and an offset.  The API allows access to unexported functions.

> > At least for kprobes, the correct way to do this is to specify the
> > probe point by symbol and offset.
> 
> But there won't be just kprobes.  Much of this code was built with
> anticipation of user-space probing, and there the kernel won't have a
> similar mechanism.  Similarly, the code is written to work with old
> kernels too - ones that predate the symbol+offset kprobe API.

OK ... you've got me there ... why would user space probing necessitate
resolution of kernel space symbols?  Surely you plan to use an exported
module API of utrace or whatever the agreed framework is?

> Unless someone is about to rip out pure address-based kprobes, I see
> no reason to complicate the code.

If you actually look, you'll see that pure addressed based kprobes still
work.

Also, I think you'll find it simplifies the code, since tons of the
runtime junk that duplicate the in-kernel symbol resolution can be
thrown out, plus the corresponding pieces of systemtap that have to
worry about this.

There's also the architectural worry:  this scheme you currently use is
very fragile.  For instance, I don't see it surviving a move to
-ffunction-sections (which patches are already going over linux-arch).

James