From: "Theodore Ts'o" <tytso@mit.edu>
To: Christian Brauner <christian@brauner.io>
Cc: linux-api@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC]: Convention for naming syscall revisions
Date: Thu, 6 Jun 2019 19:54:35 -0400 [thread overview]
Message-ID: <20190606235435.GD23169@mit.edu> (raw)
In-Reply-To: <20190606154224.7lln4zp6v3ey4icq@brauner.io>
On Thu, Jun 06, 2019 at 05:42:25PM +0200, Christian Brauner wrote:
> Hey everyone,
>
> I hope this is not going to start a trash fire.
>
> While working on a new clone version I tried to find out what the
> current naming conventions for syscall revisions is. I was told and
> seemed to be able to confirm through the syscall list that revisions of
> syscalls are for the most part (for examples see [1]) named after the
> number of arguments and not for the number of revisions. But some also
> seem to escape that logic (e.g. clone2).
There are also examples which show that it's a revision number:
preadv2, pwritev2, mlock2, sync_file_range2
immediately come to mind. It's also important to note that in some
cases, we do something very different (look aht the stat and fstat
variants), and that in some cases the number of parameters for a
system call vary between architectures (because of system call
argument passing limitations), and this gets papered over by glibc.
So we can define what the historical pattern, but there might be a big
difference between what might make sense as an internal naming
convention, and the names that we want to expose to userspace
application programmers --- especially if the number of arguments at
the syscall level might be different (on some architectures) than at
the C library level.
- Ted
next prev parent reply other threads:[~2019-06-06 23:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-06 15:42 [RFC]: Convention for naming syscall revisions Christian Brauner
2019-06-06 23:54 ` Theodore Ts'o [this message]
2019-06-07 13:42 ` Christian Brauner
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=20190606235435.GD23169@mit.edu \
--to=tytso@mit.edu \
--cc=christian@brauner.io \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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: 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