[patch v4 0/4] System-wide tunables

[Sam James]

DJ Delorie <dj@redhat.com> writes:

> 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.

+1.

>>
>> DJ, how can I help?
>
> I'm working on a v5 based on Florian's feedback, so watch for that.

Please CC me on that as I'm happy to do my bit along with Yury. We'd
really love to see this in.

>
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 418 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20260209/0fc59f05/attachment.sig>