This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]