Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Jeff Garzik <jgarzik@pobox.com>]

Andrew Morton wrote:
> Chris Wright <chrisw@osdl.org> wrote:
> 
>>* Olof Johansson (olof@austin.ibm.com) wrote:
>>
>>>Hi,
>>>
>>>On Thu, Mar 03, 2005 at 05:59:51PM -0800, Andrew Morton wrote:
>>>
>>>>This patch doesn't seem right - current 2.6.11 has:
>>>>
>>>>        return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
>>>
>>>The patch was against what Greg had already pushed into the
>>>linux-release.bkbits.net 2.6.11 tree, i.e. not what's in mainline.
>>>You're right, your revised patch would apply against mainline.
>>>
>>>However: This patch shouldn't go to mainline, since
>>>ppc-ppc64-abstract-cpu_feature-checks.patch in your tree takes care of
>>>the problem. I'd like the abstraction/cleanup patch to be merged upstream
>>>instead of the #ifdef hack once the tree opens up.
>>
>>Olof's patch is in the linux-release tree, so this brings up a point
>>regarding merging.  If the quick fix is to be replaced by a better fix
>>later (as in this case) there's some room for merge conflict.  Does this
>>pose a problem for either -mm or Linus' tree?
> 
> 
> It depends who gets to Linus's tree first.  If linux-release merges first,
> I just revert the temp fix while adding the real fix.  But the temp fix
> should never have gone into Linus's tree in the first place.
> 
> If I merge before linux-release, I guess Linus has some conflict resolving
> to do when he pulls from linux-release.  That's OK for an obvious
> two-liner, but would get out of control for more substantial things.
> 
> Neither solution is acceptable, really.  I suspect the idea of pulling
> linux-release into mainline won't work very well, and that making it a
> backport tree would be more practical.

Maybe you're right, but I tend to think that "quick, get that fix out 
immediately" fixes will appear before more substantial fixes.  That is 
certainly the way things have worked up until now.

For the cases that we care about, putting that into linux-release and 
then pulling would seem more appropriate.

Remember, the linux-release tree for each release will slow down, and 
eventually die off, as we progress towards the next release (where the 
linux-2.6.x.y-1 tree will indeed die).

	Jeff