From: Albert ARIBAUD <albert.aribaud@3adev.fr>
To: Joseph Myers <joseph@codesourcery.com>
Cc: Zack Weinberg <zackw@panix.com>,
GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof
Date: Fri, 08 Sep 2017 18:16:00 -0000 [thread overview]
Message-ID: <20170908201619.465012b5.albert.aribaud@3adev.fr> (raw)
In-Reply-To: <alpine.DEB.2.20.1709081746090.16313@digraph.polyomino.org.uk>
On Fri, 8 Sep 2017 17:59:00 +0000, Joseph Myers
<joseph@codesourcery.com> wrote :
> On Fri, 8 Sep 2017, Albert ARIBAUD wrote:
>
> > Regarding whether the patches should land only once the kernel is
> > Y0238-safe: these patches are intended to run even on a current and thus
> > completely Y2038-unsafe kernel, in which case they use 64-bit-time on
> > user side (to make applications compiled with _TIME_BITS==64 happy at
> > least until Y2038 happens) and 32-bit time on kernel side. So I don't
> > see why these patches should wait for a Y2038-safe kernel per se.
>
> Where the kernel layouts of structures are suitable for use by glibc, we'd
> like to avoid translation layers. E.g., we need to know what the kernel's
> struct stat64 variant for 64-bit time_t will look like to ensure no
> translation layer is needed. (If the answer is that statx is the
> interface that should be used for 64-bit times in struct stat so the
> kernel doesn't need to define such a stat64 variant, then the translation
> layer is needed anyway and we should maybe use the asm-generic 64-bit
> struct stat variant of the layout on all 32-bit platforms.)
Understood -- but as soon as 64-bit-time types are frozen on the kernel
side, we could freeze the corresponding GLIBC API types (hopefully
without a translation layer needed) and then if GLIBC gets out there
before the kernel does, it won't be a problem since in any case the
64-bit-time implementation must fall back to 32-bit syscalls if the
64-bit syscalls return an ENOSYS.
Cordialement,
Albert ARIBAUD
3ADEV
next prev parent reply other threads:[~2017-09-08 18:16 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-07 22:42 Albert ARIBAUD (3ADEV)
2017-09-07 22:42 ` [RFC PATCH 01/52] Y2038: add type __time64_t Albert ARIBAUD (3ADEV)
2017-09-07 22:42 ` [RFC PATCH 02/52] Y2038: add function __difftime64 Albert ARIBAUD (3ADEV)
2017-09-07 22:42 ` [RFC PATCH 03/52] Y2038: add functions using struct tm Albert ARIBAUD (3ADEV)
2017-09-07 22:42 ` [RFC PATCH 04/52] Y2038: add function __mktime64 (and timelocal) Albert ARIBAUD (3ADEV)
2017-09-07 22:42 ` [RFC PATCH 05/52] Y2038: add function __timegm64 Albert ARIBAUD (3ADEV)
2017-09-07 22:42 ` [RFC PATCH 06/52] Y2038: add struct __timespec64 Albert ARIBAUD (3ADEV)
2017-09-07 22:42 ` [RFC PATCH 07/52] Y2038: add function __clock_gettime64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 08/52] Y2038: add function __clock_settime64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 09/52] Y2038: add function __clock_getres64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 10/52] Y2038: add function __clock_nanosleep64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 11/52] Y2038: add function __timespec_get64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 12/52] Y2038: add function __futimens64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 13/52] Y2038: add function __utimensat64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 14/52] Y2038: add function __sigtimedwait64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 15/52] Y2038: add struct __timeval64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 16/52] Y2038: add function __futimes64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 17/52] Y2038: add function __lutimes64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 18/52] Y2038: add struct __itimerspec64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 19/52] Y2038: add function __timer_gettime64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 20/52] Y2038: add function __timer_settime64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 21/52] Y2038: add function __timerfd_gettime64 Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 22/52] Y2038: add function __timerfd_settime64 Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 23/52] Y2038: add struct __stat64_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 24/52] Y2038: add function __fstat64_t64 (and __fxstat64_t64) Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 25/52] Y2038: add function __stat64_t64 (and __xstat64_t64) Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 26/52] Y2038: add function __lstat64_t64 (and __lxstat64_t64) Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 27/52] Y2038: add function __fstatat64_t64 (and __fxstatat_t64) Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 28/52] Y2038: add function __time_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 29/52] Y2038: add function __stime_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 30/52] Y2038: add function __utimes_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 31/52] Y2038: add function __gettimeofday_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 32/52] Y2038: add function __settimeofday_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 33/52] Y2038: add function __mq_timedsend_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 34/52] Y2038: add function __mq_timedreceive_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 35/52] Y2038: add function __msgctl_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:45 ` [RFC PATCH 36/52] Y2038: add function __sched_rr_get_interval_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:45 ` [RFC PATCH 37/52] Y2038: add function __nanosleep64_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:45 ` [RFC PATCH 38/52] Y2038: add function __adjtime_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:45 ` [RFC PATCH 39/52] Y2038: add function __utime_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:45 ` [RFC PATCH 40/52] Y2038: add struct __itimerval_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:45 ` [RFC PATCH 41/52] Y2038: add function __getitimer_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:45 ` [RFC PATCH 42/52] Y2038: add function __setitimer_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:45 ` [RFC PATCH 43/52] Y2038: add functions using futexes Albert ARIBAUD (3ADEV)
2017-09-07 22:45 ` [RFC PATCH 44/52] Y2038: add function __getrusage_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:45 ` [RFC PATCH 45/52] Y2038: add struct __ntp_timeval_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:45 ` [RFC PATCH 46/52] Y2038: add function __ntp_gettime_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:45 ` [RFC PATCH 47/52] Y2038: add function __ntp_gettimex_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:45 ` [RFC PATCH 48/52] Y2038: add function __adjtimex_t64 (and __ntp_adjtime_t64) Albert ARIBAUD (3ADEV)
2017-09-07 22:46 ` [RFC PATCH 49/52] Y2038: add function pselect Albert ARIBAUD (3ADEV)
2017-09-08 17:49 ` [RFC PATCH 50/52] Y2038: add function select Albert ARIBAUD (3ADEV)
2017-09-08 17:49 ` [RFC PATCH 51/52] Y2038: add RPC functions Albert ARIBAUD (3ADEV)
2017-09-08 17:49 ` [RFC PATCH 52/52] Y2038: add _TIME_BITS==64 support Albert ARIBAUD (3ADEV)
2017-09-08 19:47 ` Joseph Myers
2017-09-08 19:47 ` [RFC PATCH 51/52] Y2038: add RPC functions Joseph Myers
2017-09-08 19:59 ` Paul Eggert
2017-09-09 14:37 ` Albert ARIBAUD
2017-09-11 6:33 ` Paul Eggert
2017-09-11 7:06 ` Paul Eggert
2017-09-11 14:07 ` Paul Eggert
2017-09-11 15:59 ` Albert ARIBAUD
2017-09-07 23:21 ` [RFC PATCH 00/52] Make GLIBC Y2038-proof Joseph Myers
2017-09-08 16:19 ` Zack Weinberg
2017-09-08 16:43 ` Joseph Myers
2017-09-08 16:54 ` Paul Eggert
2017-09-08 17:01 ` Zack Weinberg
2017-09-08 17:24 ` Joseph Myers
2017-09-08 18:32 ` Zack Weinberg
2017-09-08 17:42 ` Albert ARIBAUD
2017-09-08 17:59 ` Joseph Myers
2017-09-08 18:16 ` Albert ARIBAUD [this message]
2017-09-08 18:36 ` Zack Weinberg
2017-09-08 17:08 ` Albert ARIBAUD
2017-09-08 17:26 ` Joseph Myers
2017-09-08 19:19 ` Albert ARIBAUD
2017-09-08 4:23 ` Albert ARIBAUD
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170908201619.465012b5.albert.aribaud@3adev.fr \
--to=albert.aribaud@3adev.fr \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=zackw@panix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).