From: Andrew Morton <akpm@linux-foundation.org>
To: "Frank Ch. Eigler" <fche@redhat.com>
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 05:04:22 -0700 [thread overview]
Message-ID: <20090321050422.d1d99eec.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090321115141.GA3566@redhat.com>
On Sat, 21 Mar 2009 07:51:41 -0400 "Frank Ch. Eigler" <fche@redhat.com> wrote:
> Hi -
>
> On Sat, Mar 21, 2009 at 04:19:54AM -0700, Andrew Morton wrote:
> > [...]
> > > Utrace is very much tracing material - without the ftrace plugin the
> > > whole utrace machinery is just something that provides a _ton_ of
> > > hooks to something entirely external: SystemTap mainly.
> >
> > Roland's changelogs don't mention systemtap at all afacit.
> > That was, umm, major information lossage.
>
> 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.
> There are several non-systemtap clients in existence or under
> development. You've may have heard of the ptrace cleanup, a
> multi-client ptrace replacement, an on-the-fly core dumper, the ftrace
> widget, user-space probes. All of these should have somewhat
> compelling non-systemtap uses, if that's an important criterion.
Well I dunno. You guys are closer to this than I am, but I'd have thought
that systemtap is the main game here, and most/all of the above is just
fluff.
IOW, "this helps systemtap" is sufficient reason for merging a kernel
change. For sufficiently large values of "help", and sufficiently small
values of "eww", of course.
I have strong memories of being traumatised by reading the uprobes code.
What's the story on all of that nowadays?
>
> > 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?
next prev parent reply other threads:[~2009-03-21 12:14 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 [this message]
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
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=20090321050422.d1d99eec.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=a.p.zijlstra@chello.nl \
--cc=fche@redhat.com \
--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.