linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-arch@vger.kernel.org, tony.luck@intel.com,
	linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org,
	David Miller <davem@davemloft.net>,
	linuxppc-dev@ozlabs.org, Paul Mackerras <paulus@samba.org>,
	sparclinux@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Roland McGrath <roland@redhat.com>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [PATCH 6/8] ptrace: arch_ptrace -ENOSYS return
Date: Fri, 21 Mar 2008 16:07:34 +0100	[thread overview]
Message-ID: <20080321150734.GD1545@elte.hu> (raw)
In-Reply-To: <alpine.LFD.1.00.0803210744470.3020@woody.linux-foundation.org>


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> > The reason I took the approach I did instead is incrementalism. I 
> > can't change that signature without breaking about 22 arch builds.
> 
> Don't worry about the arch builds. If that's your main worry and 
> reason for this, it's not worth it. Yes, ptrace changes, and yes, we 
> may have arch issues, but no, it's not that big of a deal. Just break 
> them.
> 
> Make sure x86[-64] works, and make sure that other architectures *can* 
> work (and explain it on linux-arch) when you have to fix something up, 
> but ptrace is a blip on the radar for people, it's not going to be a 
> huge issue.

for a long time all the nice but intrusive utrace improvements from 
Roland had this big adoption barrier. So Roland went around that and 
with a lot of effort he made it optional, incremental and per arch, so 
that we could try it on x86 and merge it upstream.

Now that we see how cleaner it is and that it actually was an almost 
regression-free endevour on x86 (we had 2 regressions so far, both fixed 
- which is an amazing feat for such wide changes IMO), i very much agree 
that we should just do the "rest" of this in one big step.

it's a bit of a chicken & egg problem for such changes. If it breaks 
architectures it gets dropped out of -mm - even though 90% of our 
developers, 95% of our testers and 99% of our active users are using x86 
only.

but in general, prototyping something on a single architecture in the 
first step is OK - and maybe even the first merge is OK. But once it has 
been proven on the most tested Linux platform that we have (and there's 
no blatant x86-ism in it), there's no reason not to mandate it.

	Ingo

  reply	other threads:[~2008-03-21 16:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-19 21:17 [PATCH 1/8] ptrace: forced_successful_syscall_return() macro Roland McGrath
2008-03-19 21:18 ` [PATCH 2/8] alpha ptrace: forced_successful_syscall_return() Roland McGrath
2008-03-19 21:19 ` [PATCH 3/8] ia64 " Roland McGrath
2008-03-19 21:19 ` [PATCH 4/8] powerpc " Roland McGrath
2008-03-24  7:55   ` Paul Mackerras
2008-03-19 21:20 ` [PATCH 5/8] sparc64 " Roland McGrath
2008-03-19 21:30   ` David Miller
2008-03-19 21:20 ` [PATCH 6/8] ptrace: arch_ptrace -ENOSYS return Roland McGrath
2008-03-20  2:40   ` Linus Torvalds
2008-03-20  7:40     ` Christoph Hellwig
2008-03-20  8:16     ` Roland McGrath
2008-03-21 13:50       ` Thomas Gleixner
2008-03-21 14:07         ` Christoph Hellwig
2008-03-21 14:10         ` Sam Ravnborg
2008-03-21 14:55       ` Linus Torvalds
2008-03-21 15:07         ` Ingo Molnar [this message]
2008-03-19 21:20 ` [PATCH 7/8] x86 " Roland McGrath
2008-03-19 21:21 ` [PATCH 8/8] powerpc " Roland McGrath

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=20080321150734.GD1545@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=paulus@samba.org \
    --cc=roland@redhat.com \
    --cc=rth@twiddle.net \
    --cc=sparclinux@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=torvalds@linux-foundation.org \
    /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;
as well as URLs for NNTP newsgroup(s).