linux-kernel - Re: linux-next: manual merge of the kbuild tree with Linus' tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 13 Sep 2016 09:39:45 +1000
From:   Stephen Rothwell <sfr@...b.auug.org.au>
To:     Michal Marek <mmarek@...e.cz>
Cc:     Nicholas Piggin <npiggin@...il.com>, linux-next@...r.kernel.org,
        linux-kernel@...r.kernel.org, Kees Cook <keescook@...omium.org>,
        linux-arch@...r.kernel.org
Subject: Re: linux-next: manual merge of the kbuild tree with Linus' tree

Hi Michal,

On Mon, 12 Sep 2016 11:03:08 +0200 Michal Marek <mmarek@...e.cz> 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.

-- 
Cheers,
Stephen Rothwell