archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <>
To: Jens Axboe <>
Cc: Stephen Rothwell <>,, Thomas Gleixner <>,
	"H. Peter Anvin" <>,
	the arch/x86 maintainers <>
Subject: Re: linux-next: manual merge of the block tree
Date: Fri, 27 Jun 2008 11:26:26 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

* Jens Axboe <> wrote:

> > That way we could pull it into tip/x86 and give it some testing on 
> > the x86 side, and resolve its integration effects. Would that be 
> > possible?
> Currently I have two branches for this - one is generic-ipi, which 
> contains the generic bits and all the arch conversions. The other is 
> smp_call_function, which kills the unused argument to 
> smp_call_function() (and friends) and on_each_cpu(). If I separate out 
> the non-x86 archs, I'll have trouble getting it all in for 2.6.27 as 
> I'll be on vacation as of july 5th.
> So it's not tied in with any block bits, but it does have all archs. 
> Even if it's a bit of a weird thing to put the whole thing into the 
> x86 tree, I don't mind if we do that. Heck, it's in the block repo to 
> begin with :-)

i'll put this into tip/generic-ipi and wont put into the x86 topics 
towards linux-next - i just want to see the effects in practice.

This is the 102th -tip topic, there's space for all :-)

> So if you could pull:
> git:// generic-ipi
> and
> git:// smp_call_function
> and merge them with the x86 changes, that would be fine. It's also the 
> place where we currently have conflicts due to 32-bit and 64-bit stuff 
> being merged, so it would help Stephen as well.

i have an even better, brilliant plan :-)

what we could do is that we could offer an auto-generic-ipi-next 
integration branch that to Stephen that is tip/auto-x86-next plus 

in fact i've just implemented this. You can pull the resulting 
tip/auto-generic-ipi-next tree from:

  git:// auto-generic-ipi-next

[ note: just first raw merge and conflict resolution, not tested yet. ]

note that it embedds your tree in a Git way and we can update the 
tip/generic-ipi branch in an append-only manner and it can go towards 
Linus in whatever way you prefer. (as long as you do not rebase the 

If you agree with this setup then this tree could be put after all these 
-next branches:


and then it will merge without conflicts. It's auto-updated to all these 
branches - i.e. when these branches are iterated then 
auto-generic-ipi-next will be iterated as well.

how does this sound to you? Nothing changes to your work flow (just keep 
those branches updated and let me know when i should pull from them), 
but conflicts are auto-eliminated from Stephen's flow and the conflict 
resolution workload and burden is put on those who generate them (the 
x86 folks and you).


  reply	other threads:[~2008-06-27  9:26 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-27  6:13 linux-next: manual merge of the block tree Stephen Rothwell
2008-06-27  8:30 ` Ingo Molnar
2008-06-27  8:47   ` Jens Axboe
2008-06-27  9:26     ` Ingo Molnar [this message]
2008-06-27  9:57       ` Ingo Molnar
2008-06-27 10:11         ` Ingo Molnar
2008-06-27 11:21           ` Jens Axboe
2008-06-27 11:21         ` Jens Axboe
2008-06-27 11:18       ` Jens Axboe
  -- strict thread matches above, loose matches on Subject: below --
2013-10-25 15:03 linux-next: Tree for Oct 25 Thierry Reding
2013-10-25 15:03 ` linux-next: manual merge of the block tree Thierry Reding
2013-10-14 14:48 linux-next: Tree for Oct 14 Thierry Reding
2013-10-14 14:48 ` linux-next: manual merge of the block tree Thierry Reding
2013-10-11 19:04 Mark Brown
2013-10-01 11:03 linux-next: Tree for Oct 1 Thierry Reding
2013-10-01 11:07 ` linux-next: manual merge of the block tree Thierry Reding
2013-09-30 11:26 linux-next: manual merge of the bcon tree Thierry Reding
2013-09-30 11:26 ` linux-next: manual merge of the block tree Thierry Reding
2008-12-15  7:08 Stephen Rothwell
2008-11-19  3:21 Stephen Rothwell
2008-11-19  9:14 ` Jens Axboe
2008-11-19  9:32   ` Stephen Rothwell
2008-11-07  6:14 Stephen Rothwell
2008-11-07  6:10 Stephen Rothwell
2008-11-07  9:50 ` Jens Axboe
2008-11-07 10:07   ` Stephen Rothwell
2008-10-15  7:40 Stephen Rothwell
2008-09-05  6:12 Stephen Rothwell
2008-09-05  6:22 ` Jens Axboe
2008-09-05 13:58   ` James Bottomley
2008-09-03  5:58 Stephen Rothwell
2008-09-03  5:55 Stephen Rothwell
2008-09-02  6:06 Stephen Rothwell
2008-09-02  5:59 Stephen Rothwell
2008-08-28  5:30 Stephen Rothwell
2008-08-27  5:48 Stephen Rothwell
2008-08-27  5:47 Stephen Rothwell
2008-06-27  6:09 Stephen Rothwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).