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/22/2005
08:06:07 PM:

> On Thu, 2005-12-22 at 20:13 -0600, Tom Gall wrote:
> > Food for thought .. but if there are good reasons for having perfect
> > detail as to the processor one is on, why not just send on the PVR
> and be done
> > with it.
>
> Because you may not need the actual revision :) Anyway, the idea of
> using a doublet is just something that came to mind while I was typing,
> not a properly thought out thing. I still think the micro architecture
> should be out of the HWCAP or we'll just overflow the field.
>
A doublet will not work for the intended purpose. The dl-procinfo requires
a simple string that can be inserted into the library search path. Also by
prior agreement these strings must match the <cpu_type> strings used by gcc
for --with-cpu= and -mcpu=.

If you want to pass the full detail of PVR we should define a different Aux
Vector entry. We have several requests to get at the PVR from large
MiddleWare applications, so we should provide it, but separate from
AT_PLATFORM.

> > > I think it was a mistake to add the microarch like POWER4 in there.
It
> > > should have been a separate entity, possibly the ELF_PLATFORM string.
> > > The change was done in a rush but not properly thought out (and
that's
> > > partially my fault too).
> > >
> >
> > Perhaps we ought to compile the performance impacts one might want to
> > consider so we can continue discussions on what all might (and might
not)
> > be reason to make sure that whatever design we end up with is going to
> > fit.
>
> Yes, well, my main worry is running out of HWCAP bits very soon if we
> add microarchitectures there. Especially if we start having the embedded
> stuff in.
>
I think the embedded guys are under the missimpression that they need this
(dl_procinfo) support. They don't.

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.

> > > In addition, it might be worth using the vdso for some very processor
> > > specific things, thus getting the benefit automatically without
> > > requiring a different libc. I've been pondering putting
implementations
> > > of memcpy and spinlocks in there... food for thoughts at this point
> > > though.
> >

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