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

[Roland McGrath <roland at redhat dot com>]

> I am just trying to follow the directions that Roland gave, and that was to
> use AT_HWCAP. As far as I can tell AT_PLATFORM only really works for i386
> and may be arm. x86_64 jams in the const string "x86_64" which is not
> applicable to this problem. The vast majority of platforms (including
> powerpc) don't support AT_PLATFORM. The AT_HWCAP support for the current
> need is in 2.6.15.
> 
> I worked with the cards I was dealt.

What I'm sure I told you in fact is that AT_HWCAP and AT_PLATFORM are the
available mechanisms, and you should work out with the ppc kernel community
what most usefully expresses the variety of hardware characteristics worth
considering.  I really don't care whether you use one, the other, or both.

To affect library search, AT_HWCAP bits have to be listed in the glibc
source as "important", and glibc determines the mapping of bits to names.
If the kernel turns on new bits, glibc won't do anything at all with them
without source changes.  (But a new kernel can turn on multiple bits to
have newer glibcs use them all and older ones use only some.)

AT_PLATFORM is a string supplied by the kernel.  The kernel can supply any
string and that affects the library directory search path.  A new kernel
tomorrow giving a new string makes an existing glibc look in a new
directory.  However, the cache built by ldconfig will only look in platform
subdirs for the platform names that ldconfig knows about, which are those
in the glibc source.  So when relying on ldconfig (as is the norm), a new
kernel supplying a new and different string will not have any platform at
all recognized by ld.so so that it affects cached lookups.

Known AT_HWCAP bits are recognized by some small number (16 on ppc atm) of
bit tests.  Known AT_PLATFORM strings are recognized by strcmp tests
against a small set of short constant strings (four 5-byte strings, on x86).
It's six of one, half a dozen of the other.  I don't think there is
anything especially wrong with what we have now (i.e. no AT_PLATFORM).


Thanks,
Roland