[PATCH v2 0/3] System-wide tunables

[Adhemerval Zanella Netto]

On 22/04/24 05:47, Szabolcs Nagy wrote:
> The 04/19/2024 17:11, DJ Delorie wrote:
>> Szabolcs Nagy <szabolcs.nagy@arm.com> writes:
>>> tunables can differ across targets, so they need to be checked not to
>>> cause trouble (e.g. doing a hwcap mask specified by an int instead of
>>> arch feature can do different things across abis)
>>
>> This is no different than setting an environment variable today, right?
>> The data stored in ld.so.cache has pre-computed IDs but also the string
>> names, and the IDs are validated and recomputed in case libc.so changes.
>> The value string is not parsed unless it's a generic "double" type, and
>> even then, the string value is still included.
>>
>> I have not yet implemented any filters for the tunables, but it's
>> already been requested to have an only/exclude filter for "per program
>> image name".  I suppose I could add a filter for only/exclude hwcaps
>> too.
>>
>> Hmm... aren't tunables processed in ld.so, not libc.so  If so, it's
>> *already* more difficult to support multiple glibcs at the same time
>> (tunables mismatch between ld.so and libc.so), unless you have a
>> separate filesystem namespace, in which case you have a separate
>> ld.so.cache also.
> 
> ld.so has different name across abis exactly so you
> can have a filesystem with binaries for multiple abis.
> 
> (i think with qemu-user and binfmt settings you can
> even run cross arch binaries on the same system,
> and e.g. debian supports this via multi-arch paths.
> but even plain old multi-lib can deal with 64bit vs
> 32bit abi)
> 
> shared ld.so.cache and ld.so.conf is imo bad design,
> but if we double down on that then yes we will need
> per arch filters for settings.

I think it makes sense to add arch-specific tunables on same system,
even though this kind of deployment in not that usual as before (maybe
on some debian-like system with qemu-user).

The dl-tunable-list.h is already arch-specific, meaning that the 
environment parsing code will ignore unknown/invalid tunable.  So 
for system-wide configuration, I would expect that ldconfig to ignore
such entries (possible with an warning) and only add on the cache
valid tunables.