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:   Thu, 7 Mar 2019 08:53:29 +0100
From:   Lukasz Majewski <lukma@denx.de>
To:     Zack Weinberg <zackw@panix.com>
Cc:     Arnd Bergmann <arnd@arndb.de>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Joseph Myers <joseph@codesourcery.com>,
        GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [Y2038] Question regarding support of old time interfaces
 beyond y2038
Message-ID: <20190307085329.2b6cbeb7@jawa>
In-Reply-To: <CAKCAbMjiW8=X1u8nm6nEkAz+MyF=msN97Fr59=v01HbHb=U6UA@mail.gmail.com>
References: <20190305162351.5aadde66@jawa>
        <CAKCAbMjiW8=X1u8nm6nEkAz+MyF=msN97Fr59=v01HbHb=U6UA@mail.gmail.com>
Organization: denx.de
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 boundary="Sig_/_O84/=n1/JGR/xZjBb97pa1"; protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

--Sig_/_O84/=n1/JGR/xZjBb97pa1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hi Zack,

> On Tue, Mar 5, 2019 at 10:24 AM Lukasz Majewski <lukma@denx.de> wrote:
> > From 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." =20
>=20
> 1) We should be clear that most of these will continue to be supported
> as C library interfaces even if they are not system calls.  Some of
> them are obsolete enough and/or rarely used enough that we might not
> bother (the older ways to set the system clock, for instance).

The question here is about the decision if even the old time APIs shall
be supported on 32 bit systems which are going to be Y2038 proof (like
the 'stime').

>=20
> 2) I know of one case where the new interfaces don't cover all of the
> functionality of the old ones: timers started by setitimer continue to
> run after an execve, timers started by timer_create don't.  This means
> setitimer(ITIMER_VIRTUAL) can be used to impose a CPU time limit on a
> program you didn't write, and timer_create can't.  If new kernels are
> not going to have setitimer as a primitive, we need some other way of
> getting the same effect.
>=20
> zw


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_/_O84/=n1/JGR/xZjBb97pa1
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

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

iQEzBAEBCAAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAlyAzfkACgkQAR8vZIA0
zr2nggf7BGowmvktUvdEQr5elh3XlSHx1uP8Q0WooEI8BU3DJR6t9sn7Bl7dq/kV
PuxcQjxFSoxeosDZo7GHJ3olbf/yEP4jgsVOrsrUl4poB7yX2bj5kydh2FW1e7AC
xXGfzfgzcIOOh3cL5tkOvMSzvsJDuPtOXKw/N6zyLXJ610mwWMnrDFBWXNBqknNB
Tfu4lkc7KNufhxPhPqKSes8BhPNyRvXAaY3uihkSoHrubM1W27qaxq0UnFBio8Pj
MhE02W4jLBUX38F03G2GT4y1ZoRqHkIAkmlGd86z/7jU+UcPezdG/MJ/xkfjiQfF
hx4NMsyb2cPwkOBXHQDtNxauKgMt7g==
=8Pen
-----END PGP SIGNATURE-----

--Sig_/_O84/=n1/JGR/xZjBb97pa1--