Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 5 Mar 2019 16:23:51 +0100
From:   Lukasz Majewski <lukma@denx.de>
To:     Arnd Bergmann <arnd@arndb.de>
Cc:     linux-kernel@vger.kernel.org,
        Joseph Myers <joseph@codesourcery.com>,
        libc-alpha@sourceware.org
Subject: [Y2038] Question regarding support of old time interfaces beyond
 y2038
Message-ID: <20190305162351.5aadde66@jawa>
Organization: denx.de
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 boundary="Sig_/U6Mt1c/ACWt.uM4j5lcQ_X_"; protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

--Sig_/U6Mt1c/ACWt.uM4j5lcQ_X_
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Dear Arnd,

In your "playground" repository [1] (branch: y2038), the time functions
(stime, settimeofday, etc) are not converted in Linux to be Y2038 aware
(as for example clock_settime{64}() is).

I've also searched on the Internet and I've found some old discussions
regarding them:

SHA1:  d33c577cccd0b3e5bb2425f85037f26714a59363 [2]
=46rom commit message:

"The time, stime, utime, utimes, and futimesat system calls are only
used on older architectures, and we do not provide y2038 safe variants
of them, as they are replaced by clock_gettime64, clock_settime64,
and utimensat_time64."

Moreover, the stime has been even explicitly marked as obsolete [3].


=46rom other discussion [4] - regarding the following system calls:
 time, stime, gettimeofday, settimeofday, adjtimex, nanosleep, alarm,
 getitimer, setitimer, select, utime, utimes, futimesat, and
 {old,new}{l,f,}stat{,64}.

"These all pass 32-bit time_t arguments on 32-bit
 architectures and are replaced by other interfaces (e.g. posix
 timers and clocks, statx). C libraries implementing 64-bit time_t in
 32-bit architectures have to implement the handles by wrapping
 around the newer interfaces."


Has something changed since then? Has any new idea for conversion
emerged?


After observing the development of y2038 on playground [1], I can deduce
that new interfaces are only going to be supported and converted
(clock_settime64/clock_gettime64, etc.)

Considering the above - would it be best to drop Y2038 support on 32
bit machines for old syscalls (stime and friends) and for some others
(settimeofday/gettimeofday) write Y2038 wrappers based on new time
kernel API (clock_gettime/settime) in the C library (i.e. glibc)?


Note:

[1] -
https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/tree/ke=
rnel/time/time.c?h=3Dy2038
[2] - git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git
[3] -=20
https://elixir.bootlin.com/linux/v2.6.32/source/arch/arm/include/asm/unistd=
.h#L419
[4] - https://lists.linaro.org/pipermail/y2038/2017-November/002387.html


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

--Sig_/U6Mt1c/ACWt.uM4j5lcQ_X_
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAlx+lIgACgkQAR8vZIA0
zr32BQgAyxT4NNpx0F9Xj1EXXunxDrKEsCni69+pBPwGifM+zkOtJShFOCLOefRR
KXFblSM21PpnoknEXmc2WO/Q13fuu2wmACwaQVNQLKOdEGKfkeRfR1lM3Hk17l6y
TIBcSLnMu7Vco4UVOQAXJ5rre85U4fJioaLg9BbcUFkFI7Y2uFXHTRJ9rA8mEsaa
YQDOyZd+B3dRe8Oeu/d7lt+/fL4SEl4CSj92OulXSZ/fD+EOuuos6bT09TUarX9w
xepmsOahJ/vT1b6RAS5RW1bsBiG0ESN/S4Pk7bEZmAP6l8ZDzsMV3tJfMSIfMs4W
XuZmbZV6fLudrFXDzuROwtqQ6DeVvg==
=PzDo
-----END PGP SIGNATURE-----

--Sig_/U6Mt1c/ACWt.uM4j5lcQ_X_--