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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <sfr@xxxxxxxxxxxxxxxx> wrote:
>
> On Mon, 12 Sep 2016 11:03:08 +0200 Michal Marek <mmarek@xxxxxxx> 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).

-- 
Cheers,
Stephen Rothwell
--
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



[Index of Archives]     [Linux Kernel]     [Linux USB Development]     [Yosemite News]     [Linux SCSI]

  Powered by Linux