Re: Rd: [RFC] dl-procinfo and HWCAP_IMPORTANT support for powerpc

[Steve Munroe <sjmunroe at us dot ibm dot com>]

Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 12/24/2005
12:47:22 AM:

>
> > The dl_procinfo mechanism is intended to for "retail" distributions for
> > "general purpose" computers. Like Apple G3 vs G4 vs G5. In the Intel
space
> > they only support 2 values "i686" and "x86_64". There is practical
limit
> > (2, 3, maybe 4) to the number of <cpu_types> a distro is willing to
> > build/test. For power we are starting with power4 because that it is
the
> > first implementation of the Version 2.0 PowerPC Architecture (and the
> > Weakly Consistent Storage Model).
> >
> > If you are building a SDK or runtime for an embedded processor you can
use
> > --with-cpu= to build a optimized version of glibc.
>
> Even then, ignoring embedded if you think that's a good idea (I know
> some embedded folks who will not agree here), I still think we are
> asking for trouble around the corner. I mean, you know how many
> micro-architectures we have, we should probably at least add the
> commonly used freescale ones (g4 typically), then there is cell, and
> things are still evolving.
>

I am NOT ignoring embedded. The dl-procinfo mechanism is just part of a
comprehensive proposal which starts will the --with-cpu= support. This
(--with-cpu=) mechanism can support an arbitrary number of <cpu_type>
implementations.

The dl-procinfo mechanism supports a specific delivery model (fat rpms with
multiple implementations of libraries). This mechanism is about "delivery
to the customer" associated with general purpose distro's. So the Apple G3,
G4's ... should be added to the dl-procinfo mechanism.

However it is my understanding that embedded processors don't (can't) use
the general purpose distro's. A embedded Linux SDK can be very specific to
the chip and doesn't need the fat rpm mechanism. So IMHO the dl-procinfo
mechanism would never be used in practice for the embedded space (they will
build the single libc.so they need and ship that with the SDK).

So the key to resolving this issue is to understand how the embedded folks
deliver the SDK to their customers. If I am misinformed, then some one who
actually works on Linux for the embedded space, should speak up.

> I really think it's not a good idea to mix the actual microarchitecture
> of the processor with the feature bits.
>

Fine. I asked for the AT_HWCAP bits because it was implemented, AT_PLATFORM
was not. It was just easier to extend an existing mechanism then define a
new one. Also in the current dl-procinfo mechanism, AT_HWCAP allows for
multiple modifiers (like ALTIVEC combined with POWER4 or G4). AT_PLATFORM
does not. This allows for "commoning up" based on ISA features independent
of microarch.

Steven J. Munroe
Linux on Power Toolchain Architect
IBM Corporation, Linux Technology Center