public inbox for linux-next@vger.kernel.org 
 help / color / mirror / Atom feed
From: Matt Fleming <matt.fleming@intel•com>
To: David Miller <davem@davemloft•net>
Cc: sfr@canb•auug.org.au, linux-next@vger•kernel.org,
	linux-kernel@vger•kernel.org, tj@kernel•org, oleg@redhat•com,
	linux-arch <linux-arch@vger•kernel.org>
Subject: Re: linux-next: build failure after merge of the final tree (sparc, ptrace trees related)
Date: Fri, 14 Oct 2011 10:27:02 +0100	[thread overview]
Message-ID: <1318584422.23581.118.camel@mfleming-mobl1.ger.corp.intel.com> (raw)
In-Reply-To: <20111014.035459.2238341687770152474.davem@davemloft.net>

On Fri, 2011-10-14 at 03:54 -0400, David Miller wrote:
> Ptrace folks can we not operate like this?  The only reason I found
> out about the set_current_blocked() transformations was by accident,
> because the original patch was posted to linux-kernel only so it never
> got queued up into sparc patchwork.
> 
> Then once Oleg mentioned it to me, it didn't even compile so I fixed
> it up and put the fixed up copy into my tree.  It also didn't
> transform the TS_RESTORE_SIGMASK cases in the sparc signal code, so I
> also added a patch to the sparc tree which took care of that.
> 
> Now you guys are creating conflicts against those fixed up patches in
> another non-sparc tree, and adding new kinds of build failures as
> well.
> 
> This doesn't work.

Sorry David, this is my fault.

The reason that these patches couldn't be taken through the arch trees
was because they were dependent on the non-arch patch that introduced
block_sigmask(). I figured it would make more sense to put all the
patches through Oleg's tree. It's now pretty clear I was wrong about
that.

In hindsight, what I should have done was got the first patch that
introduced block_sigmask() into 3.1, then waited till the next release
cycle and sent out all the arch patches to the arch maintainers. That
way the patches could have been pulled into the respective arch trees.

Guys, how did you want to sort this out? Should we get the first patch
into 3.1, then get all the arch maintainers to pick up their patches?

  reply	other threads:[~2011-10-14  9:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-14  7:07 linux-next: build failure after merge of the final tree (sparc, ptrace trees related) Stephen Rothwell
2011-10-14  7:54 ` David Miller
2011-10-14  9:27   ` Matt Fleming [this message]
2011-10-14 11:38   ` Stephen Rothwell
2011-10-14 19:09   ` Oleg Nesterov
2011-10-24  9:36     ` Stephen Rothwell

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=1318584422.23581.118.camel@mfleming-mobl1.ger.corp.intel.com \
    --to=matt.fleming@intel$(echo .)com \
    --cc=davem@davemloft$(echo .)net \
    --cc=linux-arch@vger$(echo .)kernel.org \
    --cc=linux-kernel@vger$(echo .)kernel.org \
    --cc=linux-next@vger$(echo .)kernel.org \
    --cc=oleg@redhat$(echo .)com \
    --cc=sfr@canb$(echo .)auug.org.au \
    --cc=tj@kernel$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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