Date:   Thu, 21 Jun 2018 18:25:33 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     y2038 Mailman List <y2038@...ts.linaro.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Linux API <linux-api@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Paul Eggert <eggert@...ucla.edu>,
        "Eric W . Biederman" <ebiederm@...ssion.com>,
        Richard Henderson <rth@...ddle.net>,
        Ivan Kokshaysky <ink@...assic.park.msu.ru>,
        Matt Turner <mattst88@...il.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Dominik Brodowski <linux@...inikbrodowski.net>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-alpha@...r.kernel.org,
        Deepa Dinamani <deepa.kernel@...il.com>
Subject: Re: [PATCH v2 2/2] rusage: allow 64-bit times ru_utime/ru_stime

On Thu, Jun 21, 2018 at 6:11 PM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Arnd Bergmann <arnd@...db.de> wrote:
>
>> Sure, no problem. Do you have an opinion on the question I raised in the
>> first patch [1], i.e. whether we actually want this to be done this way in the
>> kernel, or one of the other approaches I described there?
>
> So this looks like the most forward looking variant:
>
>> a) deprecate the wait4() and getrusage() system calls, and create
>>    a set of kernel interfaces based around a newly defined structure that
>>    could solve multiple problems at once, e.g. provide more fine-grained
>>    timestamps. The C library could then implement the posix interfaces
>>    on top of the new system calls.
>
> ... but given the pretty long propagation time of new ABIs, is this a good
> solution? What would the limitations/trade-offs be on old-ABI systems?

The main purpose of this is to enable consistent 64-bit time_t interfaces in
user space, and for most users this would not change anything as the
existing glibc (both 64-bit and 32-bit) can continue calling the same
interfaces as before.

For those users that are interested in 64-bit time_t on 32-bit binaries,
the first step would be to change the glibc implementation to emulate
the existing interfaces with the new time_t on top of the new syscall
rather than the old (unsafe) syscall. Those users already require both
a new kernel and a new glibc version.

If the new kernel interfaces offer a real benefit, others could start
using them directly as soon as they have updated the libc version.
Note that glibc has not updated their kernel headers version for
a long time, they still allow building with linux-3.2 header files.
However, the glibc maintainers have indicated that they would
probably update that requirement to the then-latest version
when adding support to the new 64-bit time_t syscalls, so this
would become available immediately to all users of the new glibc
version.

However, the other question that has to be asked then is whether
there is anything wrong with wait4()/waitid() and getrusuage() that
we want to change beyond the time value passing. We have
answered a similar question with 'yes' for stat(), which has led
to the introduction of statx(), but so far I expect all other syscalls
to start compatible. See [1] for my current list. In that list, I have
currently marked waitid() and getrusuage() as not to be addressed,
i.e. my approach c) of applying only the first of the two patches but
not the second.

       Arnd

[1] https://docs.google.com/spreadsheets/d/1HCYwHXxs48TsTb6IGUduNjQnmfRvMPzCN6T_0YiQwis/edit#gid=0

Powered by blists - more mailing lists