This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: precompiled probing scenarios
- From: "Frank Ch. Eigler" <fche at elastic dot org>
- To: David Smith <dsmith at redhat dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: Fri, 6 Oct 2006 16:40:01 -0400
- Subject: Re: precompiled probing scenarios
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=elastic.org; b=IkKKGNAMpggvyPME8IFC31sF5/X1alFp9dICDM2Hzs6tKT1GNTaDOZYu+ZrPLswSy5gHHwfyzl7MCCkL3HZpiD66Q/u1T1M6ysuhpV0FfgDoypX/SmPfTqudBSYWdAXw;
- References: <20061006190806.GA30553@elastic.org> <4526BD8F.3060002@redhat.com>
Hi -
On Fri, Oct 06, 2006 at 03:33:19PM -0500, David Smith wrote:
> [...]
> Hmm. Are we hashing the input script? If so, how does this work with
> probe wildcards? For example, let's say I probe "kernel.function("*")".
> We compile and cache this module. I then plug in a bunch of
> additional hardware, which causes several extra modules to be loaded. I
> then run stap again with the exact same input script. [...]
kernel.function("*") should match exactly what was there before.
Probes on module("*").FOO would be redefined to mean something like
"all modules that we know at translation time that *might* exist, that
also happen to be *loaded* at run time. This aspect of wildcard
expansion would thus take place at run time rather than translate
time. It just so happens that the same module might probe a greater
or lesser number of modules on an actual system. With that proviso,
a script-source-level hash still seems to work.
> Wow. Supporting different kernel versions on the same arch/cpu is
> currently supported. Doing different arch/cpu types is going to be
> difficult. [...]
Yeah, I figure proper cross-architecture compilation would come later.
> [...] Hmm. Is this new staprun.auth variant a setuid program or
> does the user still need sudo privileges?
It could be setuid.
- FChE