LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Arnd Bergmann <firstname.lastname@example.org> To: Ingo Molnar <email@example.com> Cc: y2038 Mailman List <firstname.lastname@example.org>, Linux Kernel Mailing List <email@example.com>, "the arch/x86 maintainers" <firstname.lastname@example.org>, Linux API <email@example.com>, linux-arch <firstname.lastname@example.org>, Paul Eggert <email@example.com>, "Eric W . Biederman" <firstname.lastname@example.org>, Richard Henderson <email@example.com>, Ivan Kokshaysky <firstname.lastname@example.org>, Matt Turner <email@example.com>, Al Viro <firstname.lastname@example.org>, Dominik Brodowski <email@example.com>, Thomas Gleixner <firstname.lastname@example.org>, Andrew Morton <email@example.com>, firstname.lastname@example.org, Deepa Dinamani <email@example.com> 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: <CAK8P3a1mx16S+DhEMQA6WBJ7efdhN5YaKKVHU6n+E6kfifM-Qg@mail.gmail.com> (raw) In-Reply-To: <20180621161121.GB7222@gmail.com> On Thu, Jun 21, 2018 at 6:11 PM, Ingo Molnar <firstname.lastname@example.org> wrote: > > * Arnd Bergmann <email@example.com> wrote: > >> Sure, no problem. Do you have an opinion on the question I raised in the >> first patch , 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  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  https://docs.google.com/spreadsheets/d/1HCYwHXxs48TsTb6IGUduNjQnmfRvMPzCN6T_0YiQwis/edit#gid=0
next prev parent 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: 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=CAK8P3a1mx16S+DhEMQA6WBJ7efdhN5YaKKVHU6n+E6kfifM-Qg@mail.gmail.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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: linkBe 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).