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;
MIME-Version: 1.0
References: <20190305162351.5aadde66@jawa> <CAKCAbMjiW8=X1u8nm6nEkAz+MyF=msN97Fr59=v01HbHb=U6UA@mail.gmail.com>
 <20190307085329.2b6cbeb7@jawa>
In-Reply-To: <20190307085329.2b6cbeb7@jawa>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Thu, 7 Mar 2019 09:05:21 +0100
Message-ID: <CAK8P3a3GotM4WY9dJK8yPujxLgHXtnes=nMUKq5fJ4hTkZWqzg@mail.gmail.com>
Subject: Re: [Y2038] Question regarding support of old time interfaces beyond y2038
To:     Lukasz Majewski <lukma@denx.de>
Cc:     Zack Weinberg <zackw@panix.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Joseph Myers <joseph@codesourcery.com>,
        GNU C Library <libc-alpha@sourceware.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Mar 7, 2019 at 8:53 AM Lukasz Majewski <lukma@denx.de> wrote:
>
> 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."
> >
> > 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').

See my other reply. In the kernel, it won't be supported (the old syscall
is of course still there, but we may have an option to remove all time32
interfaces). In glibc, it's probably there in a y2038-safe way since it is
there now, other C libraries may take other decisions that are independent
of y2038.

      Arnd