This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 12/26/2005
04:04:46 PM:

> On Mon, 2005-12-26 at 10:09 -0600, Steve Munroe wrote:
>
> Heh, there is no need to bring up the buzzwords ! :)
>
> I know what you want and I agree, I was just trying to point a specific
> technical detail of the implementation, which I think might corner us in
> the future if we aren't careful.
>

> > 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).
>
> It depends. Been there done that. You can have a line of products using
> different ppc embedded processors and wanting to have your core userland
> identical for maintainance/upgrade reasons. In fact, "embedded" covers
> pretty much any situation which is why I'm keen on making sure our
> solution is scalable enough.
>
I have no problem with supporting AT_PLATFORM. I just think that 2 dozen
unique platform names could be problematic for the purpose of fat rpms and
selecting CPU-tuned libraries. ie. a simple "G4" is better than "7400" and
"7450" and ...

I also understand the for other purposes a "fine grained" (exactly whihc
chip) AT_PLATFORM might seem more useful. That I why I suggested that
providing the PVR value via a different Aux Vector entry.

> > 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.
>
> They all do differently. Anyway, there is no need to focus on embedded
> now, it's just one piece of the puzzle.
>
But I just realized that ppc64 kernel will have different/separate
AT_PLATFORM list from the ppc32 kernel.

PPC64 would return "power4", "power5", "power5+" and "970" ("power3" and
"630" if you want to) for AT_PLATFORM which is OK.

The list for the ppc32 kernel is not my (direct) concern.

> > 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.
>
> Euh...yes, but AT_HWCAP was implemented for feature bits. We just only
> added some microarchitectures to it, afaik, upon your request. It's all
> new enough that I don't see the problem in discussing it and possibly
> coming with a better alternative.
>
OK but consider this:

"power4" maps to PowerPC ISA Version 2.00
"power5" maps to PowerPC ISA Version 2.01
"power5+" maps to PowerPC ISA Version 2.02

These AT_HWCAP bits ARE valid features (each level adds new instructions to
the ISA, as well as microarch discriminators). I think "cell" has other
unique ISA features that justifies its inclusion in the AT_HWCAP.

I don't have this kind info for the various flavours of PPC32 processor. I
happily defer to those who have this knowledge to decide.

> >  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.
>
> Yes, but that isn't incompatible. For example, a 970 could/would be a
> POWER4 microarch with the altivec feature bit set. In general, features
> like altivec _has_ to be independant bits anyway since LPAR environments
> might make them unavailable even if the processor we are running on at a
> given point in time supports them.
>
I did some experimenting with how dl_procinfo behaves and found that the
combination of AT_HWCAP and AT_PLATFORM can get complicated and redundant.

For example with the current AT_HWCAP (current 2.6.15), dl-procinfo would
add the following the following search paths for a G5/JS20:

/lib[64]/altivec/power4:
/lib[64]/altivec:
/lib[64]/power4:

If the kernel also supported AT_PLATFORM and returned "970", dl-procinfo
would combine this with the AT_HWCAP & HWCAP_IMPORTANT bits and add the
follow search paths:

/lib[64]/970/altivec/power4:
/lib[64]/970/altivec:
/lib[64]/970/power4:
/lib[64]/970:
/lib[64]/altivec/power4:
/lib[64]/altivec:
/lib[64]/power4:

Which seems a bit redundant to me. But if I knew that AT_PLATFORM was
available the HWCAP_IMPORTANT mask could be adjusted to only include
PPC_FEATURE_ALTIVEC which would yield the following search paths:

/lib[64]/970/altivec:
/lib[64]/970:
/lib[64]/altivec:

For a "power5" it would simply add:

/lib[64]/power5:

So it matters when and how AT_PLATFORM is introduced. The HWCAP_IMPORTANT
mask will have to be adjusted when AT_PLATFORM support is implemented and
the search paths will change. Changing the search path later would be
really bad. So if we are going to add AT_PLATFORM support we should do it
ASAP.

I offer the following proposal for powerpc64: Add AT_PLATFORM support where
the <platform> strings match the <cpu_type> strings supported by gcc. This
harmonises library search path names with --with-cpu= targets.

One detail to work out relates to G5. Is the AT_PLATFORM for a G5, "G5" or
"970". Both are valid -mcpu= strings but I should ask David Edelsohn if
there is any different in the code gen. It would be simpler to use "970"
for both G5 and JS20.

This nets out to: "power2", "power3", "power4", "power5", "power5+", and
"970" (and "cell"?).

The AT_PLATFORM details for power32 kernel are more complicated and can be
resolved independently.

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

> Ben.
>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]