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

[Masami Hiramatsu]

Frank Ch. Eigler wrote:
> Hi -
> 
> 
> On Thu, Jul 17, 2008 at 04:06:09PM -0500, James Bottomley wrote:
> 
>> [...]
>>> My point is that the proposed effort to identify a nearby function
>>> symbol to use as a base for each probe's symbol+offset calculation is
>>> wasted.
>> It's not exactly wasted ... the calculations have to be done anyway for
>> modules.
> 
> Not really - we just anchor off a different (per-module) reference
> symbol or address.  At the moment, we use the .text* section bases.
> 
> 
>>>> you've lost access to the symbols in the sections that start before _stext.  
>>> What's between _text and _stext appears to consist of kernel boot-time
>>> functions that are unmapped the time anything like systemtap could
>>> run.
>> Well, no, they're the head code.  It's actually used in CPU boot and
>> tear down, one of the things it's useful to probe, I think.
> 
> Fair enough - conceivably probing that stuff is useful, as is module
> initialization.  We don't try to do it yet (and indeed kprobes blocks
> it all).
> 
> In any case, the method of probe address calculation doesn't affect
> that issue.  We can calculate .init* addresses relative to any
> convenient reference in exactly the same way as non-.init addresses.
> 
> 
>>>> Assuming you meant _text (which is dangerous because it's a define
>>>> in the kernel linker script and could change).
>>> By "dangerous" do you only mean that it may require a one-liner
>>> catch-up patch in systemtap if the kernel linker scripts change?
>> Dangerous as in it's not necessarily part of the kernel linker scripts.
>> [...]
>> The point, really, is to remove some of the fragile dependencies between
>> systemtap and the kernel.
> 
> Yes, that is generally desirable - each case is usually a question of
> cost/benefit.  One significant requirement for us is to keep working
> with older kernels.

Hi Frank,

I know we'd better archive that requirement. However, if we lose support
from developers because we are too much focusing on that, we'll also
lose the future of systemtap itself. We have to see the cost/benefit
from the long-term of view.

Could we separate systemtap parser/elaborator and code generator
to support both of old and new kernels?

Thank you,

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@xxxxxxxxxx

--
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/