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> <CAK8P3a3GotM4WY9dJK8yPujxLgHXtnes=nMUKq5fJ4hTkZWqzg@mail.gmail.com>
 <20190307154310.677b59dd@jawa>
In-Reply-To: <20190307154310.677b59dd@jawa>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Thu, 7 Mar 2019 16:26:54 +0100
Message-ID: <CAK8P3a0OBBEwU044jbe-YK2CmCnpNpUSiCA9uRo-8EwtcUva6g@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 3:43 PM Lukasz Majewski <lukma@denx.de> wrote:
> > On Thu, Mar 7, 2019 at 8:53 AM Lukasz Majewski <lukma@denx.de> wrote:
> > > > On Tue, Mar 5, 2019 at 10:24 AM Lukasz Majewski <lukma@denx.de>

> To be more specific:
>
> I'm thinking of settimeofday/gettimeofday syscalls.
>
> In the kernel we use internally do_sys_settimeofday64() to support
> clock_settime() and settimeofday()
>
> The internal (in-kernel) representation for those two is struct
> timespec64.
>
> If I may ask - why settimeofday64() and gettimeofday64() are not
> implemented?
>
> Is it because the same result can be achieved with clock_settime64(tv64)
> + settimeofday(NULL, tz) ?
> (The drawback is two syscalls instead of one).

Yes, that is the idea. I don't see the drawback as significant here,
since settimeofday() is not performance critical.

> I've also stumbled upon the __kernel_timex introduction on the
> playground branch:
>
> "time: Add struct __kernel_timex"
> 2c620ff93d9fbd5d644760d4c21d389078ec1080
>
> This one introduces the:
> struct __kernel_timex_timeval {
>         __kernel_time64_t tv_sec;
>         long long tv_usec;
> };
>
> This code is "protected" by CONFIG_64BIT_TIME.
>
> Is there any plan to explicitly introduce:
>
> struct __kernel_timeval {
>        __kernel_time64_t tv_sec;
>        long ong tv_usec;
> }
>
> and convert settimeofday()/gettimeofday() ?

No, see above. Basically all system calls that take a 'timeval'
already have a replacement that uses a 'timespec' with
nanosecond resolution, so the idea was that by not having
a new timeval, we make sure to catch any calls that need a
nanosecond based version as well.

clock_adjtime() is a bit of a special case here because
it uses a timeval structure but passes nanoseconds in it
when ADJ_NANO is set.

      Arnd