From: Dan Williams <dan.j.williams@intel.com>
To: corbet@lwn.net
Cc: ksummit-discuss@lists.linuxfoundation.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
SeongJae Park <sjpark@amazon.de>,
linux-kernel@vger.kernel.org,
tech-board-discuss@lists.linuxfoundation.org,
Chris Mason <clm@fb.clm>, Dave Airlie <airlied@redhat.com>
Subject: [Ksummit-discuss] [PATCH v2] CodingStyle: Inclusive Terminology
Date: Wed, 08 Jul 2020 00:23:59 -0700 [thread overview]
Message-ID: <159419296487.2464622.863943877093636532.stgit@dwillia2-desk3.amr.corp.intel.com> (raw)
Linux maintains a coding-style and its own idiomatic set of terminology.
Update the style guidelines to recommend replacements for the terms
master/slave and blacklist/whitelist.
Link: http://lore.kernel.org/r/159389297140.2210796.13590142254668787525.stgit@dwillia2-desk3.amr.corp.intel.com
Cc: Jonathan Corbet <corbet@lwn.net>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Dave Airlie <airlied@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: SeongJae Park <sjpark@amazon.de>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Chris Mason <clm@fb.clm>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
Changes since v1 [1]
- Drop inclusive-terminology.rst, it is in the lore archives if the
arguments are needed for future debates, but otherwise no pressing
need to carry it in the tree (Linus, James)
- Update the recommended terms to include replacement for 'master' and
'whitelist' (Kees, Andy)
- Add 'target' as a replacement (Andy)
- Add 'device' as a replacement (Mark)
- Collect acks and signed-off-bys. Yes, the sign-offs are not reflective
of a submission chain, but I kept "Signed-off-by" if people offered
it.
- Non-change: I did not add explicit language as to what to do with
existing usages. My personal inclination is to prioritize this
coding-style cleanup higher than others, but the coding-style document
has typically not indicated policy on how cleanups are handled by
subsystems. It will be a case by case effort and consideration.
[1]: http://lore.kernel.org/r/159389297140.2210796.13590142254668787525.stgit@dwillia2-desk3.amr.corp.intel.com
Documentation/process/coding-style.rst | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
index 2657a55c6f12..a5b61e9005ac 100644
--- a/Documentation/process/coding-style.rst
+++ b/Documentation/process/coding-style.rst
@@ -319,6 +319,19 @@ If you are afraid to mix up your local variable names, you have another
problem, which is called the function-growth-hormone-imbalance syndrome.
See chapter 6 (Functions).
+For symbol names, avoid introducing new usage of 'master/slave' (or
+'slave' independent of 'master') and 'blacklist/whitelist'. Recommended
+replacements for 'master/slave' are: 'main/{secondary,subordinate}',
+'primary/replica', '{initiator,requester}/{target,responder}',
+'host/{device,proxy}', or 'leader/{performer,follower}'. Recommended
+replacements for 'blacklist/whitelist' are: 'denylist/allowlist' or
+'blocklist/passlist'.
+
+Exceptions for introducing new usage is to maintain a userspace ABI/API,
+or when updating code for an existing (as of 2020) hardware or protocol
+specification that mandates those terms. For new specifications
+translate specification usage of the terminology to the kernel coding
+standard where possible.
5) Typedefs
-----------
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams@intel.com>
To: corbet@lwn.net
Cc: Randy Dunlap <rdunlap@infradead.org>,
Dave Airlie <airlied@redhat.com>,
Kees Cook <keescook@chromium.org>,
SeongJae Park <sjpark@amazon.de>, Olof Johansson <olof@lixom.net>,
Chris Mason <clm@fb.clm>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
torvalds@linux-foundation.org,
tech-board-discuss@lists.linuxfoundation.org,
ksummit-discuss@lists.linuxfoundation.org,
linux-kernel@vger.kernel.org
Subject: [PATCH v2] CodingStyle: Inclusive Terminology
Date: Wed, 08 Jul 2020 00:23:59 -0700 [thread overview]
Message-ID: <159419296487.2464622.863943877093636532.stgit@dwillia2-desk3.amr.corp.intel.com> (raw)
Linux maintains a coding-style and its own idiomatic set of terminology.
Update the style guidelines to recommend replacements for the terms
master/slave and blacklist/whitelist.
Link: http://lore.kernel.org/r/159389297140.2210796.13590142254668787525.stgit@dwillia2-desk3.amr.corp.intel.com
Cc: Jonathan Corbet <corbet@lwn.net>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Dave Airlie <airlied@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: SeongJae Park <sjpark@amazon.de>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Chris Mason <clm@fb.clm>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
Changes since v1 [1]
- Drop inclusive-terminology.rst, it is in the lore archives if the
arguments are needed for future debates, but otherwise no pressing
need to carry it in the tree (Linus, James)
- Update the recommended terms to include replacement for 'master' and
'whitelist' (Kees, Andy)
- Add 'target' as a replacement (Andy)
- Add 'device' as a replacement (Mark)
- Collect acks and signed-off-bys. Yes, the sign-offs are not reflective
of a submission chain, but I kept "Signed-off-by" if people offered
it.
- Non-change: I did not add explicit language as to what to do with
existing usages. My personal inclination is to prioritize this
coding-style cleanup higher than others, but the coding-style document
has typically not indicated policy on how cleanups are handled by
subsystems. It will be a case by case effort and consideration.
[1]: http://lore.kernel.org/r/159389297140.2210796.13590142254668787525.stgit@dwillia2-desk3.amr.corp.intel.com
Documentation/process/coding-style.rst | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
index 2657a55c6f12..a5b61e9005ac 100644
--- a/Documentation/process/coding-style.rst
+++ b/Documentation/process/coding-style.rst
@@ -319,6 +319,19 @@ If you are afraid to mix up your local variable names, you have another
problem, which is called the function-growth-hormone-imbalance syndrome.
See chapter 6 (Functions).
+For symbol names, avoid introducing new usage of 'master/slave' (or
+'slave' independent of 'master') and 'blacklist/whitelist'. Recommended
+replacements for 'master/slave' are: 'main/{secondary,subordinate}',
+'primary/replica', '{initiator,requester}/{target,responder}',
+'host/{device,proxy}', or 'leader/{performer,follower}'. Recommended
+replacements for 'blacklist/whitelist' are: 'denylist/allowlist' or
+'blocklist/passlist'.
+
+Exceptions for introducing new usage is to maintain a userspace ABI/API,
+or when updating code for an existing (as of 2020) hardware or protocol
+specification that mandates those terms. For new specifications
+translate specification usage of the terminology to the kernel coding
+standard where possible.
5) Typedefs
-----------
WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams@intel.com>
To: corbet@lwn.net
Cc: ksummit-discuss@lists.linuxfoundation.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
SeongJae Park <sjpark@amazon.de>,
linux-kernel@vger.kernel.org,
tech-board-discuss@lists.linuxfoundation.org,
Chris Mason <clm@fb.clm>, Dave Airlie <airlied@redhat.com>,
torvalds@linux-foundation.org
Subject: [Tech-board-discuss] [PATCH v2] CodingStyle: Inclusive Terminology
Date: Wed, 08 Jul 2020 00:23:59 -0700 [thread overview]
Message-ID: <159419296487.2464622.863943877093636532.stgit@dwillia2-desk3.amr.corp.intel.com> (raw)
Linux maintains a coding-style and its own idiomatic set of terminology.
Update the style guidelines to recommend replacements for the terms
master/slave and blacklist/whitelist.
Link: http://lore.kernel.org/r/159389297140.2210796.13590142254668787525.stgit@dwillia2-desk3.amr.corp.intel.com
Cc: Jonathan Corbet <corbet@lwn.net>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Dave Airlie <airlied@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: SeongJae Park <sjpark@amazon.de>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Chris Mason <clm@fb.clm>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
Changes since v1 [1]
- Drop inclusive-terminology.rst, it is in the lore archives if the
arguments are needed for future debates, but otherwise no pressing
need to carry it in the tree (Linus, James)
- Update the recommended terms to include replacement for 'master' and
'whitelist' (Kees, Andy)
- Add 'target' as a replacement (Andy)
- Add 'device' as a replacement (Mark)
- Collect acks and signed-off-bys. Yes, the sign-offs are not reflective
of a submission chain, but I kept "Signed-off-by" if people offered
it.
- Non-change: I did not add explicit language as to what to do with
existing usages. My personal inclination is to prioritize this
coding-style cleanup higher than others, but the coding-style document
has typically not indicated policy on how cleanups are handled by
subsystems. It will be a case by case effort and consideration.
[1]: http://lore.kernel.org/r/159389297140.2210796.13590142254668787525.stgit@dwillia2-desk3.amr.corp.intel.com
Documentation/process/coding-style.rst | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
index 2657a55c6f12..a5b61e9005ac 100644
--- a/Documentation/process/coding-style.rst
+++ b/Documentation/process/coding-style.rst
@@ -319,6 +319,19 @@ If you are afraid to mix up your local variable names, you have another
problem, which is called the function-growth-hormone-imbalance syndrome.
See chapter 6 (Functions).
+For symbol names, avoid introducing new usage of 'master/slave' (or
+'slave' independent of 'master') and 'blacklist/whitelist'. Recommended
+replacements for 'master/slave' are: 'main/{secondary,subordinate}',
+'primary/replica', '{initiator,requester}/{target,responder}',
+'host/{device,proxy}', or 'leader/{performer,follower}'. Recommended
+replacements for 'blacklist/whitelist' are: 'denylist/allowlist' or
+'blocklist/passlist'.
+
+Exceptions for introducing new usage is to maintain a userspace ABI/API,
+or when updating code for an existing (as of 2020) hardware or protocol
+specification that mandates those terms. For new specifications
+translate specification usage of the terminology to the kernel coding
+standard where possible.
5) Typedefs
-----------
next reply other threads:[~2020-07-08 7:40 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-08 7:23 Dan Williams [this message]
2020-07-08 7:23 ` [Tech-board-discuss] [PATCH v2] CodingStyle: Inclusive Terminology Dan Williams
2020-07-08 7:23 ` Dan Williams
2020-07-08 7:52 ` [Ksummit-discuss] " Dan Williams
2020-07-08 7:52 ` [Tech-board-discuss] " Dan Williams
2020-07-08 7:52 ` Dan Williams
2020-07-08 8:22 ` [Ksummit-discuss] " Kees Cook
2020-07-08 8:22 ` [Tech-board-discuss] " Kees Cook
2020-07-08 8:22 ` Kees Cook
2020-07-08 14:43 ` [Ksummit-discuss] " Dan Williams
2020-07-08 14:43 ` [Tech-board-discuss] " Dan Williams
2020-07-08 14:43 ` Dan Williams
2020-07-08 9:30 ` [Ksummit-discuss] [Tech-board-discuss] " Mark Brown
2020-07-08 9:30 ` Mark Brown
2020-07-08 9:30 ` Mark Brown
2020-07-08 10:07 ` [Ksummit-discuss] " Dan Carpenter
2020-07-08 10:07 ` [Tech-board-discuss] " Dan Carpenter
2020-07-08 10:07 ` Dan Carpenter
2020-07-08 11:04 ` Joe Perches
2020-07-08 11:04 ` [Tech-board-discuss] " Joe Perches
2020-07-08 11:04 ` Joe Perches
2020-07-08 15:14 ` [Ksummit-discuss] " Dan Williams
2020-07-08 15:14 ` [Tech-board-discuss] " Dan Williams
2020-07-08 15:14 ` Dan Williams
2020-07-08 15:59 ` [Ksummit-discuss] [Tech-board-discuss] " James Bottomley
2020-07-08 15:59 ` James Bottomley
2020-07-08 14:22 ` [Ksummit-discuss] " tytso
2020-07-08 14:22 ` [Tech-board-discuss] " tytso
2020-07-08 14:22 ` tytso
2020-07-08 16:23 ` [Ksummit-discuss] " Christian Brauner
2020-07-08 16:23 ` [Tech-board-discuss] " Christian Brauner
2020-07-08 16:23 ` Christian Brauner
2020-07-08 16:42 ` [Ksummit-discuss] [Tech-board-discuss] " Shuah Khan
2020-07-08 16:42 ` Shuah Khan
2020-07-08 16:42 ` Shuah Khan
2020-07-08 18:59 ` [Ksummit-discuss] " Stephen Hemminger
2020-07-08 18:59 ` [Tech-board-discuss] " Stephen Hemminger
2020-07-08 18:59 ` Stephen Hemminger
2020-07-10 16:02 ` Linus Walleij
2020-07-10 16:02 ` [Tech-board-discuss] " Linus Walleij
2020-07-10 16:02 ` Linus Walleij
2020-07-10 16:13 ` [Ksummit-discuss] " Dan Williams
2020-07-10 16:13 ` [Tech-board-discuss] " Dan Williams
2020-07-10 16:13 ` Dan Williams
2020-07-11 13:30 ` [Ksummit-discuss] " Pavel Machek
2020-07-11 13:30 ` [Tech-board-discuss] " Pavel Machek
2020-07-11 13:30 ` Pavel Machek
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=159419296487.2464622.863943877093636532.stgit@dwillia2-desk3.amr.corp.intel.com \
--to=dan.j.williams@intel.com \
--cc=airlied@redhat.com \
--cc=clm@fb.clm \
--cc=corbet@lwn.net \
--cc=gregkh@linuxfoundation.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sjpark@amazon.de \
--cc=tech-board-discuss@lists.linuxfoundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.