From: Richard J Moore <richardj_moore@uk.ibm.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: Hien Q Nguyen <nguyhien@us.ibm.com>, systemtap@sources.redhat.com
Subject: Re: [...] kprobes [minutes] portion 20060406
Date: Thu, 06 Apr 2006 22:08:00 -0000 [thread overview]
Message-ID: <OFD12436D6.4D754ECC-ON41257148.007888DD-41257148.0079967E@uk.ibm.com> (raw)
In-Reply-To: <20060406212838.GB22703@redhat.com>
Unfortunately I missed the discussion. Am I right in deducing that
user-space probes as being discussed here are designed or intended as
probes for use with an application's perspective? If so, I believe that is
wrong or at least only attending to part of the need. For me the real
benefit of user-space probes is to provide an extension to a kernel probe
that gives it full access to the system. The arguments on lkml put forward
by Christoph and Arjan have value when one thinks of a user-probe only
serving user-space code and a user-space problem. But we have tools
already in place to deal with that. Have we fully appreciated the need
when addressing certain system or kernel problems that one needs access to
full system resources, which will include user-space code and data. Anyone
who works on performance problems (hangs being an extreme example)
involving the networking stack will corroborate this need. An more
generally anyone that works with a kernel-based server component of a
client-server model will also corroborate this need.
Richard
- -
Richard J Moore
IBM Advanced Linux Response Team - Linux Technology Centre
MOBEX: 264807; Mobile (+44) (0)7739-875237
Office: (+44) (0)1962-817072
"Frank Ch.
Eigler"
<fche@redhat.co To
m> Hien Q Nguyen <nguyhien@us.ibm.com>
Sent by: cc
systemtap-owner systemtap@sources.redhat.com
@sourceware.org bcc
Subject
06/04/2006 Re: [...] kprobes [minutes] portion
22:28 20060406
Hi -
On Thu, Apr 06, 2006 at 02:14:46PM -0700, Hien Q Nguyen wrote:
> User space probe
> Prasanna had prototype that execute the handler in the user space [...]
Beyond merely dispatching, it is important to consider what such a
handler can do. Would it still be useful if it cannot call into the
kernel-side runtime, if it cannot share variables with kernel-space
probes?
- FChE
next prev parent reply other threads:[~2006-04-06 22:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <OF450EB249.F3B0B23E-ON88257148.00738621-88257148.0074730E@us.ibm.com>
2006-04-06 21:28 ` Frank Ch. Eigler
2006-04-06 22:08 ` Richard J Moore [this message]
2006-04-07 8:25 ` Prasanna S Panchamukhi
2006-04-07 8:43 ` Richard J Moore
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=OFD12436D6.4D754ECC-ON41257148.007888DD-41257148.0079967E@uk.ibm.com \
--to=richardj_moore@uk.ibm.com \
--cc=fche@redhat.com \
--cc=nguyhien@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).