[PATCH v2 0/3] System-wide tunables

[PATCH v2 0/3] System-wide tunables

[DJ Delorie]

This patch series is the initial implementation of system-wide
tunables, which I mentioned a few months ago.

The first part has ldconfig read tunable information from
/etc/tunables.conf and store it to /etc/ld.so.cache.  Reusing ldconfig
means no new documentation or training would be required of sysadmins,
or reprogramming of distro packaging.

The second part optimizes the loading of /etc/ld.so.cache and allows
for it to be loaded independently of searching for libraries.

The third part applies the stored tunable information to the running
application.

Changes since v1: fixed format bug in error() and rebased.  No other
  changes.

DJ Delorie (3):
  Add system-wide tunables: ldconfig part
  Add system-wide tunables: cache ld.so.cache
  Add system-wide tunables: Apply tunables part

 elf/Makefile               |   1 +
 elf/cache.c                |  65 +++++-
 elf/dl-cache.c             | 276 +++++++++++++++++--------
 elf/dl-tunables.c          |  85 ++++++++
 elf/ldconfig.c             |  21 +-
 elf/tunconf.c              | 408 +++++++++++++++++++++++++++++++++++++
 elf/tunconf.h              |  43 ++++
 sysdeps/generic/dl-cache.h |   6 +
 sysdeps/generic/ldconfig.h |   2 +
 9 files changed, 818 insertions(+), 89 deletions(-)
 create mode 100644 elf/tunconf.c
 create mode 100644 elf/tunconf.h

-- 
2.39.3

Re: [PATCH v2 0/3] System-wide tunables

[Szabolcs Nagy]

The 04/18/2024 23:48, DJ Delorie wrote:
> This patch series is the initial implementation of system-wide
> tunables, which I mentioned a few months ago.
> 
> The first part has ldconfig read tunable information from
> /etc/tunables.conf and store it to /etc/ld.so.cache.  Reusing ldconfig
> means no new documentation or training would be required of sysadmins,
> or reprogramming of distro packaging.

a user may want multiple glibcs with different abi
on the same system (32bit, ilp32, lp64, l64p128, ..)
all sharing the same /etc/ld.so.cache (iirc this is
possible now)

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)

and i'm not sure it's a good idea that one glibc cannot
be independently updated from others since tunables are
not abi stable, while iirc the /etc/ld.so.chace is
backward compat.

Re: [PATCH v2 0/3] System-wide tunables

[DJ Delorie]

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.

Re: [PATCH v2 0/3] System-wide tunables

[Szabolcs Nagy]

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.