Re: linux-next: manual merge of the block tree with the asm-generic tree

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

 



* Ingo Molnar <mingo@xxxxxxxxxx> wrote:

> 
> * Jens Axboe <axboe@xxxxxxxxx> wrote:
> 
> > >>> Peter, what's the verdict - do you want to rebase it, or leave it 
> > >>> as-is?
> > >>
> > >> Ah, I looked into doing this, but tip/locking/core has since grown a 
> > >> bunch of patches and has a merge commit -- I talked to Ingo yesterday 
> > >> and he proposed just queueing a fix on top instead of doing a full 
> > >> rebase.
> > >>
> > >> Ingo, that still your preferred solution?
> > > 
> > > Yeah, that would be the best solution IMO - it's not like there's any 
> > > real prospect of someone bisecting futex2 patch-enablement commits on 
> > > Alpha ... and the bisection distance isn't particularly large either in 
> > > any case.
> > 
> > OK, works for me. I'll keep my branch as-is, and just ensure it gets sent 
> > out after locking/core has been pulled by Linus.
> 
> Thank you!

Heads-up: the futex syscall numbers are now fixed on Alpha in the locking 
tree via:

  dcc134510eef ("alpha: Fix up new futex syscall numbers")

This would, I presume, trigger a new conflict in -next, which should be 
resolved in an identical fashion.

Jens, feel free to send your tree to Linus in any ordering with the
locking tree, there's no real dependency between them, and whoever
sends last should warn Linus about the known conflict.

Thanks,

	Ingo



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

  Powered by Linux