From: Ingo Molnar <mingo@elte.hu>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Roland McGrath <roland@redhat.com>,
jdike@addtoit.com, utrace-devel@redhat.com,
linux-kernel@vger.kernel.org
Subject: Re: [RFC, PATCH 0/2] utrace/ptrace: simplify/cleanup ptrace attach
Date: Wed, 6 May 2009 10:12:25 +0200 [thread overview]
Message-ID: <20090506081225.GD8098@elte.hu> (raw)
In-Reply-To: <20090505230642.GA980@redhat.com>
* Oleg Nesterov <oleg@redhat.com> wrote:
> On 05/04, Andrew Morton wrote:
> >
> > On Mon, 4 May 2009 12:43:48 -0700 (PDT)
> > Roland McGrath <roland@redhat.com> wrote:
> >
> > > I guess we should take Andrew's advice on this. To me, it
> > > makes most sense just to order the -mm patches so utrace comes
> > > later, and replace the utrace patch as necessary with a
> > > compatible version. Perhaps things would be simpler if we
> > > made a separate standalone series or git tree (tip/ptrace?)
> > > for ptrace cleanups.
> >
> > Staging the utrace patch at end-of-series would make sense if
> > utrace is not on track for a 2.6.31 merge.
> >
> > And afaict, this is indeed the case - things seem to have gone a
> > bit quiet on the utrace front lately.
>
> The only goal of current ptrace cleanups is to simplify the
> "ptrace over utrace" change (hopefully they make sense by
> themselves though).
>
> I am obviously biased, but imho the only real problem with
> utrace-ptrace.patch is the current ptrace code which needs
> cleanups.
Yes. But realize the fundamental reason for that: _without_
ptrace-over-utrace the utrace core code is a big chunk of dead code
only used on the fringes. I see and agree with all the future uses
of utrace, but it's easy to be problem-free if a facility is not
used by anything significant.
So a clean ptrace-over-utrace plugin is absolutely needed for utrace
to go upstream in v2.6.31. The ftrace plugin alone does not justify
it. The real prize here is a (much!) cleaner ptrace code. Once
ptrace is driven via utrace and it works, its value (and trust
level) will skyrocket.
Ingo
next prev parent reply other threads:[~2009-05-06 8:14 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-03 18:55 [RFC, PATCH 0/2] utrace/ptrace: simplify/cleanup ptrace attach Oleg Nesterov
2009-05-04 18:49 ` Roland McGrath
2009-05-04 19:30 ` Oleg Nesterov
2009-05-04 19:43 ` Roland McGrath
2009-05-04 23:31 ` Andrew Morton
2009-05-05 1:12 ` Roland McGrath
2009-05-05 23:06 ` Oleg Nesterov
2009-05-06 8:12 ` Ingo Molnar [this message]
2009-05-06 8:23 ` Christoph Hellwig
2009-05-06 9:05 ` Ingo Molnar
2009-05-06 9:11 ` Christoph Hellwig
2009-05-06 9:37 ` Ingo Molnar
2009-05-07 6:13 ` Roland McGrath
2009-05-08 15:08 ` 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=20090506081225.GD8098@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=jdike@addtoit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--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 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.