public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
	Andi Kleen <andi@firstfloor.org>,
	Ananth Mavinakayanahalli <ananth@in.ibm.com>,
	Christoph Hellwig <hch@infradead.org>,
	"Frank Ch. Eigler" <fche@redhat.com>, Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <peterz@infradead.org>,
	Roland McGrath <roland@redhat.com>,
	linux-kernel@vger.kernel.org, utrace-devel@redhat.com
Subject: Re: [PATCH 0/7] utrace/ptrace
Date: Wed, 23 Dec 2009 18:42:32 +0100	[thread overview]
Message-ID: <20091223174232.GA14993@redhat.com> (raw)
In-Reply-To: <20091222135809.1ab10869.akpm@linux-foundation.org>

On 12/22, Andrew Morton wrote:
>
> On Fri, 18 Dec 2009 02:11:16 +0100
> Oleg Nesterov <oleg@redhat.com> wrote:
>
> > It allows for multiple separate tracing engines to work
> > in parallel without interfering with each other.  Higher-level tracing
> > facilities can be implemented as loadable kernel modules using this layer.
>
> That's a bit brief.  Do you have a nicer sales brochure?  What are
> these "separate tracing engines" and what is their merge status and why
> would we want any of them, for what purpose?  etc.
>
> IOW: give us a reason!

First of all, utrace makes other things possible. gdbstub, nondestructive
core dump, uprobes, kmview, hopefully more. I didn't look at these projects
closely, perhaps other people can tell more. As for their merge status,
until utrace itself is merged it is very hard to develop them out of tree.

To me, even seccomp is the good example why utrace is useful. seccomp
is simple, but it needs hooks in arch/ hot pathes. Contrary, utrace-based
implementation is more flexible, simple, and it is completely "hidden"
behind utrace.

In my opinion, ptrace-utrace is another example. Once CONFIG_UTRACE
goes away, we can remove almost all ptrace-related code from core
kernel (and kill task_struct->ptrace/etc members).

ftrace/etc is excellent in many ways, but even if we need the simple
"passive" tracing it is not enough sometimes. And we have nothing else
except ptrace currently. But ptrace is so horrible and unfixeable, and
it has so many limitations. In fact, even the simple things like stop/
continue this thread/process are not trivial using ptrace, gdb/strace
have to do a lot of hacks to overcome ptrace's limitations, and some
of these hacks falls into "mostly works, but that is all" category.

Of course, I can't promise we will have the new gdb which explores
utrace facilities soon, but I think at leat utrace gives a chance.


Well. I had a lot of technical discussions with Roland about utrace,
but I never asked him why he created this thing ;) To me, utrace
looks like vfs. Currently we have the single and very poor "filesystem",
ptrace. Until we add the appropriate layer, we can't expect the
further improvements is this area.

Oleg.


  reply	other threads:[~2009-12-23 17:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-18  1:11 [PATCH 0/7] utrace/ptrace Oleg Nesterov
2009-12-22 21:58 ` Andrew Morton
2009-12-23 17:42   ` Oleg Nesterov [this message]
2009-12-23 19:33     ` Roland McGrath
2009-12-23 19:47       ` Andi Kleen
2009-12-23 19:55         ` Roland McGrath
     [not found] <1319782550.2227981262142487066.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
2009-12-30  3:09 ` caiqian

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=20091223174232.GA14993@redhat.com \
    --to=oleg@redhat.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=ananth@in.ibm.com \
    --cc=andi@firstfloor.org \
    --cc=fche@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=roland@redhat.com \
    --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