This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 08/12] Use clock_gettime to implement gettimeofday.
On 20/08/2019 10:21, Zack Weinberg wrote:
> Abstractly, this is the same change as using clock_gettime to
> implement time, but the vestigial “get time zone” feature of
> gettimeofday complicates matters a little. Unlike settimeofday, there
> are *no* known uses of this feature that are not bugs, so it is simply
> dummied out. (The per-process timezone support in ‘localtime’ and
> friends is unrelated, and the programs that set the kernel’s offset
> between the hardware clock and UTC do not need to read it back.)
>
> Henceforth, if gettimeofday’s ‘struct timezone’ argument is not NULL,
> it will write zeroes to both fields. Any program that is actually
> looking at this data will thus think it is running in UTC, which is
> probably more correct than whatever it was doing before.
>
> Hurd having already been converted, this patch only affects Linux and
> hypothetical future ports. Most Linux ports supplied a vDSO symbol
> for gettimeofday, and some wrapped that with an ifunc, so this patch
> deletes a lot of code. For ease of future edits to the many copies of
> _libc_vdso_platform_setup, the variable ‘p’ in each is now declared
> separately from any use of it.
I personally would prefer to make gettimeofday implementation use
clock_gettime internally regardless, it has the clear code simplification
advantage, and it allows an architecture provide only clock_gettime as vDSO
to optimize all get time related functions.
However some architecture does implement it with vDSO as latency optimization
and I think we should consult with arch maintainers to see if this change is
indeed acceptable.
On my vDSO refactor for gettimeofday [1], I tried to keep current code
as is and the fallback code is still calling __NR_gettimeofday (since
all current architectures support the syscall).
[1] https://sourceware.org/ml/libc-alpha/2019-07/msg00158.html