public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: "Frank Ch. Eigler" <fche@redhat.com>
To: Vara Prasad <prasadav@us.ibm.com>
Cc: systemtap@sources.redhat.com
Subject: Re: user-space probes -- plan B from outer space
Date: Wed, 14 Jun 2006 23:46:00 -0000	[thread overview]
Message-ID: <20060614234643.GG30867@redhat.com> (raw)
In-Reply-To: <449090B5.5080007@us.ibm.com>

Hi -

varap wrote:
> [...]
> >A fixed pool of predefined handlers seem like an antithesis of
> >systemtap.  Did you have some user interface in mind for these?
>
> Like i mentioned in response to Prasanna's user space probes approach  
> mail there will be two types of handlers for user space probes [...]

I understand that this is what you're proposing.

> SystemTap will use the second approach.

OK, so no user interface required for the first.  But of course if
you're building the first approach also, you must have some tool in
mind to at least demonstrate it.


> [...] you could use the preexisting handlers and don't need to write
> kernel module and possibly don't even need root permission to trace.
> [...]

With some cleverness, we can keep separated the issues of these
predefined handlers (and the hypothetical non-systemtap tool that
might use them) and unprivileged probing.


> >>[...] I am not sure i see the value of process("process name")
> >>syntax if our focus is process specific tracing.
>
> >It would be one way of identifying present or future processes to
> >probe.  For processes that do not yet exist, what other scheme do you
> >have in mind?
>
> The scheme i am thinking is you could start a new process [...]

But you were concerned about the process("name") *syntax*.  Sure,
implementing any of these various probes may involve forked observer
processes.  But if you don't have that *syntax*, how else do you want
a script to target a particular process (other than by pid)?


> >>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.
> >>[...]
> >
> >How would this gdb batch job alternative work?  Are you intending to
> >compare the expressity of systemtap script with gdb macros?
> 
> I am not saying gdb macros are as powerful as systemtap scripts. All i 
> meant is one can use gdb batch scripts to print the variables you need 
> and use all kinds of post processing using your favorite scripting 
> language. As the handlers are run in the userspace i am not seeing much 
> advantage of using systemtap language to do filtering in the userspace 
> vs post processing using your favorite scripting language.

It has the same kind of advantage in user space as it does in kernel
space: the option of safely and compactly
filtering/analyzing/acting-on data in situ rather than archiving
masses of trace data and passively analyzing it after the fact.

- FChE

  reply	other threads:[~2006-06-14 23:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-06 19:08 Frank Ch. Eigler
2006-06-06 21:50 ` Jim Keniston
2006-06-07 19:59   ` Frank Ch. Eigler
2006-06-09 11:57     ` Jim Keniston
2006-06-09 18:42       ` Frank Ch. Eigler
2006-06-07  1:38 ` Vara Prasad
2006-06-14 19:11   ` Frank Ch. Eigler
2006-06-14 22:42     ` Vara Prasad
2006-06-14 23:46       ` Frank Ch. Eigler [this message]
2006-06-15  1:02         ` Vara Prasad
2006-06-19 17:13           ` Frank Ch. Eigler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060614234643.GG30867@redhat.com \
    --to=fche@redhat.com \
    --cc=prasadav@us.ibm.com \
    --cc=systemtap@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).