Re: [Cbe-oss-dev] Cell and new CPU feature bits

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> > Is this bug really going to be exposed in the wild or is it
> > an early silicon bug that will only bite early-testers?
> 
> Is this or any other errata published somewhere? I didn't think they  
> were.

I don't know, but I got approval to publically talk about that one (that
is to get a fix in the kernel, the vDSO, and see with Steve Munroe about
getting one in glibc hptiming as well)

> Our solution back at Apple was to put OF properties on the CPU node  
> for each optional feature. e.g. for fres and frsqrte we put  
> "graphics" since that's the official term for that group of optional  
> instructions. We also put in "data-streams" instead of presuming that  
> dss, etc. were always part of "altivec". These properties nicely fit  
> into our Gestalt() API where "ppcf" had 32 bits to describe these to  
> userland software.

Our firmwares do something similar, at least on pSeries (the cell blade
firmware may need a bit of kicking there). But that's only useful for
the kernel. I'm more interested about what is best to expose those to
userland and we have no such thing as good ol' Gestalt there :) We have
AT_HWCAP which we already use for a combination of things, and I was
wondering about the risk of running out of bits in there. Maybe we'll
have to extend the thing a bit.

I suppose the datastream instructions will mandate their own bits,
though nobody on the field seem to use them on linux at least on open
source code I've seen, and I'll probably add a separate bit for the new
altivec instructions. I was wondering if I should define a bit for those
"graphics" instruction and dcbf X form (at least the later could be just
derived from the uArchitecture bits in there)

Cheers,
Ben.