On Mon, 2005-01-17 at 10:16 +0000, David Woodhouse wrote:

On Sun, 2005-01-09 at 16:13 +0100, Olaf Hering wrote:

quoted

quoted

ChangeSet 1.2347, 2005/01/08 14:02:27-08:00, hpa@zytor.com

      [PATCH] raid6: altivec support
      
      This patch adds Altivec support for RAID-6, if appropriately configured on
      the ppc or ppc64 architectures.  Note that it changes the compile flags for
      ppc64 in order to handle -maltivec correctly; this change was vetted on the
      ppc64 mailing list and OK'd by paulus.

This fails to compile on ppc, enable_kernel_altivec() is an exported but
undeclared function. cpu_features is also missing.

I sent Linus & Andrew a patch fixing the enable_kernel_altivec() thing
yesterday. cpu_features isn't missing, it's defined differently.

quoted

drivers/md/raid6altivec1.c: In function `raid6_altivec1_gen_syndrome':
drivers/md/raid6altivec1.c:99: warning: implicit declaration of function `enable_kernel_altivec'
drivers/md/raid6altivec1.c: In function `raid6_have_altivec':
drivers/md/raid6altivec1.c:111: error: request for member `cpu_features' in something not a structure or union
drivers/md/raid6altivec2.c: In function `raid6_altivec2_gen_syndrome':
drivers/md/raid6altivec2.c:110: warning: implicit declaration of function `enable_kernel_altivec'

This makes it compile on PPC, but highlights the difference between
'cur_cpu_spec' on ppc32 and ppc64. Why is 'cur_cpu_spec' an array on
ppc32? Isn't 'cur' supposed to imply 'current'?

It's history. When I wrote that on ppc in the first place, I decided to
leave room for having slightly different CPUs so I defined it as an
array of NR_CPUs.

When we ported this to ppc64, we figured out we never actually used that
"feature", and that the way the dynamic patching works with CPU features
makes it mandatory to have identical feature sets anyway.

We should probably "backport" that simplification to ppc32...

Ben.