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;
Message-ID: <1551804989.2925.283.camel@codethink.co.uk>
Subject: Re: [Y2038] Question regarding support of old time interfaces
 beyond y2038
From:   Ben Hutchings <ben.hutchings@codethink.co.uk>
To:     Zack Weinberg <zackw@panix.com>, Lukasz Majewski <lukma@denx.de>
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>
Date:   Tue, 05 Mar 2019 16:56:29 +0000
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: Codethink Ltd.
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 2019-03-05 at 11:05 -0500, Zack Weinberg wrote:
> > 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."
> 
> 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).
> 
> 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.

{get,set}itimer() are still implemented on all architectures, and I
don't see any sign that that's going to change.  There aren't 64-bit
versions on 32-bit architectures though.  This is explained in the
message for commit 48166e6ea47d23984f0b481ca199250e1ce0730a:

"...these can all be safely implemented in the C library by wrapping
around the existing system calls because the 32-bit time_t they pass
only counts elapsed time, not time since the epoch."

Ben.

-- 
Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom