LKML Archive on
help / color / mirror / Atom feed
From: Arnd Bergmann <>
To: Ingo Molnar <>
Cc: y2038 Mailman List <>,
	Linux Kernel Mailing List <>,
	"the arch/x86 maintainers" <>,
	Linux API <>,
	linux-arch <>,
	Paul Eggert <>,
	"Eric W . Biederman" <>,
	Richard Henderson <>,
	Ivan Kokshaysky <>,
	Matt Turner <>,
	Al Viro <>,
	Dominik Brodowski <>,
	Thomas Gleixner <>,
	Andrew Morton <>,,
	Deepa Dinamani <>
Subject: Re: [PATCH v2 2/2] rusage: allow 64-bit times ru_utime/ru_stime
Date: Thu, 21 Jun 2018 18:25:33 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Jun 21, 2018 at 6:11 PM, Ingo Molnar <> wrote:
> * Arnd Bergmann <> 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

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.



  reply	other threads:[~2018-06-21 16:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-20 12:05 [PATCH v2 1/2] y2038: rusage: Use __kernel_old_timeval for process times Arnd Bergmann
2018-04-20 12:05 ` [PATCH v2 2/2] rusage: allow 64-bit times ru_utime/ru_stime Arnd Bergmann
2018-06-21 15:49   ` Ingo Molnar
2018-06-21 16:01     ` Arnd Bergmann
2018-06-21 16:11       ` Ingo Molnar
2018-06-21 16:25         ` Arnd Bergmann [this message]
2018-06-22  2:16           ` Ingo Molnar
2018-06-22 17:45             ` Eric W. Biederman
2018-06-24  7:12               ` Ingo Molnar
2018-06-25  1:26                 ` Eric W. Biederman
2018-06-25  9:14                   ` Ingo Molnar
2018-06-25 16:21                     ` Eric W. Biederman
2018-06-25 11:42               ` Arnd Bergmann

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).