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.