From: Andrew Morton <akpm@linux-foundation.org>
To: ananth@in.ibm.com
Cc: "Frank Ch. Eigler" <fche@redhat.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
linux-kernel@vger.kernel.org, Rostedt <rostedt@goodmis.org>,
Steven@e28smtp08.in.ibm.com, utrace-devel@redhat.com,
Linus Torvalds <torvalds@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Christoph Hellwig <hch@infradead.org>,
Jim Keniston <jkenisto@us.ibm.com>
Subject: Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
Date: Mon, 23 Mar 2009 22:54:09 -0700 [thread overview]
Message-ID: <20090323225409.07bdcbf7.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090324052926.GC24018@in.ibm.com>
On Tue, 24 Mar 2009 10:59:26 +0530 Ananth N Mavinakayanahalli <ananth@in.ibm.com> wrote:
> On Sat, Mar 21, 2009 at 05:04:22AM -0700, Andrew Morton wrote:
> > On Sat, 21 Mar 2009 07:51:41 -0400 "Frank Ch. Eigler" <fche@redhat.com> wrote:
> > > On Sat, Mar 21, 2009 at 04:19:54AM -0700, Andrew Morton wrote:
> >
> > I have strong memories of being traumatised by reading the uprobes code.
>
> That was a long time ago wasn't it? :-)
>
> That approach was a carry over from an implementation from dprobes that
> used readdir hooks. Yes, that was not the most elegant approach, as such
> has long been shelved.
>
> > What's the story on all of that nowadays?
>
> Utrace makes implementing uprobes more cleaner. We have a prototype that
> implements uprobes over utrace. Its per process, doesn't use any
> in-kernel hooks, etc. It currently has a kprobes like interface (needs a
> kernel module), but it shouldn't be difficult to adapt it to use
> utrace's user interfaces (syscalls?) when those come around. The current
> generation of uprobes that has all the bells and whistles can be found at
> http://sources.redhat.com/git/gitweb.cgi?p=systemtap.git;a=tree;f=runtime/uprobes2
>
> However, there are aspects of the current uprobes that can be useful to
> any other userspace tracer: instruction analysis, breakpoint insertion
> and removal, single-stepping support. With these layered on top of
> utrace, building userspace debug/trace tools that depend on utrace
> should be easier, outside of ptrace.
>
> Work is currently on to factor these layers out. The intention is to
> upstream all the bits required for userspace tracing once utrace gets
> in, along with an easy to use interface for userspace developers
> (a /proc or /debugfs interface?) -- one should be able to use it on
> its own or with SystemTap, whatever they prefer. Details are still hazy
> at the moment.
>
> But, utrace is the foundation to do all of that.
>
The sticking point was uprobes's modification of live pagecache. We said
"ick, COW the pages" and you said "too expensive". And there things
remained.
Is that all going to happen again?
next prev parent reply other threads:[~2009-03-24 6:06 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-21 1:39 [PATCH 0/3] utrace Roland McGrath
2009-03-21 1:41 ` [PATCH 1/3] signals: tracehook_notify_jctl change Roland McGrath
2009-03-21 1:41 ` [PATCH 2/3] utrace core Roland McGrath
2009-03-21 8:49 ` Andrew Morton
2009-03-21 14:08 ` Renzo Davoli
2009-03-21 14:34 ` Ingo Molnar
2009-03-21 16:37 ` Renzo Davoli
2009-03-21 16:44 ` Ingo Molnar
2009-03-23 4:34 ` Roland McGrath
2009-03-23 4:35 ` Roland McGrath
2009-03-23 10:57 ` Will Newton
2009-03-21 1:42 ` [PATCH 3/3] utrace-based ftrace "process" engine, v2 Roland McGrath
2009-03-21 7:43 ` Ingo Molnar
2009-03-21 8:39 ` Andrew Morton
2009-03-21 9:12 ` Ingo Molnar
2009-03-21 11:19 ` Andrew Morton
2009-03-21 11:51 ` Frank Ch. Eigler
2009-03-21 12:04 ` Andrew Morton
2009-03-21 12:57 ` Frank Ch. Eigler
2009-03-21 15:45 ` Ingo Molnar
2009-03-21 20:35 ` Diego Calleja
2009-03-22 12:17 ` Ingo Molnar
2009-03-21 21:34 ` Andrew Morton
2009-03-21 21:51 ` Frank Ch. Eigler
2009-03-21 22:02 ` Linus Torvalds
2009-03-21 22:20 ` Frank Ch. Eigler
2009-03-21 22:37 ` Alexey Dobriyan
2009-03-21 23:38 ` Frank Ch. Eigler
2009-03-22 10:25 ` Ingo Molnar
2009-03-23 5:33 ` Roland McGrath
2009-03-23 5:20 ` Roland McGrath
2009-03-22 12:37 ` Ingo Molnar
2009-03-23 13:48 ` Alexey Dobriyan
2009-03-23 15:14 ` Oleg Nesterov
2009-03-23 21:44 ` Theodore Tso
2009-03-30 22:18 ` Andrew Morton
2009-03-30 22:52 ` Frank Ch. Eigler
2009-03-31 9:17 ` Peter Zijlstra
2009-03-31 11:27 ` Peter Zijlstra
2009-03-31 11:38 ` Frank Ch. Eigler
2009-03-31 16:25 ` Christoph Hellwig
2009-03-31 20:54 ` Roland McGrath
2009-03-21 21:48 ` Frank Ch. Eigler
2009-03-22 12:08 ` Ingo Molnar
2009-03-22 12:53 ` Ingo Molnar
2009-03-23 20:25 ` Frank Ch. Eigler
2009-03-23 20:39 ` Linus Torvalds
2009-03-23 5:09 ` Roland McGrath
2009-03-24 5:29 ` Ananth N Mavinakayanahalli
2009-03-24 5:54 ` Andrew Morton [this message]
2009-03-24 6:10 ` Ananth N Mavinakayanahalli
2009-03-23 4:49 ` Roland McGrath
2009-03-23 6:34 ` Ingo Molnar
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=20090323225409.07bdcbf7.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=Steven@e28smtp08.in.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=ananth@in.ibm.com \
--cc=fche@redhat.com \
--cc=hch@infradead.org \
--cc=jkenisto@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=utrace-devel@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