Subject: Re: linux-next: manual merge of the rr tree

From: Ingo Molnar <[email-masked]>
Date: Tue, 6 Jan 2009 15:59:58 +0100

* Mike Travis <[email-masked]> wrote:

> Ingo Molnar wrote:
> > * Mike Travis <[email-masked]> wrote:
> > 
> >> Rusty Russell wrote:
> >>> On Monday 05 January 2009 23:17:45 Ingo Molnar wrote:
> >>>> That would allow Mike, Christoph and you to work this out cleanly from 
> >>>> scratch. It would also solve your merge conflict.
> >>>>
> >>>> Does that sound like a good solution?
> >>> Sure, but it won't make this window.  I guess since those patches 
> >>> don't do anything but lay groundwork it's not critical, but annoying 
> >>> they've lain fallow so long.
> >>>
> >>> I'm happy to put them with the cpualloc patches, since they're related 
> >>> and going to conflict, but I still want to see if Mike has the rest of 
> >>> them?
> >> I do.  And really, as soon as the cpus4096 is safely set for 2.6.29 I 
> >> can devote much more time on it.
> > 
> > I think the complete elimination of cpumask_t should be the primary 
> > priority - before jumping to any other aspect. If we dont get rid of it it 
> > will stick around forever, like the BKL. It was a nice migration helper 
> > but now it's time to wave goodbye? :)
> > 
> > 	Ingo
> 
> I think that's possible for 2.6.30 especially with Rusty's "big hammer" 
> patch that removes the definition of cpumask_t.  Of course, as has been 
> the delay forever, is dealing with all the arch's.  The current method 
> of some via tip, some via linux-next/rr has been somewhat excruciating. 
> How about we push the big ones via -mm so we get more complaints early 
> on?

Sure, can do it via -mm or via -tip/cpus4096.

> Or some other suggestion?  Once the "big hammer" patch is in, there will 
> be massive fallout, and I plan on being on an extended vacation when 
> that happens... ;-)

hm, on a second thought, lets do it via -mm only ;-)

	Ingo