public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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>
Subject: Re: [Y2038] Question regarding support of old time interfaces beyond y2038
Date: Tue, 05 Mar 2019 16:56:29 +0000	[thread overview]
Message-ID: <1551804989.2925.283.camel@codethink.co.uk> (raw)
In-Reply-To: <CAKCAbMjiW8=X1u8nm6nEkAz+MyF=msN97Fr59=v01HbHb=U6UA@mail.gmail.com>

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

  reply	other threads:[~2019-03-05 16:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-05 15:23 [Y2038] Question regarding support of old time interfaces beyond y2038 Lukasz Majewski
2019-03-05 16:05 ` Zack Weinberg
2019-03-05 16:56   ` Ben Hutchings [this message]
2019-03-07  7:53   ` Lukasz Majewski
2019-03-07  8:05     ` Arnd Bergmann
2019-03-07 14:43       ` Lukasz Majewski
2019-03-07 15:26         ` Arnd Bergmann
2019-03-07 19:20     ` Joseph Myers
2019-03-05 17:04 ` Arnd Bergmann
2019-03-07  7:47   ` Lukasz Majewski

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=1551804989.2925.283.camel@codethink.co.uk \
    --to=ben.hutchings@codethink.co.uk \
    --cc=arnd@arndb.de \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukma@denx.de \
    --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