[patch v4 0/4] System-wide tunables
DJ Delorie
dj@redhat.com
Mon Feb 9 20:57:24 GMT 2026
Yury Khrustalev <yury.khrustalev@arm.com> writes:
> I think we should come back to this patch as this functionality
> will be of great help. Let's make it done by 2.44.
>
> DJ, how can I help?
I'm working on a v5 based on Florian's feedback, so watch for that.
As for helping, I see two opportunities:
1. Technical review. When you see v5, go through it and look for bugs,
missing required functionality, etc. "Could it work" checks. I'm
not asking for feature creep, just making sure the first version
isn't buggy.
2. There are still a few design choices that aren't 100% consensus'd,
which could use some discussion and someone to drive consensus,
including:
- should the new settings be in ld.so.conf or their own file
- should the cache be reloadable over the life of a running program
- how much pre-processing, pre-warning, etc should ldconfig do
For the first, I argued for a separate file to keep from interfering
with sysadmins or scripts managing ld.so.conf, but process it with
ldconfig so that sysadmins or scripts that don't know about tunables
will at least do the right thing. The counter argument is that having a
second set of file parsing code is more complexity and a source of bugs,
but the code is relatively short and copied from existing code.
The second was requested by Carlos, and I took it as an opportunity to
make loading the tunables easier - since tunables are loaded BEFORE
dynamic objects, I needed the cache loaded earlier than it was.
Coordinating that across both modules was easier if I refactored the API
first. Long running programs benefit from path updates for
newly-installed plugins, but the risk is that cache changes mean
inconsistent sets of objects.
The third is about whether ldconfig should accept a tunable it doesn't
recognize, or reject one if it exceeds its limits. I went for a
compromise - warn all you want, but put the data in the cache anyway,
and let the program decide if the values are OK or not. Numbers are
pre-parsed to save time, but validated by the program.
There may be other issues still pending, too. This change has taken way
longer than I expected :-P
More information about the Libc-alpha
mailing list