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


> 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 ...

It's certainly the case that makers of general-purpose systems are not
going to want to include umpteen different tuned builds in their fat
library packages or their installation options for different packages.
For example, Fedora has only ever had builds for two or three flavors of
anything at most on x86.  That said, there is no big harm in having a
larger number of known platform strings in glibc.  (This is contrary to
going willy-nilly with HWCAP_IMPORTANT bits, which translate to many more
directories searched for combinations of bits set, rather than just
replacing the single platform name with another in the same one search step.)

The AT_PLATFORM string is compared against the known list in a linear
search, so you want the likely values to be first in the list and not to
have so large a number of likely values that doing several strcmps before
hitting is commonplace.  The implementation makes it unwieldly to have
more than say 16, which already sounds like too many for the strcmp
consideration.

Those are the only constraints on having a lot of known platform strings.
What's more important, and is the same for either hwcap bits or platform
strings, is that it's somewhat of a pain to decide to add more later.
With a platform string, the kernel can change and path-based library
searching will use whatever string it gives.  However, if ldconfig has
seen the library in question, which is normal use, then with either an
hwcap or a platform string, the cache-based library searches (the normal
case) will ignore the new platform string unless it's in the recognized
set built into ld.so and ldconfig.  So, you are well-advised to decide now
what set of platform strings you'll care about for new hardware within the
lifetime of systems built in the coming months (i.e. the next major
versions of everyone's systems, that use 2.4 after it's released).

> 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.

These strings are used as directory names in places like /lib, not just in
places like -mcpu= options where it is quite clear that a flavor of
PowerPC CPU is what that string is.  The only existing practice using
these is on x86, where the strings are i?86, which is the same as a CPU
identifier seen alone in places like uname output and config tuples.
To me, it seems unwise to have these strings be something that sounds so
generic out of context as "cell" or "970".  I tend to think all the
strings for powerpc should start with "power" or "ppc".

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

Indeed, and we on the libc lists would be more than happy if you all took
this discussion of powerpc CPU details elsewhere and resolve it amongst
yourselves what set of hwcap bits and platform strings you want the kernel
to potentially supply.  Aside from the spelling nits of their canonical
names known to glibc, it's not a libc issue.  The libc issue is what what
hwcap bits to use in library search, and what set of platform strings to
put in the known list for ldconfig cached search.  For the reasons I
mentioned above, you want to get this right the first time as much as
possible, and get that in place before we release 2.4, which means it
should be decided upon within the next few weeks ideally.


Thanks,
Roland


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