This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [RFC] systemtap: begin the process of using proper kernel APIs (part1: use kprobe symbol_name/offset instead of address)
Hi -
On Tue, Jul 15, 2008 at 09:06:23PM -0500, James Bottomley wrote:
> [...]
> > Please choose your words more carefully. We don't "subvert" anything,
> > where one would mean sneaking around some sort of protection.
>
> Actually, I did and you do. One of the OED's definition of subvert is
> "to undermine or overturn a condition or order of things, a principle or
> a law etc." In this particular case, this:
>
> commit 3a872d89baae821a0f6e2c1055d4b47650661137
> Author: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
> Date: Mon Oct 2 02:17:30 2006 -0700
> [PATCH] Kprobes: Make kprobe modules more portable
>
> Which provided a portable input to kprobes (the symbol_name/offset one)
> and revoked the global accessibility of the kallsyms_lookup_name().
That patch served two purposes: a helpful utility for other kprobes
users, and it enabling what LKML deemed more important - unexporting
kallsyms*.
> It's actually worse than this, though. The kernel API isn't fixed in
> stone, it evolves usually by trying to make problematic use cases
> better. By refusing to consider using the replacement API [...]
Your lecture is based upon a misundertanding ...
> [...]
> It emits a single probe and produces this in the module build:
> -rw-r--r-- 1 root root 17996 2008-07-15 20:45 stap_2154.c
> About 600 lines.
> However, it also needs this for the symbol table:
> -rw-r--r-- 1 root root 446137 2008-07-15 20:45 stap-symbols.h
... that this is somehow connected to the kprobe api issue.
IT IS NOT.
We do not use those symbol tables for kprobe placement purposes.
(This part is partially a prototype for user-space parts, and the
sizes will not stay large.)
The way we set up kprobes now could be trivially converted to
"_stext"+offset. Would that alone allay your concerns?
- FChE