> That will make it part of the kernel ABI, since the mapping depends on> the running kernel, doesn't it?

Well, not the permanent ABI in the sense that AT_* et al are. Thismapping must agree among all users sharing the same ld.so.cache file.That is all. So if you were to change the meaning of a bit that wasused before with a different string, then you could not have theconflicting ld.so.conf.d files both installed at the same time(ldconfig will complain and fail). If you wanted to have two kernelsboth installed that disagree on the string for a given bit, then you'dhave to switch the ld.so.conf.d files and re-run ldconfig when youswitch which kernel you're booting.

There are 32 bits free now. One can anticipate that reassigning a bitwould come up only after these are exhausted. With prudent use, thiswill take a very long time to happen. Then the oldest CPU type stringmight be retired to reuse its bit. It seems unlikely that there willbe a single installation (root directory) that really needs to haveinstalled both a kernel optimized for the oldest CPU model known and akernel optimized for the newest CPU model known. If there is, we canworry about it then.

At any rate, the point remains that these bit assignments are not partof any published userland ABI one has to think about in all the waysthat the real ABI implies. There is nowhere that has to know them orwill ever consider them, except the kernel with the vDSO image builtinside and the ld.so.conf.d file that goes with it.