All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Frank Ch. Eigler" <fche@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>, Roland McGrath <roland@redhat.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	utrace-devel@redhat.com, linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
Date: Sat, 21 Mar 2009 08:57:06 -0400	[thread overview]
Message-ID: <20090321125706.GB3566@redhat.com> (raw)
In-Reply-To: <20090321050422.d1d99eec.akpm@linux-foundation.org>

Hi -

On Sat, Mar 21, 2009 at 05:04:22AM -0700, Andrew Morton wrote:
> [...]
> > There have been many mixed messages from LKML on the topic - sometimes
> > mentioning systemtap is forbidden, other times necessary.  Sorry about
> > that.
> 
> heh.  We all love systemtap and want it to get better.

Great!


> [...]
> I have strong memories of being traumatised by reading the uprobes
> code.  What's the story on all of that nowadays?

uprobes, being a layer upon utrace that provides a kprobes-like
breakpointing API for user threads, is being refactored into several
parts.  I don't know about the aesthetics of it all, but I believe the
general future plan is this:

One piece would perform machine code analysis (to classify
instructions for ideal/safe placement of breakpoints or for code
patching), and another thin layer that uses this and utrace to manage
user-space breakpoints.  (Systemtap would interface at this point.)
Then a user-space syscallish interface could come along to expose this
to a super-ptrace client (to speed up gdb; perhaps to allow multiple
debuggers).  Plus one might as well add an ftrace-engine for it
(directly analogous to the recent kprobe-based one that ftrace people
found "cool".)


> > > Actually it seems that the whole utrace-ftrace thing is a big
> > > distraction and could/should just be omitted.  This is a systemtap
> > > feature and should be viewed as such. [...]
> > 
> > utrace is a better way to perform user thread management than what is
> > there now, and the utrace-ftrace widget shows how to *hook* thread
> > events such as syscalls in a lighter weight / more managed way than
> > the first one proposed.  (That's one reason we've been participating
> > in the ftrace discussions.)  Of course it can be made to use the fine
> > syscall pretty-printing code recently added.
> 
> eh.  Boring.  Let's fix systemtap?

There are several constituencies here, some of which find the above
exciting.  That's OK and we'd like to help them too.


- FChE

  reply	other threads:[~2009-03-21 12:58 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 [this message]
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
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=20090321125706.GB3566@redhat.com \
    --to=fche@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=roland@redhat.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.