[patch v4 1/4] Add system-wide tunables: ldconfig part

[Adhemerval Zanella Netto]

On 17/06/25 21:32, DJ Delorie wrote:
> Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> writes:
>> Checking how tunables.conf and ld.so.cache plays together I found some
>> cases we will need to define which is the expected semantic; since they
>> differ from that ld.so does:
> 
> IIRC the idea was "the system-wide tunables are a source and cache for
> tunables, but not authoritative" I.e. parsing and validating are up to
> the application using them, just like the environent variable.  The
> cache even stores both the parsed and raw values for the tunables, in
> case the internal tunable IDs don't match from cache to app.

I recall we discussed this briefly that our idea was to validate the tunable
during process execution.  However, I think we need to aim for consistency
and have ldconfig to parse and validate because:

  1. It helps the system administrator to catch invalid and/or ill-formatted
     tunables that won't be effective during the system configuration.  It
     will help system administrator to relying on runtime probing to understand
     why the tunable is not working.

  2. The system wide tunable configuration would be consistent with the
     environment variable; which parses and validates the tunable string.

  3. The ldconfig and ld.so are distributed together, and although we do
     support ld.so.cache versioning, allowing valid but not supported
     nor invalid value tunables during *ldconfig* setup does not add much
     value (the tunable won't affect the system anyway).

  4. Validating the tunable and having a consistent set helps runtime
     startup performance, since it is one thing less to do at every process
     execution.

> 
>>  1. And invalid tunable, i.e 'glibc.invalid.tunable=0', prints which
>>     seems an error:
>>
>>     $ ./elf/ldconfig -r /tmp/ldconfig
>>     top 0 name `glibc.invalid.tunable' (-1) value `0'
> 
> Likely a leftover debug statement.  I tend to put a lot of those in when
> writing code.
>