LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Ingo Molnar <firstname.lastname@example.org> To: Arnd Bergmann <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: Fri, 22 Jun 2018 04:16:36 +0200 [thread overview] Message-ID: <20180622021636.GA11266@gmail.com> (raw) In-Reply-To: <CAK8P3a1mx16S+DhEMQA6WBJ7efdhN5YaKKVHU6n+E6kfifM-Qg@mail.gmail.com> * Arnd Bergmann <firstname.lastname@example.org> wrote: > 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(), So we are thinking about adding wait5() in essence, right? One thing we might want to look into whether the wait4() and waitid() ABIs could be 'merged', by making wait4() essentially a natural special case of waitid(). This would mean that the only new system call we'd have to add is waitid2() in essence, which would solve both the rusage layout problem and would offer a unified ABI. If that makes sense (it might not!!), then I'd also modernize waitid2() by making it attribute structure based, have a length field and make the ABI extensible from now on going forward without having to introduce a new syscall variant every time we come up with something new... I.e. how the perf syscall does ABI extensions: we've had dozens of ABI extensions, some of them pretty complex, and not a single time did we have to modify glibc and tooling was able to adapt quickly yet in a both backwards and forwards compatible fashion. Another, simpler example is the new sys_sched_setattr() syscall, that too is using the perf_copy_attr() ABI method, via sched_copy_attr(). (With a minor compatibility quirk of SCHED_ATTR_SIZE_VER0 that a new wait ABI wouldn't have to do - i.e. it could be made even simpler.) This way we only have: SYSCALL_DEFINE3(sched_setattr, pid_t, pid, struct sched_attr __user *, uattr, unsigned int, flags) But even 'pid' and 'flags' could have been part of the attribute, i.e. one we pick up an attribute structure from user-space we can have really low argument count system calls. This also concentrates all the compat concerns into handling the attribute structure properly - no weird per-arch artifacts and quirks with 4-5-6 system call arguments. Thanks, Ingo
next prev parent reply other threads:[~2018-06-22 2:16 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 2018-06-22 2:16 ` Ingo Molnar [this message] 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=20180622021636.GA11266@gmail.com \ --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 \ --firstname.lastname@example.org \ /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).