[PATCH v5 2/4] Add system-wide tunables: cache ld.so.cache
Adhemerval Zanella Netto
adhemerval.zanella@linaro.org
Fri Feb 27 19:53:38 GMT 2026
On 27/02/26 16:38, DJ Delorie wrote:
> Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> writes:
>> I agree with Yury here that we need to add some tests, at least some
>> minimal one that stress the ld.so.cache reload (which is not the usual
>> scenario). I would suggest add test-containts tests that:
>
> Yup, I was thinking the same thing. One test should be able to test
> both good->bad and bad->good as well as changes to paths.
>
>> 1.3. If not modifying the ld.so.cache contents keep the same
>> contents.
>
> I assume this just requires doing two dlopen()'s back to back and making
> sure they both work?
Yeap, I double check next week if this scenario cover everything.
>
>>> + static int copy_old_time = 0;
>>
>> Maybe use bool here?
>
> Can do.
>
>>> + /* At this point, NEW_CACHE_FILE_TIME is valid as well as
>>> + CACHE_FILE_TIME, so we compare them. We list fields in the order
>>> + they're most likely to be different in. */
>>> + return ((new_cache_file_time.st_mtime != cache_file_time.st_mtime)
>>> + || (new_cache_file_time.st_ino != cache_file_time.st_ino)
>>> + || (new_cache_file_time.st_size != cache_file_time.st_size)
>>> + || (new_cache_file_time.st_dev != cache_file_time.st_dev)
>>> + );
>>
>> Maybe only keep the required fields, instead of while stat struct?
>> If we use a struct the test could optimized in bulk by the compiler.
>
> Done. I used this syntax to avoid having to "know" what the struct stat
> field types are:
>
> static struct {
> typeof (struct __stat64_t64.st_mtime) mtime;
> typeof (struct __stat64_t64.st_ino) ino;
> typeof (struct __stat64_t64.st_size) size;
> typeof (struct __stat64_t64.st_dev) dev;
> } cache_file_time, new_cache_file_time;
Neat, it should work.
More information about the Libc-alpha
mailing list