many brave. such powerful. so wow

[activedecay]

Subject [PATCH] CodingStyle: Inclusive Terminology
From Dan Williams <>
Date Sat, 04 Jul 2020 13:02:51 -0700
share

Recent events have prompted a Linux position statement on inclusive
terminology. Given that Linux maintains a coding-style and its own
idiomatic set of terminology here is a proposal to answer the call to
replace non-inclusive terminology.

Cc: Jonathan Corbet
Cc: Kees Cook
Signed-off-by: Chris Mason
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Dan Williams

Documentation/process/coding-style.rst | 12 ++++
Documentation/process/inclusive-terminology.rst | 64 +++++++++++++++++++++++
Documentation/process/index.rst | 1
3 files changed, 77 insertions(+)
create mode 100644 Documentation/process/inclusive-terminology.rst

diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
index 2657a55c6f12..4b15ab671089 100644
--- a/Documentation/process/coding-style.rst
+++ b/Documentation/process/coding-style.rst
@@ -319,6 +319,18 @@ 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 the words 'slave' and
+'blacklist'. Recommended replacements for 'slave' are: 'secondary',
+'subordinate', 'replica', 'responder', 'follower', 'proxy', or
+'performer'. Recommended replacements for blacklist are: 'blocklist' or
+'denylist'.
+
+Exceptions for introducing new usage is to maintain a userspace ABI, or
+when updating code for an existing (as of 2020) hardware or protocol
+specification that mandates those terms. For new specifications consider
+translating specification usage of the terminology to the kernel coding
+standard where possible. See :ref:process/inclusive-terminology.rst + for details.

[socram8888]

Wildfires in Australia, Hong Kong protests, Coronavirus all over the world, and now this. What a wonderful year to be alive.