ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy6545@gmail.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: ksummit <ksummit-discuss@lists.linuxfoundation.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org,
	tech-board-discuss@lists.linuxfoundation.org,
	Chris Mason <clm@fb.clm>
Subject: Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology
Date: Sat, 4 Jul 2020 20:12:21 -0400	[thread overview]
Message-ID: <CAFhKne_ZVWVhZX5hNEbeGBfU6BMRN9JKQeTsVYOcMmEH1cd3xg@mail.gmail.com> (raw)
In-Reply-To: <159389297140.2210796.13590142254668787525.stgit@dwillia2-desk3.amr.corp.intel.com>


[-- Attachment #1.1: Type: text/plain, Size: 6531 bytes --]

Another suggestion for "slave" replacement should be "device". This is in
the context of the w1 bus which is by far the largest user of the
master/slave terminology in the kernel.

On Sat., Jul. 4, 2020, 16:19 Dan Williams, <dan.j.williams@intel.com> wrote:

> 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 <corbet@lwn.net>
> Cc: Kees Cook <keescook@chromium.org>
> 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>
> ---
>  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
> +<inclusiveterminology>` for details.
>
>  5) Typedefs
>  -----------
> diff --git a/Documentation/process/inclusive-terminology.rst
> b/Documentation/process/inclusive-terminology.rst
> new file mode 100644
> index 000000000000..a8eb26690eb4
> --- /dev/null
> +++ b/Documentation/process/inclusive-terminology.rst
> @@ -0,0 +1,64 @@
> +.. _inclusiveterminology:
> +
> +Linux kernel inclusive terminology
> +==================================
> +
> +The Linux kernel is a global software project, and in 2020 there was a
> +global reckoning on race relations that caused many organizations to
> +re-evaluate their policies and practices relative to the inclusion of
> +people of African descent. This document describes why the 'Naming'
> +section in :ref:`process/coding-style.rst <codingstyle>` recommends
> +avoiding usage of 'slave' and 'blacklist' in new additions to the Linux
> +kernel.
> +
> +On the triviality of replacing words
> +====================================
> +
> +The African slave trade was a brutal system of human misery deployed at
> +global scale. Some word choice decisions in a modern software project
> +does next to nothing to compensate for that legacy. So why put any
> +effort into something so trivial in comparison? Because the goal is not
> +to repair, or erase the past. The goal is to maximize availability and
> +efficiency of the global developer community to participate in the Linux
> +kernel development process.
> +
> +Word choice and developer efficiency
> +====================================
> +
> +Why does any software project go through the trouble of developing a
> +document like :ref:`process/coding-style.rst <codingstyle>`? It does so
> +because a common coding style maximizes the efficiency of both
> +maintainers and developers. Developers learn common design patterns and
> +idiomatic expressions while maintainers can spot deviations from those
> +norms. Even non-compliant whitespace is considered a leading indicator
> +to deeper problems in a patchset. Coding style violations are known to
> +take a maintainer "out of the zone" of reviewing code. Maintainers are
> +also sensitive to word choice across specifications and often choose to
> +deploy Linux terminology to replace non-idiomatic word-choice in a
> +specification.
> +
> +Non-inclusive terminology has that same distracting effect which is why
> +it is a style issue for Linux, it injures developer efficiency.
> +
> +Of course it is around this point someone jumps in with an etymological
> +argument about why people should not be offended. Etymological arguments
> +do not scale. The scope and pace of Linux to reach new developers
> +exceeds the ability of historical terminology defenders to describe "no,
> +not that connotation". The revelation of 2020 was that black voices were
> +heard on a global scale and the Linux kernel project has done its small
> +part to answer that call as it wants black voices, among all voices, in
> +its developer community.
> +
> +Really, 'blacklist' too?
> +========================
> +
> +While 'slave' has a direct connection to human suffering the etymology
> +of 'blacklist' is devoid of a historical racial connection. However, one
> +thought exercise is to consider replacing 'blacklist/whitelist' with
> +'redlist/greenlist'. Realize that the replacement only makes sense if
> +you have been socialized with the concepts that 'red/green' implies
> +'stop/go'. Colors to represent a policy requires an indirection. The
> +socialization of 'black/white' to have the connotation of
> +'impermissible/permissible' does not support inclusion.
> +
> +Inclusion == global developer community efficiency.
> diff --git a/Documentation/process/index.rst
> b/Documentation/process/index.rst
> index f07c9250c3ac..ed861f6f8d25 100644
> --- a/Documentation/process/index.rst
> +++ b/Documentation/process/index.rst
> @@ -27,6 +27,7 @@ Below are the essential guides that every developer
> should read.
>     submitting-patches
>     programming-language
>     coding-style
> +   inclusive-terminology
>     maintainer-pgp-guide
>     email-clients
>     kernel-enforcement-statement
>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>

[-- Attachment #1.2: Type: text/html, Size: 8020 bytes --]

[-- Attachment #2: Type: text/plain, Size: 186 bytes --]

_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

  parent reply	other threads:[~2020-07-05  0:12 UTC|newest]

Thread overview: 90+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-04 20:02 [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology Dan Williams
2020-07-04 20:31 ` Randy Dunlap
2020-07-04 23:41   ` Dave Airlie
2020-07-05  0:10     ` Matthew Wilcox
2020-07-05  1:10       ` [Ksummit-discuss] [Tech-board-discuss] " Kees Cook
2020-07-05  2:44         ` Randy Dunlap
2020-07-06 11:15         ` Michael Kerrisk (man-pages)
2020-07-06 15:53           ` Kees Cook
2020-07-05  2:54       ` [Ksummit-discuss] " Dave Airlie
2020-07-04 20:44 ` Stephen Rothwell
2020-07-04 23:34   ` Dave Airlie
2020-07-05  2:12     ` Stephen Rothwell
2020-07-05  2:56       ` Dave Airlie
2020-07-05  3:23         ` James Bottomley
2020-07-05  3:26         ` Stephen Rothwell
2020-07-04 21:14 ` Olof Johansson
2020-07-04 21:25 ` [Ksummit-discuss] [Tech-board-discuss] " James Bottomley
2020-07-04 21:51   ` Joe Perches
2020-07-04 23:39   ` Dave Airlie
2020-07-05  0:08     ` Joe Perches
2020-07-05  1:32     ` Kees Cook
2020-07-05 17:50     ` opal hart
2020-07-04 23:42 ` [Ksummit-discuss] " Dave Airlie
2020-07-05  0:12 ` Matthew Wilcox [this message]
2020-07-06  7:06   ` NeilBrown
2020-07-06  7:10   ` NeilBrown
2020-07-06  7:22     ` Greg Kroah-Hartman
2020-07-06  7:53       ` Geert Uytterhoeven
2020-07-06 10:22         ` Greg Kroah-Hartman
2020-07-06 12:51         ` Matthew Wilcox
2020-07-06 12:59           ` Joe Perches
2020-07-06 13:04             ` Matthew Wilcox
2020-07-06 13:30               ` Joe Perches
2020-07-09 11:11                 ` Mauro Carvalho Chehab
2020-07-13  4:25                   ` Vinod Koul
2020-07-13 15:55                     ` Dan Williams
2020-07-05  0:41 ` Kees Cook
2020-07-07  4:30   ` Dan Williams
2020-07-10 16:52     ` Andy Lutomirski
2020-07-05  4:55 ` Willy Tarreau
2020-07-06  3:13   ` Daniel Palmer
2020-07-06 12:45   ` Chris Mason via Ksummit-discuss
2020-07-06 14:06     ` Laurent Pinchart
2020-07-06 15:55       ` Chris Mason via Ksummit-discuss
2020-07-06 16:06     ` Mike Rapoport
2020-07-07  4:17       ` Dan Williams
2020-07-06 15:22   ` Arvind Sankar
2020-07-06 15:40     ` [Ksummit-discuss] [Tech-board-discuss] " Steven Rostedt
2020-07-06 13:23 ` [Ksummit-discuss] " Tibor Raschko
2020-07-06 16:29 ` Andy Lutomirski
2020-07-07  4:00   ` Dan Williams
2020-07-07  5:56   ` Kees Cook
2020-07-07  6:49     ` Mike Rapoport
2020-07-07 13:37       ` [Ksummit-discuss] [Tech-board-discuss] " Steven Rostedt
2020-07-07 15:24         ` Bird, Tim
2020-07-07 15:33           ` Randy Dunlap
2020-07-07 15:41             ` Steven Rostedt
2020-07-07 15:55               ` Bird, Tim
2020-07-07  6:56     ` [Ksummit-discuss] " Harrosh, Boaz
2020-07-07  8:54       ` Kees Cook
2020-07-07 13:41         ` [Ksummit-discuss] [Tech-board-discuss] " Steven Rostedt
2020-07-07 14:45           ` Mike Rapoport
2020-07-07 20:56             ` Kees Cook
2020-07-07 21:48         ` [Ksummit-discuss] " Arvind Sankar
2020-07-07 12:13       ` Mark Brown
2020-07-06 18:30 ` [Ksummit-discuss] [Tech-board-discuss] " Shuah Khan
2020-07-06 23:58   ` Tibor Raschko
     [not found]     ` <20200709124327.369781a0@coco.lan>
2020-07-09 16:01       ` Shuah Khan
2020-07-09 16:13         ` Mark Brown
2020-07-09 16:32           ` James Bottomley
2020-07-09 16:35           ` Steven Rostedt
2020-07-07  4:04   ` Dan Williams
2020-07-06 19:15 ` Mark Brown
2020-07-07  0:48   ` Tibor Raschko
2020-07-07 21:26     ` Arvind Sankar
2020-07-07 23:54       ` Tibor Raschko
2020-07-07  4:08   ` Dan Williams
2020-07-07  9:36     ` Mark Brown
2020-07-06 21:31 ` [Ksummit-discuss] " Pavel Begunkov
2020-07-06 22:10   ` [Ksummit-discuss] [Tech-board-discuss] " Steven Rostedt
2020-07-06 22:17     ` Pavel Begunkov
2020-07-06 22:28       ` Steven Rostedt
2020-07-06 23:03         ` Pavel Begunkov
2020-07-08  3:42           ` Stephen Hemminger
2020-07-07  6:56 ` [Ksummit-discuss] " SeongJae Park via Ksummit-discuss
2020-07-08  7:12   ` Dan Williams
2020-07-08  9:28     ` SeongJae Park via Ksummit-discuss
2020-07-07  7:51 ` Christian Brauner
2020-07-17  8:35 ` Pavel Machek
2020-07-26 15:30 ` Laurent Pinchart

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=CAFhKne_ZVWVhZX5hNEbeGBfU6BMRN9JKQeTsVYOcMmEH1cd3xg@mail.gmail.com \
    --to=willy6545@gmail.com \
    --cc=clm@fb.clm \
    --cc=dan.j.williams@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 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 NNTP newsgroup(s).