mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Christoph Hellwig <hch@infradead.org>,
	Oleg Nesterov <oleg@redhat.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Ananth Mavinakayanahalli <ananth@in.ibm.com>,
	"Frank Ch. Eigler" <fche@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Roland McGrath <roland@redhat.com>,
	linux-kernel@vger.kernel.org, utrace-devel@redhat.com
Subject: Re: [RFC,PATCH 0/14] utrace/ptrace
Date: Fri, 27 Nov 2009 09:04:39 -0500	[thread overview]
Message-ID: <20091127140439.GA17000@infradead.org> (raw)
In-Reply-To: <20091126122441.GC15189@elte.hu>

On Thu, Nov 26, 2009 at 01:24:41PM +0100, Ingo Molnar wrote:
> FYI, the merge window has not opened yet, so it cannot close in a few 
> days.

subsystems merged window, not Linus'.

> 
> > [...] and thus not getting any of the broad -next test coverage is a 
> > pretty bad idea.  In the end it will be the maintainers ruling but 
> > that doesn't make it a good idea from the engineering point of view.
> 
> FYI, it's been in -mm, that's where it's maintained.

None of the recent mm snapshots has anything utrace related in there,
just a few ptrace patches from Oleg (which are in this series but a very
small part of it) and certainly not all this new code that is pretty
recent (take a look at the utrace list for the development).

> Yes. Which is a further argument to not do it like that but to do one 
> arch at a time. Trying to do too much at once is bad engineering.

I'm not sure why you're trying to pick fights here, but no one has said
about doing it all in once.  The point I'm trying to make is that it's
pretty bad to keep parallel ptrace implementations, and we should settle
on one.  A pre-requisite of using the new once genericly is to have the
architecture ptrace code updated.  I think arm and mips are the two
only relevant ones still missing, so updating them and killing the other
ones is easy.

If you think keeping the two ptrace implementations is fine argue for
that directly, but please stick to the technical points instead of just
fighting for fightings sake.

  reply	other threads:[~2009-11-27 14:04 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-24 20:01 Oleg Nesterov
2009-11-25  8:03 ` Ananth N Mavinakayanahalli
2009-11-25 15:40   ` Oleg Nesterov
2009-11-26  7:53     ` Ananth N Mavinakayanahalli
2009-11-26 14:50       ` powerpc: fork && stepping (Was: [RFC,PATCH 0/14] utrace/ptrace) Oleg Nesterov
2009-11-26 17:25         ` Oleg Nesterov
2009-11-26 18:22           ` Veaceslav Falico
2009-11-26 20:23             ` Oleg Nesterov
2009-11-26 21:04               ` Oleg Nesterov
2009-11-26 21:53               ` Paul Mackerras
2009-11-26 22:37                 ` Oleg Nesterov
2009-11-27 17:46                   ` Veaceslav Falico
2009-11-28  7:30                     ` Ananth N Mavinakayanahalli
2009-11-29 21:07                       ` powerpc: syscall_dotrace() && retcode (Was: powerpc: fork && stepping) Oleg Nesterov
2009-11-29 23:15                         ` Benjamin Herrenschmidt
2009-11-30  0:43                           ` Benjamin Herrenschmidt
2009-11-30 20:00                             ` Oleg Nesterov
2009-11-30 20:01                           ` Oleg Nesterov
2009-12-01 19:27                             ` Roland McGrath
2009-12-01 20:17                               ` Benjamin Herrenschmidt
2009-11-26 22:40                 ` powerpc: fork && stepping (Was: [RFC,PATCH 0/14] utrace/ptrace) Andreas Schwab
2009-11-27  5:39         ` Ananth N Mavinakayanahalli
2009-11-27 15:05           ` Oleg Nesterov
2009-11-28  7:06             ` Ananth N Mavinakayanahalli
2009-11-25 21:48 ` [RFC,PATCH 0/14] utrace/ptrace Christoph Hellwig
2009-11-25 22:28   ` Oleg Nesterov
2009-11-26  7:07   ` Srikar Dronamraju
2009-11-26 12:55     ` Peter Zijlstra
2009-11-26  9:10   ` Ingo Molnar
2009-11-26 10:47     ` Christoph Hellwig
2009-11-26 12:24       ` Ingo Molnar
2009-11-27 14:04         ` Christoph Hellwig [this message]
2009-11-27 14:17           ` Oleg Nesterov
2009-11-27 19:16           ` Ingo Molnar
2009-11-26 14:27       ` Oleg Nesterov
2009-12-02  0:46         ` Roland McGrath
2009-11-29  8:59   ` Pavel Machek

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=20091127140439.GA17000@infradead.org \
    --to=hch@infradead.org \
    --cc=adobriyan@gmail.com \
    --cc=ananth@in.ibm.com \
    --cc=fche@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --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

all inboxes | Powered by JetHome®