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

[Dave Jones]

On Thu, Mar 03, 2005 at 02:45:15PM -0800, Greg KH wrote:
 > On Fri, Mar 04, 2005 at 09:30:22AM +1100, Paul Mackerras wrote:
 > > Jeff Garzik writes:
 > > > Rene Rebe wrote:
 > > > > Hi,
 > > > > 
 > > > > 
 > > > > --- linux-2.6.11/drivers/md/raid6altivec.uc.vanilla    2005-03-02 
 > > > > 16:44:56.407107752 +0100
 > > > > +++ linux-2.6.11/drivers/md/raid6altivec.uc    2005-03-02 
 > > > > 16:45:22.424152560 +0100
 > > > > @@ -108,7 +108,7 @@
 > > > >  int raid6_have_altivec(void)
 > > > >  {
 > > > >      /* This assumes either all CPUs have Altivec or none does */
 > > > > -    return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
 > > > > +    return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;
 > > > 
 > > > 
 > > > I nominate this as a candidate for linux-2.6.11 release branch.  :)
 > > 
 > > No.  Unfortunately if you fix ppc64 here you will break ppc, and vice
 > > versa.  Yes, we are going to reconcile the cur_cpu_spec definitions
 > > between ppc and ppc64. :)
 > 
 > Fine, dueling arches, who wins?  :)
 > 
 > So, what do I do, just ignore the patch?  Or do you have a fix?

until its fixed properly, how about this ?

+#ifdef CONFIG_PPC64
     return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;
+#else
+    return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
+#endif


Brings about an interesting conundrum with teh 2.6.x.y branch.
If fixing something properly is invasive, would we want to allow
band-aids to get things working ? This would make things more difficult
wrt Linus being able to pull the previous .y branch into his current
tree, but bitkeepers conflict resolution is really unsurpassed for
such situations in my experience.

		Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/