On Sun, Apr 30, 2006 at 09:47:10AM +1000, Paul Mackerras wrote:

Olof Johansson writes:

quoted

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.

quoted

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