This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
[RFC 0/7] y2038: clock_settime rework to be Y2038 safe on 32bit systems
- From: Lukasz Majewski <lukma at denx dot de>
- To: libc-alpha at sourceware dot org, Joseph Myers <joseph at codesourcery dot com>
- Cc: Paul Eggert <eggert at cs dot ucla dot edu>, Zack Weinberg <zackw at panix dot com>, Lukasz Majewski <lukma at denx dot de>
- Date: Wed, 27 Mar 2019 09:52:03 +0100
- Subject: [RFC 0/7] y2038: clock_settime rework to be Y2038 safe on 32bit systems
This patch set is a RFC to present the conversion and support
of clock_settime to be Y2038 safe.
This work is based on a previous development/patches:
https://libc-alpha.sourceware.narkive.com/zniMOWui/rfc-patch-00-52-make-glibc-y2038-proof#post68
And shall be applied on top of:
https://github.com/lmajewski/y2038_glibc/commits/mktime_v3_fixes
Github repository:
https://github.com/lmajewski/y2038_glibc/commits/Y2038-2.29-glibc-__clock_settime64_v1-27-03-2019
Shall be used with provided meta-y2038 for development and testing:
https://github.com/lmajewski/meta-y2038
I've used guidelines from:
https://www.gnu.org/software/libc/manual/html_mono/libc.html
"D.2.1 64-bit time symbol handling in the GNU C Library"
to convert *clock_settime*.
- The clock_settime() has been choosen as a relatively easy syscall
for conversion (i.e. no VDO)
- The idea for proceeding: convert a single syscall (clock_settime) or related group
of syscalls (clock_gettime, clock_nanosleep,clock_getres, clock_settime)
- to keep the number of changes manageable
- The explicit 64 bit time related syscalls (Y2038 safe) have been already accepted
to mainline Linux kernel (5.1-rc2):
https://elixir.bootlin.com/linux/v5.1-rc2/source/arch/arm/tools/syscall.tbl#L420
- Test(s) for Y2038 (with using clock_settime) would be added to glibc after the
pair of clock_settime/clock_gettime is accepted/reviewed
- Last two patches of this series shows the way how the Y2038 support is going to
be added to glibc.
- The important question about enabling Y2038 support in glibc:
-- If a well tested group of functions/syscalls (like clock_*) is accepted with
the Y2038 support enabled (_TIME_BITS passed to user program enables 64 bit time)
or
-- The Y2038 support is enabled only when _ALL_ syscalls/functions are Y2038 ready
- I've read that clock_* functions were moved from librt to glibc - what was the
motivation behind this move? Why to we have compatibility code in the rt/* for
clock_settime() if the _real_ support is in time/* ?
Comments are more than welcome.
Lukasz Majewski (7):
y2038: Introduce struct __timespec64
y2038: Provide conversion helpers for struct __timespec64
y2038: clock_settime: Provide __clock_settime64 implementation for
linux
y2038: rt: clock_settime: Convert __clock_settime to __clock_settime64
y2038: clock_settime: implementation for Unix generic
y2038: Support for Y2038 safe time on 32 bit systems (generic code)
y2038: Introduce support for clock_settime() being Y2038 safe
include/features.h | 19 +++++++
include/time.h | 97 ++++++++++++++++++++++++++++++++-
manual/creature.texi | 28 ++++++++++
rt/Versions | 2 +-
rt/clock-compat.c | 3 -
rt/clock_settime.c | 4 +-
sysdeps/unix/clock_settime.c | 23 ++++++--
sysdeps/unix/sysv/linux/clock_settime.c | 51 +++++++++++++----
time/Makefile | 2 +-
time/bits/types/struct___timespec64.h | 39 +++++++++++++
time/bits/types/struct_timespec.h | 8 +++
time/bits/types/time_t.h | 4 ++
time/time.h | 9 +++
13 files changed, 265 insertions(+), 24 deletions(-)
create mode 100644 time/bits/types/struct___timespec64.h
--
2.11.0