please pull powerpc.git 'merge' branch

Olof Johansson olof at lixom.net
Sun Apr 30 13:50:01 EST 2006


On Sun, Apr 30, 2006 at 09:47:10AM +1000, Paul Mackerras wrote:
> Olof Johansson writes:
> 
> > Previously we've said implementation instead of specification
> > ("PPC_FEATURE_POWER5_PLUS" etc). That's better than saying base
> > architecture version, since there are parts of the arch that might or
> > might not be implemented (i.e. optional features, etc).
> 
> We now have the AT_PLATFORM string, which we didn't have when we added
> the POWER5_PLUS etc. features.  That specifies which particular
> implementation we are on quite precisely.  We don't want to have a bit
> for every single implementation or we'll run out of bits.
> 
> The ARCH_2_05 bit means all the non-optional bits of the 2.05
> architecture.  If there are optional features in the architecture, we
> have separate bits for them.  For example, we don't have separate
> bits for POWER4 and for 970; instead we have a HAS_ALTIVEC bit, and
> for 970 we set both POWER4 and HAS_ALTIVEC.  So the POWER4 bit is
> really a "2.00 architecture version" bit.

Ok, I guess that's more or less how it's been used, since there's only
been one implementation per architecture version in the past (970 series
being the main exception). The only one left out from the table seems
to be 2.01 (POWER4+), not sure if it had any userspace-visible changes
in the first place.

A rename of existing names might make sense for consistency/clarity. But
that's outside of __KERNEL__ so it would break userspace.

> > Don't you want to fall back to the ELF method if the prom call fails
> > (ret != 0)? Right you close and return.
> 
> If the ibm,client-architecture-support method exists but
> returns an error, call_prom_ret returns zero but puts a non-zero value
> in ret.

Right, that's quite obvious from the implementation.

> In that case we don't want to try the elf-header method.

That was my question, if it made sense to fall back to it. And that's a
"no". Thanks. :-)


-Olof



More information about the Linuxppc-dev mailing list