This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC v3 04/23] sysdeps/clock_gettime: Use clock_gettime64 if avaliable
On 18/07/2019 05:18, Florian Weimer wrote:
> * Arnd Bergmann:
>
>> I have two ideas for how that could be done:
>>
>> - When building for a minimum kernel version of 5.1, don't
>> fall back to __vdso_clock_gettime() or syscall(__NR_clock_gettime)
>> but use the slow path for __clock_gettime64() if the vdso doesn't
>> work.
>
> Assuming that clock_gettime64 support is available, yes.
>
>> - if __vdso_clock_gettime64() is unavailable and __vdso_clock_gettime()
>> returns negative seconds, fall back to syscall(__NR_clock_gettime).
>
> I don't want to do anything like this. I expect that some of us will
> eventually use time namespaces to keep programs running (with incorrect
> time). If we make glibc itself time-sensitive, then things will get
> horribly complex.
>
>> Would either of those meet your requirements?
>
> I don't have requirements. I just want something that has limited
> impact on 64-bit architectures. I don't think probing at startup is too
> bad, actually.
I hope that my vDSO refactor patchset [1] may simplify the support.
For the patchset it just a matter of define the expected vDSO symbol
name (HAVE_CLOCK_GETTIME_VSYSCALL for time32), and then
{INLINE,INTERNAL}_VSYSCALL will check, demangle, call, and fallback
to syscall.
I would expect that for time64_t it would be a matter to just add
a new define, HAVE_CLOCK_GETTIME64_VSYSCALL, where each architecture
would define if were the case.
[1] https://sourceware.org/ml/libc-alpha/2019-06/msg00344.html