From: Alejandro Colomar <alx@kernel.org>
To: Elliott Hughes <enh@google.com>,
Stefan Puiu <stefan.puiu@gmail.com>,
Bruno Haible <bruno@clisp.org>,
linux-man@vger.kernel.org
Cc: Alejandro Colomar <alx@kernel.org>,
GNU C Library <libc-alpha@sourceware.org>,
linux-api@vger.kernel.org
Subject: [PATCH 0/2] Use terms consistently in function parameter names.
Date: Sun, 3 Mar 2024 13:15:05 +0100 [thread overview]
Message-ID: <20240303121454.16994-1-alx@kernel.org> (raw)
In-Reply-To: <ZUIlirG-ypudgpbK@debian>
[-- Attachment #1: Type: text/plain, Size: 2673 bytes --]
Hi!
I finally wrote this patch. I had it in my todo for too long.
In <time.h> functions, use duration, instead of request, as suggested by
Elliott.
In ctl functions and similar, there was a lot of variation:
- command
- cmd
- request
- req
- option
- operation
- op
And they all meant the same thing. We have similar problems in the
names of the constants, which have similar variability.
In the case of the function parameters, we can easily rename them. I
chose 'op', as it seems a reasonable (and short) name, and most of the
documentation already used the term 'operation' to refer to the
parameter, even in cases where the parameter was names differently.
I would like to ask to kernel maintainers and libc implementations to
add some consistency here too, and rename the parameters accordingly,
for consistency, or at least use your own consistency, if you don't like
this one, but stick to some rules.
In the case of constants, we can't rename them. Too bad. But I'd like
to ask programmers to have this in mind for when new constants are
added, so that some consistency is followed. (This was something that
made me doubt about using 'op', because most constants seem to use
'_CMD_' in their names. If you prefer 'cmd' for the parameter names for
that reason, let's discuss it.)
Have a lovely day!
Alex
Alejandro Colomar (2):
man*/: epoll_*(), fcntl(), flock(), ioctl(), msgctl(), *prctl(),
ptrace(), quotactl(), reboot(), semctl(), shmctl(), lockf():
Consistently use 'op' and 'operation'
clock_nanosleep.2, nanosleep.2: Use 'duration' rather than 'request'
man2/arch_prctl.2 | 12 +++---
man2/clock_nanosleep.2 | 20 ++++-----
man2/epoll_wait.2 | 4 +-
man2/fcntl.2 | 70 +++++++++++++++----------------
man2/flock.2 | 6 +--
man2/ioctl.2 | 30 +++++++-------
man2/ioctl_console.2 | 8 ++--
man2/ioctl_fideduperange.2 | 2 +-
man2/ioctl_getfsmap.2 | 6 +--
man2/ioctl_ns.2 | 2 +-
man2/ioctl_tty.2 | 10 ++---
man2/ioctl_userfaultfd.2 | 10 ++---
man2/msgctl.2 | 16 ++++----
man2/nanosleep.2 | 12 +++---
man2/prctl.2 | 84 +++++++++++++++++++-------------------
man2/ptrace.2 | 60 +++++++++++++--------------
man2/quotactl.2 | 34 +++++++--------
man2/reboot.2 | 19 +++++----
man2/semctl.2 | 22 +++++-----
man2/shmctl.2 | 20 +++++----
man3/lockf.3 | 11 ++---
21 files changed, 233 insertions(+), 225 deletions(-)
--
2.43.0
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next parent reply other threads:[~2024-03-03 12:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ZUIlirG-ypudgpbK@debian>
2024-03-03 12:15 ` Alejandro Colomar [this message]
2024-03-03 12:15 ` [PATCH 1/2] man*/: epoll_*(), fcntl(), flock(), ioctl(), msgctl(), *prctl(), ptrace(), quotactl(), reboot(), semctl(), shmctl(), lockf(): Consistently use 'op' and 'operation' Alejandro Colomar
2024-03-05 18:12 ` Alejandro Colomar
2024-03-05 19:19 ` enh
2024-03-03 12:15 ` [PATCH 2/2] clock_nanosleep.2, nanosleep.2: Use 'duration' rather than 'request' Alejandro Colomar
2024-03-03 12:45 ` Bruno Haible
2024-03-03 12:55 ` Alejandro Colomar
2024-03-03 13:02 ` [PATCH v2 2/2] " Alejandro Colomar
2024-03-05 0:18 ` [PATCH 2/2] clock_nanosleep.2, " enh
2024-03-05 0:34 ` Alejandro Colomar
2024-03-05 0:56 ` enh
2024-03-05 1:11 ` Alejandro Colomar
2024-03-05 22:22 ` enh
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=20240303121454.16994-1-alx@kernel.org \
--to=alx@kernel.org \
--cc=bruno@clisp.org \
--cc=enh@google.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=stefan.puiu@gmail.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: 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 read-only IMAP folder(s) and NNTP newsgroup(s).