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 <[email protected]>
Cc: Kees Cook <[email protected]>
Signed-off-by: Chris Mason <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
---
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
On 7/4/20 1:02 PM, Dan Williams 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 <[email protected]>
> Cc: Kees Cook <[email protected]>
> Signed-off-by: Chris Mason <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Dan Williams <[email protected]>
> ---
> 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/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
do next to nothing
> +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
word choice
> +specification.
> +
> +Non-inclusive terminology has that same distracting effect which is why
> +it is a style issue for Linux, it injures developer efficiency.
for Linux:
> +
> +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
how about:
Using colors to represent a policy requires an indirection.
> +socialization of 'black/white' to have the connotation of
> +'impermissible/permissible' does not support inclusion.
> +
> +Inclusion == global developer community efficiency.
Acked-by: Randy Dunlap <[email protected]>
thanks.
--
~Randy
Hi Dan,
On Sat, 04 Jul 2020 13:02:51 -0700 Dan Williams <[email protected]> wrote:
>
> +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'
I feel a need to point out that racial issues are wider than just
people of African descent ... Also, others have pointed out that
slavery is not just restricted to those of African descent.
--
Cheers,
Stephen Rothwell
On Sat, Jul 4, 2020 at 1:19 PM Dan Williams <[email protected]> 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 <[email protected]>
> Cc: Kees Cook <[email protected]>
> Signed-off-by: Chris Mason <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Dan Williams <[email protected]>
I'm happy to support this, I agree with the general approach as well
as the motivations thereof.
At your discretion, feel free to add:
Signed-off-by: Olof Johansson <[email protected]>
Or Acked-by, or whatever other label you prefer to use to show
agreement and support.
-Olof
On Sat, 2020-07-04 at 13:02 -0700, Dan Williams wrote:
[...]
> 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
Could we just lose this entire document? The one thing we should learn
from recent history is that we really want prevent people distracting
from the good inclusive (and technically more accurate) terminology
will do. One way the detractors do this by engaging in ultimately
pointless arguments about historical accuracy of supporting statements.
By making pejorative statements about history (which are open to
challenge on several fronts), this document acts as a magnet for such
attention. Simply leave it out and the detractors will have nothing to
attack except the bald statement of desiring more inclusive language.
I'd much rather defend why we want inclusive and more descriptive
language than get into a pointless argument over whether the Ottoman
slave trade was more or less evil than the American one.
James
On 2020-07-04 14:25, James Bottomley wrote:
> On Sat, 2020-07-04 at 13:02 -0700, Dan Williams wrote:
> [...]
>> diff --git a/Documentation/process/inclusive-terminology.rst
[]
> Could we just lose this entire document?
Yes please.
On Sun, 5 Jul 2020 at 06:45, Stephen Rothwell <[email protected]> wrote:
>
> Hi Dan,
>
> On Sat, 04 Jul 2020 13:02:51 -0700 Dan Williams <[email protected]> wrote:
> >
> > +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'
>
> I feel a need to point out that racial issues are wider than just
> people of African descent ... Also, others have pointed out that
> slavery is not just restricted to those of African descent.
The racial issues are wider than that, and even wider again I'm sure,
but in 2020 this is as good a place to start as any, and the trigger
as that sentence says was in 2020, there was a reckoning about it
mainly due to people of African descent. That trigger has had flow on
effects in other countries, but I'm not sure that sentence in any way
diminishes that, it's merely an introduction to why this change is
happening now.
As for the non-black slavery, others have never pointed this out
before in 30 years of master/slave terminology? surely if white
slavery was as big a problem, they be as supportive of this, even more
so. It speaks volumes that I've never heard white slavery as a problem
once in 30 years, but now I'm hearing about it a few times, and
somehow as an excuse not to support this.
Dave.
On Sun, 5 Jul 2020 at 07:25, James Bottomley
<[email protected]> wrote:
>
> On Sat, 2020-07-04 at 13:02 -0700, Dan Williams wrote:
> [...]
> > 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
>
> Could we just lose this entire document? The one thing we should learn
> from recent history is that we really want prevent people distracting
> from the good inclusive (and technically more accurate) terminology
> will do. One way the detractors do this by engaging in ultimately
> pointless arguments about historical accuracy of supporting statements.
> By making pejorative statements about history (which are open to
> challenge on several fronts), this document acts as a magnet for such
> attention. Simply leave it out and the detractors will have nothing to
> attack except the bald statement of desiring more inclusive language.
> I'd much rather defend why we want inclusive and more descriptive
> language than get into a pointless argument over whether the Ottoman
> slave trade was more or less evil than the American one.
I don't totally agree on that, because like the CoC discussion, people
need concrete examples. People need reasons, saying simply "be
inclusive" doesn't work.
You say "be inclusive" people don't think about it, they just go "I'm
inclusive" and proceed, never questioning what it means to be
inclusive, they normalise inclusivity to their self image and within
their lives where they might never confront anything like this.
I don't doubt we get the American/Ottoman/Barbery coast people and the
correct answer to those people is to tell them to examine why they
suddenly care about Barbery slavery now when they have never even
heard or worried about it before. Why haven't they submitted patches
removing slavery terminology from the kernel before?
Dave.
'. Colors to represent a policy requires an indirection. The
>
> how about:
> Using colors to represent a policy requires an indirection.
I'd totally submit that red/black trees while in no way racist, are a
horrible indirection, as it means nothing if you've never interacted
with gambling culture, (and maybe James Bond movies).
left/right trees make naturally more sense and translate into more
languages, so yes I think removal of color naming is a good thing even
for non-racist reasonings.
Dave.
On Sun, 5 Jul 2020 at 06:19, Dan Williams <[email protected]> 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 <[email protected]>
> Cc: Kees Cook <[email protected]>
> Signed-off-by: Chris Mason <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Dan Williams <[email protected]>
I'm sure the language could be fine tuned, but the intent is something
I support.
Acked-by: Dave Airlie <[email protected]>
> ---
> 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
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
On Sun, 2020-07-05 at 09:39 +1000, Dave Airlie wrote:
> Why haven't they submitted patches
> removing slavery terminology from the kernel before?
Because inhuman devices in a master/slave hierarchy isn't
anything like chattel slavery?
Blacklist/whitelist has nothing to do with skin color?
Are red-black trees next?
On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams 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 <[email protected]>
> Cc: Kees Cook <[email protected]>
> Signed-off-by: Chris Mason <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Dan Williams <[email protected]>
(nit: isn't this a Co-developed-by chain, not a SoB chain?)
Acked-by: Kees Cook <[email protected]>
Comments below...
> ---
> 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'.
Keeping "master" in a "master/slave" pairing (i.e. replacing only
"slave") seems incomplete to me. If "master" is paired with "slave", it
should be replaced too. Potential examples: 'primary', 'leader', 'principle',
'controller', 'sender', 'initial'.
Similarly, for "whitelist/blacklist", "whitelist" needs to replaced when
"blacklist" has been. For example, seccomp documentation[1] uses
"allow-list" and "deny-list".
[1] https://man7.org/linux/man-pages/man2/seccomp.2.html
> +Exceptions for introducing new usage is to maintain a userspace ABI, or
and API?
> +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.
Let's add:
Where possible, old instances of this language should be replaced when
it is not tied to external specifications nor userspace ABI/API.
>
> 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.
... usage of 'master/slave', 'slave', 'whitelist/blacklist', and
'blacklist' in 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.
Let's add:
Beyond just Linux
=================
For those of us in the kernel community involved in specification
development or similar larger ecosystem conversations, please help
steer those discussions to avoid these terms in new specifications
or APIs.
> 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
>
--
Kees Cook
On Sun, Jul 05, 2020 at 09:39:29AM +1000, Dave Airlie wrote:
> I don't totally agree on that, because like the CoC discussion, people
> need concrete examples. People need reasons, saying simply "be
> inclusive" doesn't work.
>
> You say "be inclusive" people don't think about it, they just go "I'm
> inclusive" and proceed, never questioning what it means to be
> inclusive, they normalise inclusivity to their self image and within
> their lives where they might never confront anything like this.
>
> I don't doubt we get the American/Ottoman/Barbery coast people and the
> correct answer to those people is to tell them to examine why they
> suddenly care about Barbery slavery now when they have never even
> heard or worried about it before. Why haven't they submitted patches
> removing slavery terminology from the kernel before?
Right; this part of the patch provides a temporal explanation for "but
why now?" and acts as an internal reference, instead of pointing to
external[1] sources, which lack the Linux-specific contextualization.
Additionally, I think it provides rebuttals to many of the specious
arguments against inclusive terminology (and it could perhaps gain
more, as we've already seen in this thread, against slippery slope
arguments). It also attempts to acknowledge what this change in the
kernel processes provides to the world in general: it's a fairly local
change to make our development community less disruptive to those that
would seek to join it -- it does not, and cannot, solve global racism
(though that would be nice).
[1] https://tools.ietf.org/id/draft-knodel-terminology-01.html
--
Kees Cook
Hi Dave,
On Sun, 5 Jul 2020 09:34:57 +1000 Dave Airlie <[email protected]> wrote:
>
> On Sun, 5 Jul 2020 at 06:45, Stephen Rothwell <[email protected]> wrote:
> >
> > On Sat, 04 Jul 2020 13:02:51 -0700 Dan Williams <[email protected]> wrote:
> > >
> > > +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'
> >
> > I feel a need to point out that racial issues are wider than just
> > people of African descent ... Also, others have pointed out that
> > slavery is not just restricted to those of African descent.
>
> The racial issues are wider than that, and even wider again I'm sure,
> but in 2020 this is as good a place to start as any, and the trigger
> as that sentence says was in 2020, there was a reckoning about it
> mainly due to people of African descent. That trigger has had flow on
> effects in other countries, but I'm not sure that sentence in any way
> diminishes that, it's merely an introduction to why this change is
> happening now.
And reading it again in the (actual) light of day, I see you are right
and I misinterpreted this.
> As for the non-black slavery, others have never pointed this out
(I did not say "non-black")
> before in 30 years of master/slave terminology? surely if white
> slavery was as big a problem, they be as supportive of this, even more
(nor did I say "white slavery")
> so. It speaks volumes that I've never heard white slavery as a problem
> once in 30 years, but now I'm hearing about it a few times, and
> somehow as an excuse not to support this.
I was merely referring to some of the posts in the
[email protected] mailing list. Also, I made no statement about
my support (or otherwise) for any of this.
--
Cheers,
Stephen Rothwell
On Sun, 5 Jul 2020 at 12:12, Stephen Rothwell <[email protected]> wrote:
>
> Hi Dave,
>
> On Sun, 5 Jul 2020 09:34:57 +1000 Dave Airlie <[email protected]> wrote:
> >
> > On Sun, 5 Jul 2020 at 06:45, Stephen Rothwell <[email protected]> wrote:
> > >
> > > On Sat, 04 Jul 2020 13:02:51 -0700 Dan Williams <[email protected]> wrote:
> > > >
> > > > +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'
> > >
> > > I feel a need to point out that racial issues are wider than just
> > > people of African descent ... Also, others have pointed out that
> > > slavery is not just restricted to those of African descent.
> >
> > The racial issues are wider than that, and even wider again I'm sure,
> > but in 2020 this is as good a place to start as any, and the trigger
> > as that sentence says was in 2020, there was a reckoning about it
> > mainly due to people of African descent. That trigger has had flow on
> > effects in other countries, but I'm not sure that sentence in any way
> > diminishes that, it's merely an introduction to why this change is
> > happening now.
>
> And reading it again in the (actual) light of day, I see you are right
> and I misinterpreted this.
>
> > As for the non-black slavery, others have never pointed this out
>
> (I did not say "non-black")
>
Sorry I misdirected what you said a bit, and I did misinterpret as
Australia also has it's own indigenous slavery issues,
I was trying to stop the "white slavery" is a thing crew from turning
up on this.
Apologies for accidentally implying something what you hadn't said.
Dave.
On Sun, 2020-07-05 at 12:56 +1000, Dave Airlie wrote:
> On Sun, 5 Jul 2020 at 12:12, Stephen Rothwell <[email protected]>
> wrote:
[...]
> > > As for the non-black slavery, others have never pointed this out
> >
> > (I did not say "non-black")
> >
>
> Sorry I misdirected what you said a bit, and I did misinterpret as
> Australia also has it's own indigenous slavery issues,
>
> I was trying to stop the "white slavery" is a thing crew from turning
> up on this.
>
> Apologies for accidentally implying something what you hadn't said.
Not at all, thank you; you just gave a precise illustration of my
point: putting statements like this in the kernel acts as a magnet for
this type of disagreement ... and not just from honourable people.
Developers can honestly disagree about this sort of thing, while
supporting the aim of using inclusive language. That's why this file
shouldn't be in the kernel tree.
James
Hi Dave,
On Sun, 5 Jul 2020 12:56:23 +1000 Dave Airlie <[email protected]> wrote:
>
> Sorry I misdirected what you said a bit, and I did misinterpret as
> Australia also has it's own indigenous slavery issues,
(and non-indigenous :-()
> I was trying to stop the "white slavery" is a thing crew from turning
> up on this.
>
> Apologies for accidentally implying something what you hadn't said.
Sure
No worries, mate :-)
--
Cheers,
Stephen Rothwell
On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams wrote:
> +Non-inclusive terminology has that same distracting effect which is why
> +it is a style issue for Linux, it injures developer efficiency.
I'm personally thinking that for a non-native speaker it's already
difficult to find the best term to describe something, but having to
apply an extra level of filtering on the found words to figure whether
they are allowed by the language police is even more difficult. *This*
injures developers efficiency. What could improve developers efficiency
is to take care of removing *all* idiomatic or cultural words then. For
example I've been participating to projects using the term "blueprint",
I didn't understand what that meant. It was once explained to me and
given that it had no logical reason for being called this way, I now
forgot. If we follow your reasoning, Such words should be banned for
exactly the same reasons. Same for colors that probably don't mean
anything to those born blind.
For example if in my local culture we eat tomatoes at starters and
apples for dessert, it could be convenient for me to use "tomato" and
"apple" as list elements to name the pointers leading to the beginning
and the end of the list, and it might sound obvious to many people, but
not at all for many others.
Maybe instead of providing an explicit list of a few words it should
simply say that terms that take their roots in the non-technical world
and whose meaning can only be understood based on history or local
culture ought to be avoided, because *that* actually is the real
root cause of the problem you're trying to address.
Willy
On Sun, 5 Jul 2020 09:39:29 +1000
Dave Airlie <[email protected]> wrote:
> I don't totally agree on that, because like the CoC discussion, people
> need concrete examples. People need reasons, saying simply "be
> inclusive" doesn't work.
Which people? because so far the only people I've seen take these
terminologies out of computing context, are those who are only voicing
their "concern" out of bad faith, as well as those who fall for the
concern-trolling bait. The meta-discussion serves to stir up noise and
waste time that's better spent on other things.
History pains, sure, but I believe it serves no justice to erase every
trace of bad things that happened in history. That includes use of
words tangentially related to such events.
--
wowaname <https://wowana.me/pgp.xht>
Hi Willy,
On Sun, 5 Jul 2020 at 13:55, Willy Tarreau <[email protected]> wrote:
> I'm personally thinking that for a non-native speaker it's already
> difficult to find the best term to describe something,
I'm a nobody in the kernel world but this point made me think.
I'm a native English speaker but I don't live in an English speaking
place and my experience is that a lot of technology terms have been
directly imported from English into the local language almost as-is.
In my case master/slave have been directly transliterated into
Japanese as masuta and sureebu and exists like that in technical
documentation for example:
https://www.analog.com/jp/analog-dialogue/articles/introduction-to-spi-interface.html#
I can imagine that by changing terminology that has been in use for so
long that it's been imported into other languages directly or is
common enough that non-native speakers know what it means might have
exactly the opposite result by excluding people that aren't native
English speakers and can't decode synonyms that are obvious to a
native speaker.
Cheers,
Daniel
Hi guys,
do you think playing with words will really get you anywhere
or help anyone?
> +On the triviality of replacing words
You're not going to make white black, make a native African
white, or fix age-old crimes by this "triviality".
You're only going to sort of please those who actually
hate you -- and everyone creative -- because they envy.
Or rather subdue to their twisted will (what's next on
the list, cannibalism aproval extorted from you?).
Have you seen this post by a teacher?
https://www.reddit.com/r/TrueOffMyChest/comments/gulna2/i_used_to_teach_in_a_black_inner_city_school/
Do you believe that a typical late-USSRish quota system
for those who do not want to learn will help them learn?
I'd rather start with helping those who DO want to learn
by protecting them from their disruptive environment that
pulls them back into morass.
That whole "inclusivity" agenda is extremely toxic and
hypocritical -- this king is so naked that it takes a late
Soviet-style propaganda and party-bashing to make people
shut up and not even confess that a black criminal's life
might only be an excuse and not the reason to murder and
pillage zounds of other people of any skin color -- with
only some black people daring to point out that the said
criminal was once threating a pregnant black woman with
his gun aimed at her baby not yet even born, for example.
That orwellish "inclusivity" that excludes on intent,
ill-meaning "goodwill", silencing "free speech" is what
seems to be going to bury the country where many of you
work and live.
I wouldn't say I wish USA good health and good luck --
it is the country that ruined USSR on intent and that
ruined former Ukraine on intent (I used to live in Kiev
since early 1980s up till 2014 when USA-made nazi coup
destroyed the country). But I should at least warn you
that you're playing with demon core, not even with fire;
you're rushing to support moral rapists when you could
at least stay where you are.
I write that as a person made in USSR back in 1979,
just in case. It was still Russia, but I remember
those kitchen talks that are no more needed. And I
remember a "why do you learn?" question back in 1993.
You can argue and call me an intolerant liar, welcome.
Time will tell and you have no power over it, comrades.
PS: those who find this kind of abuse unacceptable
are welcome to Russia if they fail to protect their
homeland -- we've learned it all too well already,
so we *do* value our freedom -- and stand by it.
Look for Innopolis.
PPS: James, kudos to you! Prepare for your share
of "democratic shelling" though. Hope you stand.
--
?---- WBR, Michael Shigorin / http://altlinux.org
??------ http://opennet.ru / http://anna-news.info
On 5 Jul 2020, at 0:55, Willy Tarreau wrote:
> On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams wrote:
>> +Non-inclusive terminology has that same distracting effect which is
>> why
>> +it is a style issue for Linux, it injures developer efficiency.
>
> I'm personally thinking that for a non-native speaker it's already
> difficult to find the best term to describe something, but having to
> apply an extra level of filtering on the found words to figure whether
> they are allowed by the language police is even more difficult.
Since our discussions are public, we?ve always had to deal with
comments from people outside the community on a range of topics. But
inside the kernel, it?s just a group of developers trying to help each
other produce the best quality of code. We?ve got a long history
together and in general I think we?re pretty good at assuming good
intent.
> *This*
> injures developers efficiency. What could improve developers
> efficiency
> is to take care of removing *all* idiomatic or cultural words then.
> For
> example I've been participating to projects using the term
> "blueprint",
> I didn't understand what that meant. It was once explained to me and
> given that it had no logical reason for being called this way, I now
> forgot. If we follow your reasoning, Such words should be banned for
> exactly the same reasons. Same for colors that probably don't mean
> anything to those born blind.
>
> For example if in my local culture we eat tomatoes at starters and
> apples for dessert, it could be convenient for me to use "tomato" and
> "apple" as list elements to name the pointers leading to the beginning
> and the end of the list, and it might sound obvious to many people,
> but
> not at all for many others.
>
> Maybe instead of providing an explicit list of a few words it should
> simply say that terms that take their roots in the non-technical world
> and whose meaning can only be understood based on history or local
> culture ought to be avoided, because *that* actually is the real
> root cause of the problem you're trying to address.
I?d definitely agree that it?s a good goal to keep out non-technical
terms. Even though we already try, every subsystem has its own set of
patterns that reflect the most frequent contributors.
-chris
Sending the wrong message
===========================
I'm pretty sure everybody agrees that being inclusive is more than just
using the right words. Being truly inclusive means not caring about the
origin, birth, age, sex, skin color (amongst other things) at all. This
means not judging people based on these factors, and being friendly,
inviting and supportive with everybody in everyday life by default. On
the street, in hallways and rooms, and on the internet. This behavior
also includes using words and phrases that are non-offensive. So as a
result, the proposed patch advocates avoiding words such as "slave" and
"blacklist".
However, as it was already said in this discussion by other parties,
"context is everything". Quite ironically, this was said in a slightly
different context, but it doesn't change the importance and general
truth of these words. I'll go out on a limb and claim that nobody who
wrote "master-slave" during development of a device driver, or used the
word "blacklist" was actually thinking of African people or human
slavery. In the context of the Linux kernel (and in computing in
general), these words have a long history and have zero bad connotation,
no racism, and absolutely null offense. One could argue that
recommending to retroactively remove such references (which the original
proposal does) assumes that these were offensive, hence suggesting to a
certain degree that past developers who have used these words were
possibly racists. Retroactively removing those occurrences from code is
thus, I honestly think, disrespecting and insulting to the original
authors. Because why remove them if they didn't mean anything bad? And
before you say "because those instances could still be interpreted as
offensive", I'll get to that soon.
The proposal is just a surface treatment
===========================
... and a bad one at that. The "black" in "blacklist" has nothing to do
with African or Afro-American people. No matter how many occurrences of
"black" we eradicate from our dictionary, the word "black" will always
have bad connotations. This connotation stems from darkness, the absence
of beautiful colors, and historically from the coldness, darkness and
insecurity of the night. Dan W. dismisses this by saying this is an
etymological argument, but we cannot dismiss arguments just because they
are unbeneficial (is that even a word?) to our cause. The true problem
is not that the word "black" has bad connotations, but that people with
dark skin color have been labeled with a word that has a bad
connotation. If we don't want to be offensive, (as a small step) we must
stop thinking of African and Afro-American people as "black" and ban
this labeling of them. Note the big difference: Instead of banning the
use of a simple color in some contexts which have nothing to do with
oppression, hate or slavery, we should instead stop referring to groups
of people with a word that incites bad feelings. For this reason, I
argue that banning "blacklist" is just a surface treatment that doesn't
recognize the true problem behind it, and even if implemented will stay
ineffective. Accepting this proposal is like fixing an error message in
the kernel logs by simply removing the error message instead of fixing
the underlying bug. To fix the bug in our language, we must stop
referring to "black" people as black people. A measure where proponents
of the patch fail at most.
Being respectful
===========================
The case for "slave" is a bit different, obviously, because the
etymology here does link to actual human slavery. Again, it is important
to note the context however. In computing, this means something
completely different, end of sentence. Supporters of the patch will come
and say, "it doesn't need to be meant offensively to be taken
offensively". That's true, of course, but only if it is a
misunderstanding, which in the computing context has zero chance. If you
know and understand what the other party *really* meant, then something
that wasn't meant offensively cannot be taken offensively. The right
word here is not "offensive", but one or more of "uncomfortable",
"disturbing", or "upsetting". Now *that* is understandable. If you have
a history of you or your ancestors been oppressed, then talking about
slavery understandably generates unwelcome emotional reactions. But this
has nothing to do with inclusion, racism, or hate. However, because we
don't want to emotionally upset people, I actually support avoiding
references to "slave" in the future. Importantly though, this support is
out of respect, and not because it has anything to do with being
offensive. In this context, we should, and for correctness sake must,
stop referring to "offensiveness".
Though even this logic is borderline: just recently, half a million
people have fallen victim to COVID-19 in over just a couple of months.
The number of affected relatives are probably 2-3x of that, who are now
emotionally shaken and uncomfortable about talking about the virus.
Imagine where we would be now (or where we will be in half a year) if we
stopped referring to COVID to avoid emotionally upsetting these people.
About that argument with efficiency
===========================
The patch author goes into detail to "illustrate" how avoiding these
words will improve efficiency. I'm sorry to call this out, but this is
utterly bogus and distracting from the issue at hand. First of all, not
any maintainer has been slowed done or has worked less efficiently
because they saw the word "blacklist" or "slave" in the kernel sources.
These *technical* phrases are not like bad code formatting where
disconformity leads to worse readability or makes the coding intent
harder to follow or understand. Quite the contrary, if anybody read the
proposed "denylist" instead of "blacklist", they will stop for a second,
think "what an odd choice of words...", and if it wasn't for the current
black-lives-matter movement, would have a year ago probably even
refactored the code (or requested a v2-patch) with the usual terminology
of "blacklist". In other words, this argument has zero real-life basis
and will, if implemented, achieve the opposite effect of what it is
claiming.
If we do this, there is no end to politics
===========================
Let me start with an example. The patch author neglectfully forgets
about proposing to ban "whitelist", not just "blacklist". If we agree
that "blacklist" is wrong because it assumes that everything "black" is
always bad (and thus black people'd be bad), then obviously we *have to*
remove whitelist too. Because "whitelist" then assumes that everything
"white" is always good, and now since we're unable to ignore the
reference to skin-color, so this is just as racist (actually even
worse), suggesting white supremacy. It is obvious that whoever thought
out the exclusion of "blacklist" didn't think this through. But we all
know, these words to be replaced all stem from outside our community,
and the current patch is not the result of careful consideration, but
the result of giving-in to external pressure, and to political and media
waves. The Linux community should stand strong and be inclusive by
*being* welcoming, friendly and helpful to everybody irrespective of
skin color, not by *saying* what current political activists expect us
to say. It might even be better to stop talking about skin color in the
context of kernel development altogether, because skin color doesn't
matter here. Here people judge others by technical competency. Any
discussions otherwise are fueled by external factors and are a
distraction. Note this does *not* mean we turn our backs to racism or
offensive behavior. If we see any such poisonous activity among our
circles now or in the future, we must and will single them out and teach
them better, and for incorrigible cases we distance ourselves from them.
But these will be one-off cases that will be handled appropriately.
Unless it becomes a common problem among Linux developers, it is not our
responsibility to write down each and every desirable human behavior
(again, see top about "sending the wrong message"). We've successfully
avoided pests from infecting our circles in the past and we'll continue
to do so. Avoiding the word "blacklist" makes no difference here. How do
I know? Because let's be real: The use of the word "blacklist" has not
deterred a developer from joining our community yet... for about 25
years now. On the other hand this discussion is now wasting everybody's
time. With that last sentence in mind, sorry for this mail turning out
so long.
Raschko T.
Hi Chris,
On Mon, Jul 06, 2020 at 12:45:34PM +0000, Chris Mason via Ksummit-discuss wrote:
> On 5 Jul 2020, at 0:55, Willy Tarreau wrote:
> > On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams wrote:
> >> +Non-inclusive terminology has that same distracting effect which is why
> >> +it is a style issue for Linux, it injures developer efficiency.
> >
> > I'm personally thinking that for a non-native speaker it's already
> > difficult to find the best term to describe something, but having to
> > apply an extra level of filtering on the found words to figure whether
> > they are allowed by the language police is even more difficult.
>
> Since our discussions are public, we’ve always had to deal with
> comments from people outside the community on a range of topics. But
> inside the kernel, it’s just a group of developers trying to help each
> other produce the best quality of code. We’ve got a long history
> together and in general I think we’re pretty good at assuming good
> intent.
>
> > *This* injures developers efficiency. What could improve developers efficiency
> > is to take care of removing *all* idiomatic or cultural words then. For
> > example I've been participating to projects using the term "blueprint",
> > I didn't understand what that meant. It was once explained to me and
> > given that it had no logical reason for being called this way, I now
> > forgot. If we follow your reasoning, Such words should be banned for
> > exactly the same reasons. Same for colors that probably don't mean
> > anything to those born blind.
> >
> > For example if in my local culture we eat tomatoes at starters and
> > apples for dessert, it could be convenient for me to use "tomato" and
> > "apple" as list elements to name the pointers leading to the beginning
> > and the end of the list, and it might sound obvious to many people, but
> > not at all for many others.
> >
> > Maybe instead of providing an explicit list of a few words it should
> > simply say that terms that take their roots in the non-technical world
> > and whose meaning can only be understood based on history or local
> > culture ought to be avoided, because *that* actually is the real
> > root cause of the problem you're trying to address.
>
> I’d definitely agree that it’s a good goal to keep out non-technical
> terms. Even though we already try, every subsystem has its own set of
> patterns that reflect the most frequent contributors.
That's an interesting point, because to me, it's the exact opposite. One
of the intellectual rewards I find in working with the kernel is that
our community is international and multicultural, allowing me to learn
about other cultures. Aiming for the lowest common denominator seems to
me to be closer to erasing cultural differences than including them.
--
Regards,
Laurent Pinchart
On Sun, Jul 05, 2020 at 06:55:05AM +0200, Willy Tarreau wrote:
> On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams wrote:
> > +Non-inclusive terminology has that same distracting effect which is why
> > +it is a style issue for Linux, it injures developer efficiency.
>
> I'm personally thinking that for a non-native speaker it's already
> difficult to find the best term to describe something, but having to
> apply an extra level of filtering on the found words to figure whether
> they are allowed by the language police is even more difficult. *This*
> injures developers efficiency. What could improve developers efficiency
> is to take care of removing *all* idiomatic or cultural words then. For
> example I've been participating to projects using the term "blueprint",
> I didn't understand what that meant. It was once explained to me and
> given that it had no logical reason for being called this way, I now
> forgot. If we follow your reasoning, Such words should be banned for
> exactly the same reasons. Same for colors that probably don't mean
> anything to those born blind.
While I agree that using terms that can only be understood given a
cultural context that not everyone may share, I would think that better
examples would be references to movies/novels etc.
Though I'm not sure if blueprint translates literally into other
languages, it did actually have a logical reason, viz engineering
drawings used to be blue/white. But logical reasons don't have to exist.
In the case of colors, for example, using red-black tree doesn't exclude
blind people, precisely because there is no logical reason for using the
colors red and black, or even colors at all, so it's not as if you gain
any additional insight into the structure if you are able to see the
colors. It just needs _some_ arbitrary labels for distinguishing two
classes of nodes, it could just as well have been named A-B tree or 0-1
tree or whatever. I don't think there is any concise way to label them
that conveys anything useful about how they're used in the data
structure -- you just have to learn about the structure and how it's
used. This isn't the case with whitelist/blacklist, where those colors
actually have connotations about what the two lists mean.
On Mon, 6 Jul 2020 11:22:10 -0400
Arvind Sankar <[email protected]> wrote:
> Though I'm not sure if blueprint translates literally into other
> languages, it did actually have a logical reason, viz engineering
> drawings used to be blue/white. But logical reasons don't have to exist.
> In the case of colors, for example, using red-black tree doesn't exclude
> blind people, precisely because there is no logical reason for using the
> colors red and black, or even colors at all, so it's not as if you gain
> any additional insight into the structure if you are able to see the
> colors. It just needs _some_ arbitrary labels for distinguishing two
> classes of nodes, it could just as well have been named A-B tree or 0-1
> tree or whatever. I don't think there is any concise way to label them
> that conveys anything useful about how they're used in the data
> structure -- you just have to learn about the structure and how it's
> used. This isn't the case with whitelist/blacklist, where those colors
> actually have connotations about what the two lists mean.
When I learned about R-B trees in my algorithms class decades ago, I
distinctly remember the text book saying something about how the red
and black names were meaningless. Just know that the nodes are
different in how you go about sorting or injecting a new node into the
tree. So yes, it could have been blue and yellow, or 1 and 0, or Bob
and Alice. The colors were just a way of labeling in order to
differentiate the two types of nodes, and I am not worried that people
are going to take offense to them.
-- Steve
On 6 Jul 2020, at 10:06, Laurent Pinchart wrote:
> Hi Chris,
>
> On Mon, Jul 06, 2020 at 12:45:34PM +0000, Chris Mason via
> Ksummit-discuss wrote:
>> On 5 Jul 2020, at 0:55, Willy Tarreau wrote:
>>> Maybe instead of providing an explicit list of a few words it should
>>> simply say that terms that take their roots in the non-technical
>>> world
>>> and whose meaning can only be understood based on history or local
>>> culture ought to be avoided, because *that* actually is the real
>>> root cause of the problem you're trying to address.
>>
>> I’d definitely agree that it’s a good goal to keep out
>> non-technical
>> terms. Even though we already try, every subsystem has its own set
>> of
>> patterns that reflect the most frequent contributors.
>
> That's an interesting point, because to me, it's the exact opposite.
> One
> of the intellectual rewards I find in working with the kernel is that
> our community is international and multicultural, allowing me to learn
> about other cultures. Aiming for the lowest common denominator seems
> to
> me to be closer to erasing cultural differences than including them.
I hadn’t thought of it from this angle, but I do agree with you. I
think the cultural side comes through more in discussions and in-person
conferences than it does from the code itself.
I do try to avoid local idioms or culture references unless I’m
explaining them as part of a discussion or a personal story, mostly
because I’ve gotten feedback from coworkers who had a hard time
following my bad (ok, terrible) jokes or sarcasm. One internal example
is commands that take —clowntown as an argument. It’s pretty
therapeutic to type when you’re grumpy about tooling, but a lot of
people probably have to look it up before it makes sense.
-chris
Hi Chris,
On Mon, Jul 06, 2020 at 12:45:34PM +0000, Chris Mason via Ksummit-discuss wrote:
> On 5 Jul 2020, at 0:55, Willy Tarreau wrote:
>
> > On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams wrote:
> >> +Non-inclusive terminology has that same distracting effect which is
> >> why
> >> +it is a style issue for Linux, it injures developer efficiency.
> >
> > I'm personally thinking that for a non-native speaker it's already
> > difficult to find the best term to describe something, but having to
> > apply an extra level of filtering on the found words to figure whether
> > they are allowed by the language police is even more difficult.
>
> Since our discussions are public, we’ve always had to deal with
> comments from people outside the community on a range of topics. But
> inside the kernel, it’s just a group of developers trying to help each
> other produce the best quality of code. We’ve got a long history
> together and in general I think we’re pretty good at assuming good
> intent.
I don't think anybody doubts your intentions. But they say, the road to
hell is paved with good intentions.
I had a "privilege" to live in the USSR and back there Newspeak was not a
fiction but a reality.
And despite the good intent, I have a really strong feeling that this
could be a step in a wrong direction...
> > *This*
> > injures developers efficiency. What could improve developers
> > efficiency
> > is to take care of removing *all* idiomatic or cultural words then.
> > For
> > example I've been participating to projects using the term
> > "blueprint",
> > I didn't understand what that meant. It was once explained to me and
> > given that it had no logical reason for being called this way, I now
> > forgot. If we follow your reasoning, Such words should be banned for
> > exactly the same reasons. Same for colors that probably don't mean
> > anything to those born blind.
> >
> > For example if in my local culture we eat tomatoes at starters and
> > apples for dessert, it could be convenient for me to use "tomato" and
> > "apple" as list elements to name the pointers leading to the beginning
> > and the end of the list, and it might sound obvious to many people,
> > but
> > not at all for many others.
> >
> > Maybe instead of providing an explicit list of a few words it should
> > simply say that terms that take their roots in the non-technical world
> > and whose meaning can only be understood based on history or local
> > culture ought to be avoided, because *that* actually is the real
> > root cause of the problem you're trying to address.
>
> I’d definitely agree that it’s a good goal to keep out non-technical
> terms. Even though we already try, every subsystem has its own set of
> patterns that reflect the most frequent contributors.
>
> -chris
> _______________________________________________
> Ksummit-discuss mailing list
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
--
Sincerely yours,
Mike.
On Sat, Jul 4, 2020 at 1:19 PM Dan Williams <[email protected]> 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 <[email protected]>
> Cc: Kees Cook <[email protected]>
> Signed-off-by: Chris Mason <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Dan Williams <[email protected]>
> ---
> 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'
Can you put whitelist in the list, too?
>. Recommended replacements for 'slave' are: 'secondary',
> +'subordinate', 'replica', 'responder', 'follower', 'proxy', or
> +'performer'.
Should 'target' be in this list?
Should there be some mention of "master" to go along with "slave"?
This could be complicated -- as has been noted in this thread, the
word "master" has quite a few meanings, several of which are not
related to slavery or to any form of control, and that the meanings
associated with "master" and its cognates in other languages vary.
> Recommended replacements for blacklist are: 'blocklist' or
> +'denylist'.
As someone who has written seccomp code and described the result as a
"whitelist" or "blacklist" in the past, I have a couple of comments.
First, shouldn't whitelist be in the list? I find it surprising to
put 'blacklist' in the blocklist but to omit whitelist.
Second, I realize that I grew up thinking that 'whitelist' and
'blacklist' are the common terms for lists of things to be accepted
and rejected and that this biases my perception of what sounds good,
but writing a seccomp "denylist" or "blocklist" doesn't seem to roll
off the tongue. Perhaps this language would be better:
Is most contexts where 'whitelist' or 'blacklist' might be used, a
descriptive phrase could be used instead. For example, a seccomp
filter could have a 'list of allowed syscalls' or a 'list of
disallowed syscalls', and just lists could be the 'allowed' or
'accepted' lists and the 'disallowed', 'rejected', or 'blocked' lists.
If a single word replacement for 'whitelist' or 'blacklist' is needed,
'allowlist', 'blocklist', or 'denylist' could be used.
> @@ -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.
Should this type of historical note be in the document or in the changelog?
Suppose that we put it in this document and then, in two years,
someone notices that the very first bit of text in your changelog that
diff helpfully quoted for you is also mildly offensive to certain
groups Now we could end up with:
... in 2020 there was a global reckoning ...
... in 2022, people noticed that comparing peoples' opinions on
variable names to medical conditions could be seen as inappropriate
...
etc. And now this document ends up with a lot of history and also a
lot of content, and the history part starts to resemble the
now-frowned-upon lists of copyrights and changes that clutter the tops
of various kernel C files. I suppose that changing this could be
deferred until such time as it might be an actual problem, but perhaps
this should go in the changelog instead.
On 7/4/20 2:02 PM, Dan Williams 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.
>
Hi Dan,
Thanks for taking the time to work on this patch and updating the
coding-style.rst with the with inclusive terminology guidelines and
adding a new document outlining the scope.
The suggestions you made will help us adapt inclusive terminology
for the current times, and also help us move toward terms that are
intuitive and easier to understand keeping our global developer
community in mind.
Allowlist/denylist terms are intuitive and action based which have a
globally uniform meaning.
Terms such as "whitelist" etc are contextual, hence assume contextual
knowledge on the part of the reader.
A couple comments below:
> Cc: Jonathan Corbet <[email protected]>
> Cc: Kees Cook <[email protected]>
> Signed-off-by: Chris Mason <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Dan Williams <[email protected]>
> ---
> 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'.
allowlist and blocklist or denylist are lot more intuitive than
white/black in any case.
> +
> +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.
allowlist/denylist makes the most sense than using colors.
> +
> +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
>
Please add my Signed-off-by: Shuah Khan <[email protected]>
or Acked-by: Shuah Khan <[email protected]>
thanks,
-- Shuah
On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams wrote:
> +'blacklist'. Recommended replacements for 'slave' are: 'secondary',
> +'subordinate', 'replica', 'responder', 'follower', 'proxy', or
I'd second the suggestion of device as an option here.
> +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,
More generally etymological arguments are just not super relevant here
anyway, the issues people have are around current perceptions rather
than where things came from.
> +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.
This, especially the bit about "revelation of 2020", sounds a little
off to me - I think it's that it's worryingly close to the frequently
derided pattern where people recognise a problem that other people have
been talking about for a while and treat it as something new. Perhaps a
more neutrally worded reference to current events and/or our desire to
improve instead?
On 04/07/2020 23:02, Dan Williams 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 <[email protected]>
> Cc: Kees Cook <[email protected]>
> Signed-off-by: Chris Mason <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Dan Williams <[email protected]>
> ---
> 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'.
"Subordinate" means that they are unequal, and inequality is a big issue. This
should be forbidden as well. And what with "secondary"? Are you implying that
one better than another? That's shouting that people from the second world
countries don't have right to be included, this can't be good. Are you trying
to exclude me? That deeply hurts me, don't you care?
How about killing all words that mean "ownership" or "owning" then? And what
with that "kill"? It's everywhere, and it definitely means killing a person. That's
one meaning at least... but we don't care about other interpretations, do we?
...
> +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.
Code styles also exist to not think about things that doesn't matter, as
well as terminologies do -- you see it, and the meaning is apparent. And
that betrays the whole idea when you replace well-known terms with some
random words.
Well, if you're trying to point people what to say and how to think,
could you please __at least__ be consistent? That would be really nice.
Let me outline -- discrimination is an issue. And creating a common
vocabulary can be pretty useful. But instead of it being helpful, the only
thing I see here is ill-conceived and pretty arrogant essay.
--
Pavel Begunkov
On Tue, 7 Jul 2020 00:31:49 +0300
Pavel Begunkov <[email protected]> wrote:
> > 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'.
>
> "Subordinate" means that they are unequal, and inequality is a big issue. This
And if two objects are unequal, then that seems to be an appropriate
term. We are not concerned about the inequality of devices.
-- Steve
On 07/07/2020 01:10, Steven Rostedt wrote:
> On Tue, 7 Jul 2020 00:31:49 +0300
> Pavel Begunkov <[email protected]> wrote:
>>> 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'.
>>
>> "Subordinate" means that they are unequal, and inequality is a big issue. This
>
> And if two objects are unequal, then that seems to be an appropriate
> term. We are not concerned about the inequality of devices.
Totally agree with you! But do we care then whether two _devices_ or _objects_
are slave-master? Can't see how it fundamentally differs.
--
Pavel Begunkov
On Tue, 7 Jul 2020 01:17:47 +0300
Pavel Begunkov <[email protected]> wrote:
> Totally agree with you! But do we care then whether two _devices_ or _objects_
> are slave-master? Can't see how it fundamentally differs.
The term slave carries a lot more meaning than subordinate. I replied to
someone else but later realized that the person sent me their reply
offlist, so my reply to them was also offlist. What I told them was,
back in college (decades ago), when I first mentioned "master/slave" in
conversation (I think it was about hard drives), a person in that
conversation stated that those were not very nice terms to use. I blew
it off back then, but after listening to more people, I found that
using "slave" even to describe a device is not something that people
care to hear about.
And in actuality, does one device actually enslave another device? I
think that terminology is misleading to begin with.
-- Steve
On 07/07/2020 01:28, Steven Rostedt wrote:
> On Tue, 7 Jul 2020 01:17:47 +0300
> Pavel Begunkov <[email protected]> wrote:
>
>> Totally agree with you! But do we care then whether two _devices_ or _objects_
>> are slave-master? Can't see how it fundamentally differs.
>
> The term slave carries a lot more meaning than subordinate. I replied to
> someone else but later realized that the person sent me their reply
> offlist, so my reply to them was also offlist. What I told them was,
> back in college (decades ago), when I first mentioned "master/slave" in
> conversation (I think it was about hard drives), a person in that
> conversation stated that those were not very nice terms to use. I blew
> it off back then, but after listening to more people, I found that
> using "slave" even to describe a device is not something that people
> care to hear about.
That's cultural, but honestly I've never seen such a person. I still
don't understand, why having secondary or subordinate object belittling
the owned side by not providing it the same rights and freedom is OK,
but slave/master objects are not. Where is the line?
>
> And in actuality, does one device actually enslave another device? I
> think that terminology is misleading to begin with.
As mentioned, I do like good clear terminology, and if it conveys the idea
better, etc., then it's worth to try. And IMHO that's the right reasoning
that should be behind. Otherwise, for almost every word we can find a person
seeing something subjectively offensive or at least bad in it.
--
Pavel Begunkov
> The suggestions you made will help us adapt inclusive terminology
> for the current times, and also help us move toward terms that are
> intuitive and easier to understand keeping our global developer
> community in mind.
> Allowlist/denylist terms are intuitive and action based which have a
> globally uniform meaning.
Nobody has a problem understanding "blacklist" and "whitelist". These
are universally understood words even outside of computing. Claiming
that we need clearer alternatives is smoke and mirrors.
> Terms such as "whitelist" etc are contextual, hence assume contextual
> knowledge on the part of the reader.
We are talking about the source code of and interacting with an
operating system kernel. Naturally, most things here are contextual and
require domain knowledge to be understood correctly. Not requiring
contextual knowledge when reading the kernel sources doesn't sound like
a realistic argument.
Raschko T.
> More generally etymological arguments are just not super relevant here
> anyway, the issues people have are around current perceptions rather
> than where things came from.
This is where ignoring etymology in this case falls apart, claiming that the
current meaning is more important than the historical one. Yes it should be more
important, but it suggests that the current meaning is negative, which it is
not. In computer science (context!) these words do not have any negative
perception or connotation, and people in this field know this. Yes, outsiders
might not know this and could misunderstand them. But since when do experts in
computer science (or in any field of science for the matter) care if a layman
can correctly understand the field's technical terms? We never did and never
will, except in this particular case for some odd reason.
Be honest: "blacklist" is a technical term where the actual meaning has no
negative connotation despite what people outside the field might think. But
apparently we don't care about the actual meaning. We also don't care about the
historical meaning or etymology. We only care about... well if not about the
meaning in the past or present, then I don't know what. Looking good in the media?
On Mon, Jul 6, 2020 at 9:30 AM Andy Lutomirski <[email protected]> wrote:
>
> On Sat, Jul 4, 2020 at 1:19 PM Dan Williams <[email protected]> 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 <[email protected]>
> > Cc: Kees Cook <[email protected]>
> > Signed-off-by: Chris Mason <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > Signed-off-by: Dan Williams <[email protected]>
> > ---
> > 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'
>
> Can you put whitelist in the list, too?
Yes, will do. I had left it out mistakenly thinking it would help
focus the discussion, but the replacements don't make sense without
including the replacements for whitelist.
>
> >. Recommended replacements for 'slave' are: 'secondary',
> > +'subordinate', 'replica', 'responder', 'follower', 'proxy', or
> > +'performer'.
>
> Should 'target' be in this list?
Yes.
> Should there be some mention of "master" to go along with "slave"?
> This could be complicated -- as has been noted in this thread, the
> word "master" has quite a few meanings, several of which are not
> related to slavery or to any form of control, and that the meanings
> associated with "master" and its cognates in other languages vary.
Yes, I'll at least expand this with the paired terminology for each of
the replacements of 'slave'.
>
> > Recommended replacements for blacklist are: 'blocklist' or
> > +'denylist'.
>
> As someone who has written seccomp code and described the result as a
> "whitelist" or "blacklist" in the past, I have a couple of comments.
>
> First, shouldn't whitelist be in the list? I find it surprising to
> put 'blacklist' in the blocklist but to omit whitelist.
>
> Second, I realize that I grew up thinking that 'whitelist' and
> 'blacklist' are the common terms for lists of things to be accepted
> and rejected and that this biases my perception of what sounds good,
> but writing a seccomp "denylist" or "blocklist" doesn't seem to roll
> off the tongue. Perhaps this language would be better:
>
> Is most contexts where 'whitelist' or 'blacklist' might be used, a
> descriptive phrase could be used instead. For example, a seccomp
> filter could have a 'list of allowed syscalls' or a 'list of
> disallowed syscalls', and just lists could be the 'allowed' or
> 'accepted' lists and the 'disallowed', 'rejected', or 'blocked' lists.
> If a single word replacement for 'whitelist' or 'blacklist' is needed,
> 'allowlist', 'blocklist', or 'denylist' could be used.
That makes practical sense to me. Now that I look at this I think the
recommendation for the shorthand replacement should only be one style
option, lets say "blocklist/passlist" because it's not as amenable to
context sensitive replacements as "slave" and benefits from a standard
single shorthand.
>
>
> > @@ -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.
>
> Should this type of historical note be in the document or in the changelog?
>
> Suppose that we put it in this document and then, in two years,
> someone notices that the very first bit of text in your changelog that
> diff helpfully quoted for you is also mildly offensive to certain
> groups Now we could end up with:
>
> ... in 2020 there was a global reckoning ...
>
> ... in 2022, people noticed that comparing peoples' opinions on
> variable names to medical conditions could be seen as inappropriate
Perhaps. Again, I wanted to stay focused and not dilute the discussion
about the specific terminology at issue with a series of "what about"
debates. I also did not want to specify a threshold for when Linux
would need to deal with an issue like this again. I believe that will
be a case of "we'll know it when we see it". Certainly the terminology
at hand seems to have passed that threshold given multiple
organizations actively discussing and deploying policy to address it.
> ...
> etc. And now this document ends up with a lot of history and also a
> lot of content, and the history part starts to resemble the
> now-frowned-upon lists of copyrights and changes that clutter the tops
> of various kernel C files. I suppose that changing this could be
> deferred until such time as it might be an actual problem, but perhaps
> this should go in the changelog instead.
Sure, I'd be ok with that to move the coding-style change forward.
On Mon, Jul 6, 2020 at 11:30 AM Shuah Khan <[email protected]> wrote:
>
> On 7/4/20 2:02 PM, Dan Williams 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.
> >
>
> Hi Dan,
>
> Thanks for taking the time to work on this patch and updating the
> coding-style.rst with the with inclusive terminology guidelines and
> adding a new document outlining the scope.
>
> The suggestions you made will help us adapt inclusive terminology
> for the current times, and also help us move toward terms that are
> intuitive and easier to understand keeping our global developer
> community in mind.
>
> Allowlist/denylist terms are intuitive and action based which have a
> globally uniform meaning.
>
> Terms such as "whitelist" etc are contextual, hence assume contextual
> knowledge on the part of the reader.
>
> A couple comments below:
>
> > Cc: Jonathan Corbet <[email protected]>
> > Cc: Kees Cook <[email protected]>
> > Signed-off-by: Chris Mason <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > Signed-off-by: Dan Williams <[email protected]>
> > ---
> > 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'.
>
> allowlist and blocklist or denylist are lot more intuitive than
> white/black in any case.
Yes, that was interesting to me when I first grappled with this. The
replacements are more direct.
I was going to go with blocklist/passlist as the common shorthand
recommendation, but if a subsystem picks allowlist/denylist as a local
custom that's fine too.
[..]
> Please add my Signed-off-by: Shuah Khan <[email protected]>
> or Acked-by: Shuah Khan <[email protected]>
Thanks Shuah.
On Mon, Jul 6, 2020 at 12:16 PM Mark Brown <[email protected]> wrote:
>
> On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams wrote:
>
> > +'blacklist'. Recommended replacements for 'slave' are: 'secondary',
> > +'subordinate', 'replica', 'responder', 'follower', 'proxy', or
>
> I'd second the suggestion of device as an option here.
Sure, will do. I'm assuming you're thinking of cases where 'slave' is
used in isolation without a paired relative term? If not, please
clarify.
>
> > +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,
>
> More generally etymological arguments are just not super relevant here
> anyway, the issues people have are around current perceptions rather
> than where things came from.
>
> > +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.
>
> This, especially the bit about "revelation of 2020", sounds a little
> off to me - I think it's that it's worryingly close to the frequently
> derided pattern where people recognise a problem that other people have
> been talking about for a while and treat it as something new. Perhaps a
> more neutrally worded reference to current events and/or our desire to
> improve instead?
I'd just as soon let this commentary live in the archives if people
need some more background. It's not like we have companion essays on
the other recommendations in coding-style, and we seem to be
converging on just amending coding-style.
On Mon, Jul 6, 2020 at 9:07 AM Mike Rapoport <[email protected]> wrote:
>
> Hi Chris,
>
> On Mon, Jul 06, 2020 at 12:45:34PM +0000, Chris Mason via Ksummit-discuss wrote:
> > On 5 Jul 2020, at 0:55, Willy Tarreau wrote:
> >
> > > On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams wrote:
> > >> +Non-inclusive terminology has that same distracting effect which is
> > >> why
> > >> +it is a style issue for Linux, it injures developer efficiency.
> > >
> > > I'm personally thinking that for a non-native speaker it's already
> > > difficult to find the best term to describe something, but having to
> > > apply an extra level of filtering on the found words to figure whether
> > > they are allowed by the language police is even more difficult.
> >
> > Since our discussions are public, we’ve always had to deal with
> > comments from people outside the community on a range of topics. But
> > inside the kernel, it’s just a group of developers trying to help each
> > other produce the best quality of code. We’ve got a long history
> > together and in general I think we’re pretty good at assuming good
> > intent.
>
> I don't think anybody doubts your intentions. But they say, the road to
> hell is paved with good intentions.
>
> I had a "privilege" to live in the USSR and back there Newspeak was not a
> fiction but a reality.
>
> And despite the good intent, I have a really strong feeling that this
> could be a step in a wrong direction...
I've experienced some professional training classes for visiting other
countries and they tell you helpful things like "avoid making jokes
about X" or "Y topic is sensitive". It's not about censoring it's more
about how to keep discussion focused on the job at hand. So I'm hoping
this is more of the mundane advice of "what's the best way to
communicate my point efficiently to the widest possible audience" and
not a "step in a wrong direction"... time will tell.
On Sat, Jul 4, 2020 at 5:41 PM Kees Cook <[email protected]> wrote:
>
> On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams 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 <[email protected]>
> > Cc: Kees Cook <[email protected]>
> > Signed-off-by: Chris Mason <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > Signed-off-by: Dan Williams <[email protected]>
>
> (nit: isn't this a Co-developed-by chain, not a SoB chain?)
>
> Acked-by: Kees Cook <[email protected]>
>
> Comments below...
>
> > ---
> > 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'.
>
> Keeping "master" in a "master/slave" pairing (i.e. replacing only
> "slave") seems incomplete to me. If "master" is paired with "slave", it
> should be replaced too. Potential examples: 'primary', 'leader', 'principle',
> 'controller', 'sender', 'initial'.
Yes, this matches Andy's feedback, will add.
> Similarly, for "whitelist/blacklist", "whitelist" needs to replaced when
> "blacklist" has been. For example, seccomp documentation[1] uses
> "allow-list" and "deny-list".
>
> [1] https://man7.org/linux/man-pages/man2/seccomp.2.html
Oh, good to know will make that change.
> > +Exceptions for introducing new usage is to maintain a userspace ABI, or
>
> and API?
True, yes, the intent was "don't break userspace" for terminology replacement.
>
> > +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.
>
> Let's add:
>
> Where possible, old instances of this language should be replaced when
> it is not tied to external specifications nor userspace ABI/API.
Sounds good to me.
>
> >
> > 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.
>
> ... usage of 'master/slave', 'slave', 'whitelist/blacklist', and
> 'blacklist' in the Linux kernel.
Yes, but as I'm reading this thread backwards I've already agreed to
just push the coding-style change in isolation.
>
> > +
> > +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.
>
> Let's add:
>
> Beyond just Linux
> =================
>
> For those of us in the kernel community involved in specification
> development or similar larger ecosystem conversations, please help
> steer those discussions to avoid these terms in new specifications
> or APIs.
I agree with this statement and am interested in getting connected to
those conversations, but this may be a bit too much advocacy to expect
in kernel documentation.
On Mon, Jul 06, 2020 at 09:29:46AM -0700, Andy Lutomirski wrote:
> Is most contexts where 'whitelist' or 'blacklist' might be used, a
> descriptive phrase could be used instead. For example, a seccomp
> filter could have a 'list of allowed syscalls' or a 'list of
> disallowed syscalls', and just lists could be the 'allowed' or
> 'accepted' lists and the 'disallowed', 'rejected', or 'blocked' lists.
> If a single word replacement for 'whitelist' or 'blacklist' is needed,
> 'allowlist', 'blocklist', or 'denylist' could be used.
Yup. See:
https://lore.kernel.org/lkml/202007041703.51F4059CA@keescook/
specifically the terminology for seccomp is already "allow-list" and
"deny-list":
https://github.com/mkerrisk/man-pages/commit/462ce23d491904a0b46252dc97c8cb42391c093e (last year)
https://github.com/seccomp/libseccomp/commit/0e762521d604612bb4dca8867d4a428a5e6cae54 (last month)
> Second, I realize that I grew up thinking that 'whitelist' and
> 'blacklist' are the common terms for lists of things to be accepted
> and rejected and that this biases my perception of what sounds good,
> but writing a seccomp "denylist" or "blocklist" doesn't seem to roll
> off the tongue. Perhaps this language would be better:
I have struggled with this as well. The parts of speech change, and my
grammar senses go weird. whitelist = adjective noun. allow-list = verb
noun. verbing the adj/noun combo feels okay, but verbing a verb/noun is
weird.
And just using "allowed" and "denied" doesn't impart whether it refers
to a _single_ instance or a _list_ of instances.
But that's all fine. The change is easy to do and is more descriptive
even if I can't find terms that don't collide with my internal grammar
checker. ;)
--
Kees Cook
On Mon, Jul 06, 2020 at 10:56:17PM -0700, Kees Cook wrote:
> On Mon, Jul 06, 2020 at 09:29:46AM -0700, Andy Lutomirski wrote:
> > Is most contexts where 'whitelist' or 'blacklist' might be used, a
> > descriptive phrase could be used instead. For example, a seccomp
> > filter could have a 'list of allowed syscalls' or a 'list of
> > disallowed syscalls', and just lists could be the 'allowed' or
> > 'accepted' lists and the 'disallowed', 'rejected', or 'blocked' lists.
> > If a single word replacement for 'whitelist' or 'blacklist' is needed,
> > 'allowlist', 'blocklist', or 'denylist' could be used.
>
> Yup. See:
> https://lore.kernel.org/lkml/202007041703.51F4059CA@keescook/
> specifically the terminology for seccomp is already "allow-list" and
> "deny-list":
> https://github.com/mkerrisk/man-pages/commit/462ce23d491904a0b46252dc97c8cb42391c093e (last year)
> https://github.com/seccomp/libseccomp/commit/0e762521d604612bb4dca8867d4a428a5e6cae54 (last month)
>
> > Second, I realize that I grew up thinking that 'whitelist' and
> > 'blacklist' are the common terms for lists of things to be accepted
> > and rejected and that this biases my perception of what sounds good,
> > but writing a seccomp "denylist" or "blocklist" doesn't seem to roll
> > off the tongue. Perhaps this language would be better:
>
> I have struggled with this as well. The parts of speech change, and my
> grammar senses go weird. whitelist = adjective noun. allow-list = verb
> noun. verbing the adj/noun combo feels okay, but verbing a verb/noun is
> weird.
>
> And just using "allowed" and "denied" doesn't impart whether it refers
> to a _single_ instance or a _list_ of instances.
>
> But that's all fine. The change is easy to do and is more descriptive
> even if I can't find terms that don't collide with my internal grammar
> checker. ;)
How about yeslist and nolist? ;-)
> --
> Kees Cook
> _______________________________________________
> Ksummit-discuss mailing list
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
--
Sincerely yours,
Mike.
Hello,
On Sat, 04 Jul 2020 13:02:51 -0700 Dan Williams <[email protected]> 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.
I'm glad to see this patch.
>
> Cc: Jonathan Corbet <[email protected]>
> Cc: Kees Cook <[email protected]>
> Signed-off-by: Chris Mason <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Dan Williams <[email protected]>
Acked-by: SeongJae Park <[email protected]>
> ---
> 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'.
I have submitted a couple of patches for automated encouragement of the the
inclusive terms and those merged in the -next tree[1,2] now. Nonetheless, the
version says only "please consider using 'denylist' and 'allowlist' instead of
'blacklist' and 'whitelist'" for now. I think we could add more terms in there
based on this discussion. I could do that after this patch is merged, or you
could do that yourself in the next spin of this patch. Please do whatever you
feel comfort.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=7d0bea01dec27195d95d929c1ee49a4a74dd6671
[2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=95a94258ceb27052f00b7e51588a128d20bf05ed
Thanks,
SeongJae Park
Kees Cook wrote:
> I have struggled with this as well. The parts of speech change, and my
> grammar senses go weird. whitelist = adjective noun. allow-list = verb
> noun. verbing the adj/noun combo feels okay, but verbing a verb/noun is
> weird.
> And just using "allowed" and "denied" doesn't impart whether it refers
> to a _single_ instance or a _list_ of instances.
> But that's all fine. The change is easy to do and is more descriptive
> even if I can't find terms that don't collide with my internal grammar
> checker. ;)
But why. In English many times a verb when it comes before the noun means an adjective, or an adjective like, describing some traits of the noun.
Example:
I work - work is a verb here.
I used the work bench. - Work is saying something about the type of bench, an adjective. Same as you would say "I used the green bench".
I am not an English native at all but allow-list sounds totally English to me. (I guess the very correct English way is "allowed-list" where the past tense may convert the verb to a noun. but allow-list sounds very good to me as well. Say work-list as opposed to vacation-list do you need to say worked-list? I don't think so.)
run mate, running mate. cutting board. these are all examples of verbs used as adjectives. Are they not English? What am I missing I would like to learn?
Thanks
Boaz
On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams 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 <[email protected]>
> Cc: Kees Cook <[email protected]>
> Signed-off-by: Chris Mason <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Dan Williams <[email protected]>
> ---
This is the right thing to do.
Acked-by: Christian Brauner <[email protected]>
(Imho, I agree with Andy and the historical bits could probably be
moved into the changelog.)
> 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
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
On Tue, Jul 07, 2020 at 06:56:53AM +0000, Harrosh, Boaz wrote:
> Kees Cook wrote:
> > I have struggled with this as well. The parts of speech change, and my
> > grammar senses go weird. whitelist = adjective noun. allow-list = verb
> > noun. verbing the adj/noun combo feels okay, but verbing a verb/noun is
> > weird.
>
> > And just using "allowed" and "denied" doesn't impart whether it refers
> > to a _single_ instance or a _list_ of instances.
>
> > But that's all fine. The change is easy to do and is more descriptive
> > even if I can't find terms that don't collide with my internal grammar
> > checker. ;)
>
> But why. In English many times a verb when it comes before the noun means an adjective, or an adjective like, describing some traits of the noun.
This is kind of my problem being a native English speaker: I can't
entirely describe _why_ a grammar construct feels wrong. :(
> Example:
> I work - work is a verb here.
> I used the work bench. - Work is saying something about the type of bench, an adjective. Same as you would say "I used the green bench".
Right, so the verb-noun being used as a noun is find, just as adj-noun
is. To me, "add it to the allow-list" is entirely sensible just like
"set it on the work-bench." It's the "verbing" of a noun that trips me
up.
"I will whitelist the syscall" -- sounds correct to me (same for
"it is whitelisted" or "it is in whitelisting mode").
"I will allow-list the syscall" -- sounds wrong to me (same for
"it is allow-listed" or "it is in allow-listing mode").
Similarly, "I will work-bench" sounds wrong to me as does "it is
work-benched" or "it is in work-benching mode".
> I am not an English native at all but allow-list sounds totally English to me. (I guess the very correct English way is "allowed-list" where the past tense may convert the verb to a noun. but allow-list sounds very good to me as well. Say work-list as opposed to vacation-list do you need to say worked-list? I don't think so.)
>
> run mate, running mate. cutting board. these are all examples of verbs used as adjectives. Are they not English? What am I missing I would like to learn?
"it is in allowing-list mode" sounds even worse. :) But other
things require the tense follow the merged verb: "It's already in the
allowed-list" sounds fine, where "It's already in the whitelist" had no
tense since it lacked a verb. I haven't been able to find an comfortable
adjective that means "allow"; "allowable-list" is just long.
But, as mentioned earlier -- I have just switched to more descriptive
and less weird (to me) sentences. "It is set to deny by default"
(instead of "it's a whitelist") or "It's already in the allowed-list".
*shrug*
--
Kees Cook
On Mon, Jul 06, 2020 at 09:08:57PM -0700, Dan Williams wrote:
> On Mon, Jul 6, 2020 at 12:16 PM Mark Brown <[email protected]> wrote:
> > This, especially the bit about "revelation of 2020", sounds a little
> > off to me - I think it's that it's worryingly close to the frequently
> > derided pattern where people recognise a problem that other people have
> > been talking about for a while and treat it as something new. Perhaps a
> > more neutrally worded reference to current events and/or our desire to
> > improve instead?
> I'd just as soon let this commentary live in the archives if people
> need some more background. It's not like we have companion essays on
> the other recommendations in coding-style, and we seem to be
> converging on just amending coding-style.
That's even better from my point of view.
On Tue, Jul 07, 2020 at 06:56:53AM +0000, Harrosh, Boaz wrote:
> Kees Cook wrote:
> > I have struggled with this as well. The parts of speech change, and my
> > grammar senses go weird. whitelist = adjective noun. allow-list = verb
> > noun. verbing the adj/noun combo feels okay, but verbing a verb/noun is
> > weird.
> But why. In English many times a verb when it comes before the noun means an adjective, or an adjective like, describing some traits of the noun.
I fear that if you are looking for logic or reason in English grammar
you are on a path to disappointment. FWIW I share Kees' "that looks
off" instinct with some of the usage of allow/deny.
On Tue, 7 Jul 2020 09:49:21 +0300
Mike Rapoport <[email protected]> wrote:
> > But that's all fine. The change is easy to do and is more descriptive
> > even if I can't find terms that don't collide with my internal grammar
> > checker. ;)
>
> How about yeslist and nolist? ;-)
I was thinking good-list / bad-list.
/me that has been doing a lot of git bisect lately...
-- Steve
On Tue, 7 Jul 2020 01:54:23 -0700
Kees Cook <[email protected]> wrote:
> "I will whitelist the syscall" -- sounds correct to me (same for
> "it is whitelisted" or "it is in whitelisting mode").
>
> "I will allow-list the syscall" -- sounds wrong to me (same for
> "it is allow-listed" or "it is in allow-listing mode").
That's because we can't just make "allow-list" a drop in replacement
for "whitelist" as I too (native English speaker) find it awkward. But
then we don't need to make it a drop in replacement.
"I will whitelist the syscall" will become "I will add the syscall to
the allow-list", which sounds perfectly fine, and even better than
saying "I will add the syscall to the whitelist".
-- Steve
On Tue, Jul 07, 2020 at 09:41:47AM -0400, Steven Rostedt wrote:
> On Tue, 7 Jul 2020 01:54:23 -0700
> Kees Cook <[email protected]> wrote:
>
> > "I will whitelist the syscall" -- sounds correct to me (same for
> > "it is whitelisted" or "it is in whitelisting mode").
> >
> > "I will allow-list the syscall" -- sounds wrong to me (same for
> > "it is allow-listed" or "it is in allow-listing mode").
>
> That's because we can't just make "allow-list" a drop in replacement
> for "whitelist" as I too (native English speaker) find it awkward. But
> then we don't need to make it a drop in replacement.
>
> "I will whitelist the syscall" will become "I will add the syscall to
> the allow-list", which sounds perfectly fine, and even better than
> saying "I will add the syscall to the whitelist".
I will allow the syscall?
> -- Steve
--
Sincerely yours,
Mike.
> -----Original Message-----
> From: Steven Rostedt
>
> On Tue, 7 Jul 2020 09:49:21 +0300
> Mike Rapoport <[email protected]> wrote:
>
> > > But that's all fine. The change is easy to do and is more descriptive
> > > even if I can't find terms that don't collide with my internal grammar
> > > checker. ;)
> >
> > How about yeslist and nolist? ;-)
>
> I was thinking good-list / bad-list.
>
> /me that has been doing a lot of git bisect lately...
I think it depends on the context. I'd prefer a grammatically awkward verb that described
the action more specifically, than a grammatically nicer generic term. In other words,
yes/no, good/bad don't mean that much to me, unless it's obvious from context
what the effect will be. With something like allow/deny, I have a pretty clear mental
model of what the code is going to do.
-- Tim
On Tue, Jul 07, 2020 at 05:45:42PM +0300, Mike Rapoport wrote:
> On Tue, Jul 07, 2020 at 09:41:47AM -0400, Steven Rostedt wrote:
> > On Tue, 7 Jul 2020 01:54:23 -0700
> > Kees Cook <[email protected]> wrote:
> >
> > > "I will whitelist the syscall" -- sounds correct to me (same for
> > > "it is whitelisted" or "it is in whitelisting mode").
> > >
> > > "I will allow-list the syscall" -- sounds wrong to me (same for
> > > "it is allow-listed" or "it is in allow-listing mode").
> >
> > That's because we can't just make "allow-list" a drop in replacement
> > for "whitelist" as I too (native English speaker) find it awkward. But
> > then we don't need to make it a drop in replacement.
> >
> > "I will whitelist the syscall" will become "I will add the syscall to
> > the allow-list", which sounds perfectly fine, and even better than
> > saying "I will add the syscall to the whitelist".
>
> I will allow the syscall?
Kind of, but it's this change to verb-noun from adj-noun that confuses the
resulting language: the verb form of the verb-noun doesn't distinguish
between its stand-alone action ("allowed") or its combined action
("allow-list-ed") in the same way that the verb form of the adj-noun does
(the verbed adj-noun is its own word). To me to looks like "allowed" and
"whitelisted" mean distinct things (as in, a single allowance vs being
added to the persistent list of allowances).
So "I will allow this system call once" and "I will allow all instances
of this syscall", or we just get used to using the verb-noun as a whole,
and embrace "I allowlisted the syscall."
But yes, as I and others come back to: it's fine. We'll just use different
surrounding constructs to avoid confusion. But it is an odd characteristic
of English's grammar (or lack of appropriately descriptive adjectives) to
not have a drop-in replacement. (Which is where I think the master/slave
replacements fair far better -- the whitelist replacement is more complex,
but it's mostly just English glitchiness.)
--
Kees Cook
On Tue, Jul 07, 2020 at 02:48:25AM +0200, Tibor Raschko wrote:
> > More generally etymological arguments are just not super relevant here
> > anyway, the issues people have are around current perceptions rather
> > than where things came from.
>
> This is where ignoring etymology in this case falls apart, claiming that the
> current meaning is more important than the historical one. Yes it should be more
> important, but it suggests that the current meaning is negative, which it is
> not. In computer science (context!) these words do not have any negative
> perception or connotation, and people in this field know this. Yes, outsiders
> might not know this and could misunderstand them. But since when do experts in
> computer science (or in any field of science for the matter) care if a layman
> can correctly understand the field's technical terms? We never did and never
> will, except in this particular case for some odd reason.
>
> Be honest: "blacklist" is a technical term where the actual meaning has no
> negative connotation despite what people outside the field might think. But
> apparently we don't care about the actual meaning. We also don't care about the
> historical meaning or etymology. We only care about... well if not about the
> meaning in the past or present, then I don't know what. Looking good in the media?
Blacklist most definitely has a negative connotation in technical use.
You blacklist devices that don't work properly, you blacklist drivers
that don't work for your hardware, you blacklist domains that are
sending spam or trying to mount network attacks on your servers. Things
on the blacklist are "bad" in one way or the other, that's the reason
they're on it.
On Tue, Jul 07, 2020 at 01:54:23AM -0700, Kees Cook wrote:
> On Tue, Jul 07, 2020 at 06:56:53AM +0000, Harrosh, Boaz wrote:
> > Kees Cook wrote:
> > > I have struggled with this as well. The parts of speech change, and my
> > > grammar senses go weird. whitelist = adjective noun. allow-list = verb
> > > noun. verbing the adj/noun combo feels okay, but verbing a verb/noun is
> > > weird.
> >
> > > And just using "allowed" and "denied" doesn't impart whether it refers
> > > to a _single_ instance or a _list_ of instances.
> >
> > > But that's all fine. The change is easy to do and is more descriptive
> > > even if I can't find terms that don't collide with my internal grammar
> > > checker. ;)
> >
> > But why. In English many times a verb when it comes before the noun means an adjective, or an adjective like, describing some traits of the noun.
>
> This is kind of my problem being a native English speaker: I can't
> entirely describe _why_ a grammar construct feels wrong. :(
>
> > Example:
> > I work - work is a verb here.
> > I used the work bench. - Work is saying something about the type of bench, an adjective. Same as you would say "I used the green bench".
>
> Right, so the verb-noun being used as a noun is find, just as adj-noun
> is. To me, "add it to the allow-list" is entirely sensible just like
> "set it on the work-bench." It's the "verbing" of a noun that trips me
> up.
>
> "I will whitelist the syscall" -- sounds correct to me (same for
> "it is whitelisted" or "it is in whitelisting mode").
>
> "I will allow-list the syscall" -- sounds wrong to me (same for
> "it is allow-listed" or "it is in allow-listing mode").
I suspect it's at least partly because "allow" and "list" are both verbs
-- in fact, "list" is the actual verb in "I will allow-list it", and
"allow" is being used to modify the verb "list". But because "allow" is
usually a verb, the sentence sounds like there are two verbs in there
when there should only be one. I expect our ears will get trained to
accept that sentence once you encounter "allowlist" often enough.
> Blacklist most definitely has a negative connotation in technical use.
> You blacklist devices that don't work properly, you blacklist drivers
> that don't work for your hardware, you blacklist domains that are
> sending spam or trying to mount network attacks on your servers. Things
> on the blacklist are "bad" in one way or the other, that's the reason
> they're on it.
>
Of course, we put "bad" things on a blacklist. But in computing, only technical
things, not black people. What I meant with "blacklist has no negative
connotation" was that when we use the word "blacklist", nobody actually thinks
about people or skin color. Blocking bad IP addresses or faulty devices is
surely non-offensive.
If you argue that instead of this, what we really care about is "black" things
generally meaning something "bad", then forbidding "blacklist" will not get us
any closer to our goal. This is because we have a hundred other "black" phrases
in our language: black economy, black sheep, black market, to blacken, a
blackleg, a blackguard, a black mark ... only a couple of examples from the top
of my head.
My point is we will never get rid of the bad connotations in "black". "Black" is
always going to assume and remain something "unwanted", even after 2020. This is
why I think this whole campaign of removing "blacklist" is utterly ridiculous
and ineffective.
The real problem is that a group of people have been marked and
labeled with such a negative word. If we want to remove the negative association
from black people, we should stop calling them black. That'd be productive in
the long run, since afro-americans then wouldn't be associated with something
"bad" anymore.
But all the supporters of the campaign keep calling them something ba" by
calling them black, and hope to make a difference by banning 2 or 3 totally
unrelated phrases out of probably 50. The whole campaign is pointless and rides
on emotion and media attention instead of rational thinking.
I support avoiding references to master, slave, and to slavery in general.
I oppose avoiding blacklist.
Raschko T.
On Tue, 7 Jul 2020 02:03:36 +0300
Pavel Begunkov <[email protected]> wrote:
> On 07/07/2020 01:28, Steven Rostedt wrote:
> > On Tue, 7 Jul 2020 01:17:47 +0300
> > Pavel Begunkov <[email protected]> wrote:
> >
> >> Totally agree with you! But do we care then whether two _devices_ or _objects_
> >> are slave-master? Can't see how it fundamentally differs.
> >
> > The term slave carries a lot more meaning than subordinate. I replied to
> > someone else but later realized that the person sent me their reply
> > offlist, so my reply to them was also offlist. What I told them was,
> > back in college (decades ago), when I first mentioned "master/slave" in
> > conversation (I think it was about hard drives), a person in that
> > conversation stated that those were not very nice terms to use. I blew
> > it off back then, but after listening to more people, I found that
> > using "slave" even to describe a device is not something that people
> > care to hear about.
>
> That's cultural, but honestly I've never seen such a person. I still
> don't understand, why having secondary or subordinate object belittling
> the owned side by not providing it the same rights and freedom is OK,
> but slave/master objects are not. Where is the line?
>
>
> >
> > And in actuality, does one device actually enslave another device? I
> > think that terminology is misleading to begin with.
>
> As mentioned, I do like good clear terminology, and if it conveys the idea
> better, etc., then it's worth to try. And IMHO that's the right reasoning
> that should be behind. Otherwise, for almost every word we can find a person
> seeing something subjectively offensive or at least bad in it.
Wherever possible the kernel should use the same terminology as the current
standard in that area. Many of the master/slave references in the networking
code are for protocols based on IEEE 802 standards (unfortunately paywalled).
The current version of those standards do not use this kind of wording and the
standards committees are also actively working on inclusive language statemets.
As far as the use of master/slave for bonding, bridge, team etc, it
looks like Linux just invented using those terms since I don't see it
any other vendors implementations Cisco/Juniper/Arista/... Linux terms
are different than industry norms in networking, this is not a good
thing. But changing human expectations is hard.
On Mon, Jul 6, 2020 at 11:56 PM SeongJae Park <[email protected]> wrote:
>
> Hello,
>
> On Sat, 04 Jul 2020 13:02:51 -0700 Dan Williams <[email protected]> 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.
>
> I'm glad to see this patch.
>
> >
> > Cc: Jonathan Corbet <[email protected]>
> > Cc: Kees Cook <[email protected]>
> > Signed-off-by: Chris Mason <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > Signed-off-by: Dan Williams <[email protected]>
>
> Acked-by: SeongJae Park <[email protected]>
>
> > ---
> > 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'.
>
> I have submitted a couple of patches for automated encouragement of the the
> inclusive terms and those merged in the -next tree[1,2] now. Nonetheless, the
> version says only "please consider using 'denylist' and 'allowlist' instead of
> 'blacklist' and 'whitelist'" for now. I think we could add more terms in there
> based on this discussion. I could do that after this patch is merged, or you
> could do that yourself in the next spin of this patch. Please do whatever you
> feel comfort.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=7d0bea01dec27195d95d929c1ee49a4a74dd6671
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=95a94258ceb27052f00b7e51588a128d20bf05ed
>
Thank you for stepping up to take this on, much appreciated.
I think I'll leave it to you to fixup checkpatch after the final
version of this patch is merged. It may be as simple as "See section 4
'Naming' in coding-style for suggested replacements".
On Wed, 8 Jul 2020 00:12:03 -0700 Dan Williams <[email protected]> wrote:
> On Mon, Jul 6, 2020 at 11:56 PM SeongJae Park <[email protected]> wrote:
> >
> > Hello,
> >
> > On Sat, 04 Jul 2020 13:02:51 -0700 Dan Williams <[email protected]> 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.
> >
> > I'm glad to see this patch.
> >
> > >
> > > Cc: Jonathan Corbet <[email protected]>
> > > Cc: Kees Cook <[email protected]>
> > > Signed-off-by: Chris Mason <[email protected]>
> > > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > > Signed-off-by: Dan Williams <[email protected]>
> >
> > Acked-by: SeongJae Park <[email protected]>
> >
> > > ---
> > > 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'.
> >
> > I have submitted a couple of patches for automated encouragement of the the
> > inclusive terms and those merged in the -next tree[1,2] now. Nonetheless, the
> > version says only "please consider using 'denylist' and 'allowlist' instead of
> > 'blacklist' and 'whitelist'" for now. I think we could add more terms in there
> > based on this discussion. I could do that after this patch is merged, or you
> > could do that yourself in the next spin of this patch. Please do whatever you
> > feel comfort.
> >
> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=7d0bea01dec27195d95d929c1ee49a4a74dd6671
> > [2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=95a94258ceb27052f00b7e51588a128d20bf05ed
> >
>
> Thank you for stepping up to take this on, much appreciated.
>
> I think I'll leave it to you to fixup checkpatch after the final
> version of this patch is merged. It may be as simple as "See section 4
> 'Naming' in coding-style for suggested replacements".
Agreed, I will do that :)
Thanks,
SeongJae Park
On 08/07/2020 06:42, Stephen Hemminger wrote:
> On Tue, 7 Jul 2020 02:03:36 +0300
> Pavel Begunkov <[email protected]> wrote:
>
>> On 07/07/2020 01:28, Steven Rostedt wrote:
>>> On Tue, 7 Jul 2020 01:17:47 +0300
>>> Pavel Begunkov <[email protected]> wrote:
>>>
>>>> Totally agree with you! But do we care then whether two _devices_ or _objects_
>>>> are slave-master? Can't see how it fundamentally differs.
>>>
>>> The term slave carries a lot more meaning than subordinate. I replied to
>>> someone else but later realized that the person sent me their reply
>>> offlist, so my reply to them was also offlist. What I told them was,
>>> back in college (decades ago), when I first mentioned "master/slave" in
>>> conversation (I think it was about hard drives), a person in that
>>> conversation stated that those were not very nice terms to use. I blew
>>> it off back then, but after listening to more people, I found that
>>> using "slave" even to describe a device is not something that people
>>> care to hear about.
>>
>> That's cultural, but honestly I've never seen such a person. I still
>> don't understand, why having secondary or subordinate object belittling
>> the owned side by not providing it the same rights and freedom is OK,
>> but slave/master objects are not. Where is the line?
>>
>>
>>>
>>> And in actuality, does one device actually enslave another device? I
>>> think that terminology is misleading to begin with.
>>
>> As mentioned, I do like good clear terminology, and if it conveys the idea
>> better, etc., then it's worth to try. And IMHO that's the right reasoning
>> that should be behind. Otherwise, for almost every word we can find a person
>> seeing something subjectively offensive or at least bad in it.
>
> Wherever possible the kernel should use the same terminology as the current
> standard in that area. Many of the master/slave references in the networking
> code are for protocols based on IEEE 802 standards (unfortunately paywalled).
> The current version of those standards do not use this kind of wording and the
> standards committees are also actively working on inclusive language statemets.
>
> As far as the use of master/slave for bonding, bridge, team etc, it
> looks like Linux just invented using those terms since I don't see it
> any other vendors implementations Cisco/Juniper/Arista/... Linux terms
> are different than industry norms in networking, this is not a good
> thing. But changing human expectations is hard.
And that's a perfectly convincing argument for a change -- consistency makes
it easier to work with specs and code. I've never said anything against.
I care about arguments being logically sound, as yours are. And the author
neither provides such, nor IMHO actually helps the issues it raised.
--
Pavel Begunkov
On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams 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 <[email protected]>
> Cc: Kees Cook <[email protected]>
> Signed-off-by: Chris Mason <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Dan Williams <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
> ---
> 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
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Em Tue, 7 Jul 2020 01:58:21 +0200
Tibor Raschko <[email protected]> escreveu:
> > Allowlist/denylist terms are intuitive and action based which have a
> > globally uniform meaning.
>
> Nobody has a problem understanding "blacklist" and "whitelist". These
> are universally understood words even outside of computing. Claiming
> that we need clearer alternatives is smoke and mirrors.
Actually, as a non-native English speaker, the first time I saw
"<color>list", I had to do some research in order to understand what it
means :-)
That reminds me: what about "graylist"?
For coherency, if "blacklist/whitelist" won't be used anymore, an
alternative to graylist should also be provided.
Right now, it seems that only ACPI uses it:
$ git grep -i graylist
drivers/clocksource/acpi_pm.c:static void acpi_pm_check_graylist(struct pci_dev *dev)
drivers/clocksource/acpi_pm.c: acpi_pm_check_graylist);
drivers/clocksource/acpi_pm.c: acpi_pm_check_graylist);
Thanks,
Mauro
On 7/9/20 4:43 AM, Mauro Carvalho Chehab wrote:
> Em Tue, 7 Jul 2020 01:58:21 +0200
> Tibor Raschko <[email protected]> escreveu:
>
>>> Allowlist/denylist terms are intuitive and action based which have a
>>> globally uniform meaning.
>>
>> Nobody has a problem understanding "blacklist" and "whitelist". These
>> are universally understood words even outside of computing. Claiming
>> that we need clearer alternatives is smoke and mirrors.
>
> Actually, as a non-native English speaker, the first time I saw
> "<color>list", I had to do some research in order to understand what it
> means :-)
Thanks for the perspective. This is why we need clear and uniform words.
Our community is global. English isn't English everywhere either.
>
> That reminds me: what about "graylist"?
>
> For coherency, if "blacklist/whitelist" won't be used anymore, an
> alternative to graylist should also be provided.
>
> Right now, it seems that only ACPI uses it:
>
> $ git grep -i graylist
> drivers/clocksource/acpi_pm.c:static void acpi_pm_check_graylist(struct pci_dev *dev)
> drivers/clocksource/acpi_pm.c: acpi_pm_check_graylist);
> drivers/clocksource/acpi_pm.c: acpi_pm_check_graylist);
>
What is "graylist"? Does it mean in between allow/deny?
thanks,
-- Shuah
On Thu, Jul 09, 2020 at 10:01:18AM -0600, Shuah Khan wrote:
> On 7/9/20 4:43 AM, Mauro Carvalho Chehab wrote:
> > For coherency, if "blacklist/whitelist" won't be used anymore, an
> > alternative to graylist should also be provided.
> What is "graylist"? Does it mean in between allow/deny?
Yes. Typically it's used in situations where you don't want to deny
something but might for example want to do extra checks to verify that
things are OK.
On Thu, 2020-07-09 at 17:13 +0100, Mark Brown wrote:
> On Thu, Jul 09, 2020 at 10:01:18AM -0600, Shuah Khan wrote:
> > On 7/9/20 4:43 AM, Mauro Carvalho Chehab wrote:
> > > For coherency, if "blacklist/whitelist" won't be used anymore, an
> > > alternative to graylist should also be provided.
> > What is "graylist"? Does it mean in between allow/deny?
>
> Yes. Typically it's used in situations where you don't want to deny
> something but might for example want to do extra checks to verify
> that things are OK.
greylisting was originally pioneered by email. It's where you
initially reject an email but remember you did so and then let it
through if the retries follow an RFC mandated pattern. The technical
use spread from there since the technique (treating something as
untrusted until it proves trust) is very useful. It has its origin in
the English idiom "grey area" expressing doubt or lack of clarity.
The etymology of "grey area" is a grey area, but I'd bet it has to do
with not having the clarity of black and white ... but is equally
likely to be tied to Yin and Yang. Grey is also used in England to
describe the lack of clarity given by mist or fog (he woke up and saw
the world was very grey). I'd say we just leave it alone as too
distantly related to any problematic uses.
James
On Thu, 9 Jul 2020 17:13:51 +0100
Mark Brown <[email protected]> wrote:
> On Thu, Jul 09, 2020 at 10:01:18AM -0600, Shuah Khan wrote:
> > On 7/9/20 4:43 AM, Mauro Carvalho Chehab wrote:
>
> > > For coherency, if "blacklist/whitelist" won't be used anymore, an
> > > alternative to graylist should also be provided.
>
> > What is "graylist"? Does it mean in between allow/deny?
>
> Yes. Typically it's used in situations where you don't want to deny
> something but might for example want to do extra checks to verify that
> things are OK.
The only time I use greylist is for postgrey, that when an email comes
in, it will initially reject it, expecting the mail server to try
again, and the second time it lets it through. This does stop a lot of
spam, at the cost of waiting up to a few hours for email :-/
-- Steve
>>> Nobody has a problem understanding "blacklist" and "whitelist". These
>>> are universally understood words even outside of computing. Claiming
>>> that we need clearer alternatives is smoke and mirrors.
>>
>> Actually, as a non-native English speaker, the first time I saw
>> "<color>list", I had to do some research in order to understand what it
>> means :-)
You have to research and lookup *any* new words in a language when you see them
the first time. You'd also have to look up "allow" when seeing it for the first
time too.
> Thanks for the perspective. This is why we need clear and uniform words.
> Our community is global. English isn't English everywhere either.
>
So, the proposed alternatives "allowlist" and "denylist" are better because they
are not English but are in some kind of a global language? Your argumentation
doesn't seem to pan out.
The language in the Linux source is English, and in that language "blacklist"
has a meaning that is not limited to computing but is universal, irrespective of
the field of science, and is even used in everyday life. And this meaning isn't
associated with ethnic differences.
As I stated multiple times, I support removing all references to slavery and
masters. But trying to avoid "blacklist" is not just pointless but also useless.
The real problem is that "black" by itself already has a negative connotation.
so instead of blocking words unrelated to ethnicity, we should not call
Afro-Americans "blacks" anymore. The problem is that a group of people are
marked with "black" which is a word with black connotation. We should stop
calling them blacks, and that'd be a real solution (at least as far as the
language is concerned).
Raschko T.
On Mon, Jul 6, 2020 at 9:30 PM Dan Williams <[email protected]> wrote:
>
> On Sat, Jul 4, 2020 at 5:41 PM Kees Cook <[email protected]> wrote:
> >
> > On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams 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 <[email protected]>
> > > Cc: Kees Cook <[email protected]>
> > > Signed-off-by: Chris Mason <[email protected]>
> > > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > > Signed-off-by: Dan Williams <[email protected]>
> >
> > (nit: isn't this a Co-developed-by chain, not a SoB chain?)
> >
> > Acked-by: Kees Cook <[email protected]>
> >
> > Comments below...
> >
> > > ---
> > > 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'.
> >
> > Keeping "master" in a "master/slave" pairing (i.e. replacing only
> > "slave") seems incomplete to me. If "master" is paired with "slave", it
> > should be replaced too. Potential examples: 'primary', 'leader', 'principle',
> > 'controller', 'sender', 'initial'.
>
> Yes, this matches Andy's feedback, will add.
>
> > Similarly, for "whitelist/blacklist", "whitelist" needs to replaced when
> > "blacklist" has been. For example, seccomp documentation[1] uses
> > "allow-list" and "deny-list".
> >
> > [1] https://man7.org/linux/man-pages/man2/seccomp.2.html
>
> Oh, good to know will make that change.
Looks like that change already happened. And the new language is IMO
not vastly better than the old language. I'll send a patch.
Hi!
> +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.
I'd preffer to keep politics out of kernel.
> +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
So you are trying to blacklist colors. That's stupid.
> +socialization of 'black/white' to have the connotation of
> +'impermissible/permissible' does not support inclusion.
> +
> +Inclusion == global developer community efficiency.
It seems inclusion == reason to push politics and questionable patches
into kernel. That is opposite of efficiency.
:-(
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi Dan, and everybody,
Thank you for the patch.
On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams 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 <[email protected]>
> Cc: Kees Cook <[email protected]>
> Signed-off-by: Chris Mason <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Dan Williams <[email protected]>
> ---
> 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.
I've been pondering about this statement for several weeks now, sleeping
over it for far longer than I usually do. Despite this, I haven't been
able to shake off my initial feeling. Hence this reply.
This e-mail isn't challenging the proposed change to the kernel coding
style policy. That's a question that I believe has been widely discussed
behind closed doors, with also a few attempts to debate it publicly in
this mail thread. While that process causes me concern, that's a
separate topic, and I'm not questioning here the usefulness or
desirability of the change. I strongly believe in a welcoming and
inclusive kernel community, and in the need to translate these words
into actions.
The part that initially offended me is the claim that with this change
the "Linux kernel project has done its small part". I can't help feeling
this sounds hypocritical at best, and cynical at worst. Can we, as the
Linux kernel community, claim that taking this small and symbolic first
step would be enough ? I won't try to speak about the impact this coding
style policy change could have on people who today feel discriminated by
our practices, but I can only imagine that stating we "will have done
our part" could infuriate more than one, the same way I feel insulting
that companies raise rainbow flags during Pride week as a means of cheap
advertising.
Do we feel enough discomfort about our own racism to be compelled to
express public sympathy, but nowhere close enough to go further ? I feel
this would be fairly shameless, considering our community collaborates
with large companies that refuse to condemn hate speech. I don't know if
I'm the only one to see an elephant in the room here, but I think we
need to have a real debate about all the other actions we can take to
make a bigger difference.
> +
> +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
--
Regards,
Laurent Pinchart