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? -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
