From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752163AbcIMEJT (ORCPT ); Tue, 13 Sep 2016 00:09:19 -0400 Received: from mail-pf0-f196.google.com ([209.85.192.196]:34308 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750712AbcIMEJS (ORCPT ); Tue, 13 Sep 2016 00:09:18 -0400 Date: Tue, 13 Sep 2016 14:09:08 +1000 From: Nicholas Piggin To: Stephen Rothwell Cc: Michal Marek , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Kees Cook , linux-arch@vger.kernel.org, Al Viro , Michael Ellerman , Benjamin Herrenschmidt , PowerPC Subject: Re: linux-next: manual merge of the kbuild tree with Linus' tree Message-ID: <20160913140908.04b360e1@roar.ozlabs.ibm.com> In-Reply-To: <20160913140257.6d2de178@canb.auug.org.au> References: <20160912113224.792b24f0@canb.auug.org.au> <20160912125341.0596ed9f@roar.ozlabs.ibm.com> <20160913093945.521a28b4@canb.auug.org.au> <20160913140257.6d2de178@canb.auug.org.au> Organization: IBM X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 13 Sep 2016 14:02:57 +1000 Stephen Rothwell wrote: > Hi Michal, > > [For the new cc's, we are discussing the "thin archives" and "link dead > code/data elimination" patches in the kbuild tree.] > > On Tue, 13 Sep 2016 09:39:45 +1000 Stephen Rothwell wrote: > > > > On Mon, 12 Sep 2016 11:03:08 +0200 Michal Marek wrote: > > > > > > On 2016-09-12 04:53, Nicholas Piggin wrote: > > > > Question, what is the best way to merge dependent patches? Considering > > > > they will need a good amount of architecture testing, I think they will > > > > have to go via arch trees. But it also does not make sense to merge these > > > > kbuild changes upstream first, without having tested them. > > > > > > I think it makes sense to merge the kbuild changes via kbuild.git, even > > > if they are unused and untested. Any follow-up fixes required to enable > > > the first architecture can go through the respective architecture tree. > > > Does that sound OK? > > > > And if you guarantee not to rebase the kbuild tree (or at least the > > subset containing these patches), then each of the architecture trees > > can just merge your tree (or a tag?) and then implement any necessary > > arch dependent changes. I fixes are necessary, they can also be merged > > into the architecture trees. > > Except, of course, the kbuild tree still has the asm EXPORT_SYMBOL > patches that produce warnings on PowerPC :-( (And I am still reverting > the PowerPC specific one of those patches). > I'm working on a better patch to fix that (and to whitelist powerpc's relocation checks to it does not get blamed for such breakage) Although no guarantees about that yet. However some of the enablement and subsequent patches I would like to merge are quite architecture specific, and I would prefer them to go via arch trees. So I would like to see a kbuild branch with these 3 in it, if arch maintainers (or specifically powerpc) would be willing to pull it in their -next branches. Thanks, Nick