Re: user-space probes -- plan B from outer space

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

Hi -

varap wrote:

> [...]  I don't have any specific tool in mind but giving this
> [predefined ptrace handler] interface satisfies the need for those
> who wants to write their own programs to trace user space without
> needing to use systemtap. I am not sure in reality how many people
> will do that but comments seem to ask for such an interface.

It seems to me that without a specific prototype, you will not know
whether the choice of predefined handlers are actually useful.


> [...]
> On the topic of the root problem, if i understand correctly the main 
> reason we need root to use systemtap now is we need to load a module. 
> One way to solve that is use pre-compiled modules but we have to deal 
> with how we can parameterize them for the specific needs of a script. 

We already have some support for run-time parametrization (setting of
systemtap globals).

> Another way [...]

Yes, possibly, but there are yet other different approaches.  Once we
have workable user-space probing, it will be time to deal with probing
by unprivileged users.


> [...]
> >But you were concerned about the process("name") *syntax*.  [...]
>
> In the scheme i mentioned the syntax i was thinking is a command line 
> option some thing like below
> stap -e <myexecutable name>

I assume you mean "stap -c CMD" or "stap -x PID".  That's fine for
probing a single process, but it may be desirable and not too difficult
to let a script refer to a whole family of processes at once:
- everyone who runs vi
- every future descendant of a given process that has a given name pattern 
- several running processes with different pids

So, like kernel.function("*"), one might think of the user-space probe
point specifiers as possible filters that tell systemtap to focus on
some *subset* of the complete list of present/future processes/threads.


> >>>>I am not sure i see lot of value of this solution compared to a gdb
> >>>>batch job, but for bit better performance than the heavy weight gdb.
> >>>>[...]
>
> No disagreements in use of systemtap language in kernel and doing it
> in situ. In the userspace however one can pipe the output to the
> post processing process without needing to write to disk.

I see no difference between kernel & user space probing in this
regard.  Neither requires copying to disk in principle: in both cases
it should be possible to both filter data in situ and later via a
buffered trace data stream.


- FChE