[PATCH] CodingStyle: Inclusive Terminology

[PATCH] CodingStyle: Inclusive Terminology

[Dan Williams]

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

Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Chris Mason <clm@fb.clm>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
 Documentation/process/coding-style.rst          |   12 ++++
 Documentation/process/inclusive-terminology.rst |   64 +++++++++++++++++++++++
 Documentation/process/index.rst                 |    1 
 3 files changed, 77 insertions(+)
 create mode 100644 Documentation/process/inclusive-terminology.rst

diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
index 2657a55c6f12..4b15ab671089 100644
--- a/Documentation/process/coding-style.rst
+++ b/Documentation/process/coding-style.rst
@@ -319,6 +319,18 @@ If you are afraid to mix up your local variable names, you have another
 problem, which is called the function-growth-hormone-imbalance syndrome.
 See chapter 6 (Functions).
 
+For symbol names, avoid introducing new usage of the words 'slave' and
+'blacklist'. Recommended replacements for 'slave' are: 'secondary',
+'subordinate', 'replica', 'responder', 'follower', 'proxy', or
+'performer'.  Recommended replacements for blacklist are: 'blocklist' or
+'denylist'.
+
+Exceptions for introducing new usage is to maintain a userspace ABI, or
+when updating code for an existing (as of 2020) hardware or protocol
+specification that mandates those terms. For new specifications consider
+translating specification usage of the terminology to the kernel coding
+standard where possible. See :ref:`process/inclusive-terminology.rst
+<inclusiveterminology>` for details.
 
 5) Typedefs
 -----------
diff --git a/Documentation/process/inclusive-terminology.rst b/Documentation/process/inclusive-terminology.rst
new file mode 100644
index 000000000000..a8eb26690eb4
--- /dev/null
+++ b/Documentation/process/inclusive-terminology.rst
@@ -0,0 +1,64 @@
+.. _inclusiveterminology:
+
+Linux kernel inclusive terminology
+==================================
+
+The Linux kernel is a global software project, and in 2020 there was a
+global reckoning on race relations that caused many organizations to
+re-evaluate their policies and practices relative to the inclusion of
+people of African descent. This document describes why the 'Naming'
+section in :ref:`process/coding-style.rst <codingstyle>` recommends
+avoiding usage of 'slave' and 'blacklist' in new additions to the Linux
+kernel.
+
+On the triviality of replacing words
+====================================
+
+The African slave trade was a brutal system of human misery deployed at
+global scale. Some word choice decisions in a modern software project
+does next to nothing to compensate for that legacy. So why put any
+effort into something so trivial in comparison? Because the goal is not
+to repair, or erase the past. The goal is to maximize availability and
+efficiency of the global developer community to participate in the Linux
+kernel development process.
+
+Word choice and developer efficiency
+====================================
+
+Why does any software project go through the trouble of developing a
+document like :ref:`process/coding-style.rst <codingstyle>`? It does so
+because a common coding style maximizes the efficiency of both
+maintainers and developers. Developers learn common design patterns and
+idiomatic expressions while maintainers can spot deviations from those
+norms. Even non-compliant whitespace is considered a leading indicator
+to deeper problems in a patchset. Coding style violations are known to
+take a maintainer "out of the zone" of reviewing code. Maintainers are
+also sensitive to word choice across specifications and often choose to
+deploy Linux terminology to replace non-idiomatic word-choice in a
+specification.
+
+Non-inclusive terminology has that same distracting effect which is why
+it is a style issue for Linux, it injures developer efficiency.
+
+Of course it is around this point someone jumps in with an etymological
+argument about why people should not be offended. Etymological arguments
+do not scale. The scope and pace of Linux to reach new developers
+exceeds the ability of historical terminology defenders to describe "no,
+not that connotation". The revelation of 2020 was that black voices were
+heard on a global scale and the Linux kernel project has done its small
+part to answer that call as it wants black voices, among all voices, in
+its developer community.
+
+Really, 'blacklist' too?
+========================
+
+While 'slave' has a direct connection to human suffering the etymology
+of 'blacklist' is devoid of a historical racial connection. However, one
+thought exercise is to consider replacing 'blacklist/whitelist' with
+'redlist/greenlist'. Realize that the replacement only makes sense if
+you have been socialized with the concepts that 'red/green' implies
+'stop/go'. Colors to represent a policy requires an indirection. The
+socialization of 'black/white' to have the connotation of
+'impermissible/permissible' does not support inclusion.
+
+Inclusion == global developer community efficiency.
diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
index f07c9250c3ac..ed861f6f8d25 100644
--- a/Documentation/process/index.rst
+++ b/Documentation/process/index.rst
@@ -27,6 +27,7 @@ Below are the essential guides that every developer should read.
    submitting-patches
    programming-language
    coding-style
+   inclusive-terminology
    maintainer-pgp-guide
    email-clients
    kernel-enforcement-statement

Re: [PATCH] CodingStyle: Inclusive Terminology

[Randy Dunlap]

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 <corbet@lwn.net>
> Cc: Kees Cook <keescook@chromium.org>
> Signed-off-by: Chris Mason <clm@fb.clm>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
>  Documentation/process/coding-style.rst          |   12 ++++
>  Documentation/process/inclusive-terminology.rst |   64 +++++++++++++++++++++++
>  Documentation/process/index.rst                 |    1 
>  3 files changed, 77 insertions(+)
>  create mode 100644 Documentation/process/inclusive-terminology.rst
> 
> diff --git a/Documentation/process/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 <rdunlap@infradead.org>


thanks.
-- 
~Randy

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Dave Airlie]

'. 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.

Re: [Tech-board-discuss] [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Kees Cook]

On Sat, Jul 04, 2020 at 08:10:33PM -0400, Matthew Wilcox wrote:
> Left-right tree makes no sense. It doesn't distinguish the rbtree from its
> predecessor the avl tree.  I don't think it's helpful to rename a standard
> piece of computing terminology unless it's actually hurting us to have it.
> Obviously if it were called a "master-slave" tree, I would be in favour of
> renaming it.

(No one has suggested renaming red/black trees, so I think the
slippery-slope argument can be set aside here.)

As for the actual proposal on white/black-list, I've always been annoyed
by the poor description it provides (and I get to see it A LOT being
the seccomp maintainer). I welcome allow/deny-list (though the change is
not new for seccomp -- the man pages were updated last year (thanks
mkerrisk). :)

-- 
Kees Cook

Re: [Tech-board-discuss] [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Randy Dunlap]

On 7/4/20 6:10 PM, Kees Cook wrote:
> On Sat, Jul 04, 2020 at 08:10:33PM -0400, Matthew Wilcox wrote:
>> Left-right tree makes no sense. It doesn't distinguish the rbtree from its
>> predecessor the avl tree.  I don't think it's helpful to rename a standard
>> piece of computing terminology unless it's actually hurting us to have it.
>> Obviously if it were called a "master-slave" tree, I would be in favour of
>> renaming it.
> 
> (No one has suggested renaming red/black trees, so I think the
> slippery-slope argument can be set aside here.)

Did you read this message?

https://lore.kernel.org/ksummit-discuss/CAPM=9ty0tiL_qM_UFv0S0VtARKz_f-Anngc+amDM5LjGAHazhA@mail.gmail.com/

> As for the actual proposal on white/black-list, I've always been annoyed
> by the poor description it provides (and I get to see it A LOT being
> the seccomp maintainer). I welcome allow/deny-list (though the change is
> not new for seccomp -- the man pages were updated last year (thanks
> mkerrisk). :)
> 


-- 
~Randy

Re: [Ksummit-discuss] [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Michael Kerrisk (man-pages)]

On 7/5/20 3:10 AM, Kees Cook wrote:
> On Sat, Jul 04, 2020 at 08:10:33PM -0400, Matthew Wilcox wrote:
>> Left-right tree makes no sense. It doesn't distinguish the rbtree from its
>> predecessor the avl tree.  I don't think it's helpful to rename a standard
>> piece of computing terminology unless it's actually hurting us to have it.
>> Obviously if it were called a "master-slave" tree, I would be in favour of
>> renaming it.
> 
> (No one has suggested renaming red/black trees, so I think the
> slippery-slope argument can be set aside here.)
> 
> As for the actual proposal on white/black-list, I've always been annoyed
> by the poor description it provides (and I get to see it A LOT being
> the seccomp maintainer). I welcome allow/deny-list (though the change is
> not new for seccomp -- the man pages were updated last year (thanks
> mkerrisk). :)

Actually, the manual pages are ahead of the game only thanks to
a nice presentation last year @OSS from Stephen Kenigbolo :-).


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [Ksummit-discuss] [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Kees Cook]

On Mon, Jul 06, 2020 at 01:15:38PM +0200, Michael Kerrisk (man-pages) wrote:
> On 7/5/20 3:10 AM, Kees Cook wrote:
> > On Sat, Jul 04, 2020 at 08:10:33PM -0400, Matthew Wilcox wrote:
> >> Left-right tree makes no sense. It doesn't distinguish the rbtree from its
> >> predecessor the avl tree.  I don't think it's helpful to rename a standard
> >> piece of computing terminology unless it's actually hurting us to have it.
> >> Obviously if it were called a "master-slave" tree, I would be in favour of
> >> renaming it.
> > 
> > (No one has suggested renaming red/black trees, so I think the
> > slippery-slope argument can be set aside here.)
> > 
> > As for the actual proposal on white/black-list, I've always been annoyed
> > by the poor description it provides (and I get to see it A LOT being
> > the seccomp maintainer). I welcome allow/deny-list (though the change is
> > not new for seccomp -- the man pages were updated last year (thanks
> > mkerrisk). :)
> 
> Actually, the manual pages are ahead of the game only thanks to
> a nice presentation last year @OSS from Stephen Kenigbolo :-).

Ah-ha, cool. I think I found it here:
https://www.youtube.com/watch?v=XtS_t3FHWe0

-- 
Kees Cook

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Dave Airlie]

On Sun, 5 Jul 2020 at 10:10, Matthew Wilcox <willy6545@gmail.com> wrote:
>
> Erm, red-black trees don't have a derivation from gambling terminology either. The wikipedia article says:
>
> In a 1978 paper, "A Dichromatic Framework for Balanced Trees",[6] Leonidas J. Guibas and Robert Sedgewick derived the red-black tree from the symmetric binary B-tree.[7] The color "red" was chosen because it was the best-looking color produced by the color laser printer available to the authors while working at Xerox PARC.[8] Another response from Guibas states that it was because of the red and black pens available to them to draw the trees.[9]
>
> Left-right tree makes no sense. It doesn't distinguish the rbtree from its predecessor the avl tree.  I don't think it's helpful to rename a standard piece of computing terminology unless it's actually hurting us to have it. Obviously if it were called a "master-slave" tree, I would be in favour of renaming it.

As I said "it means nothing if you've never interacted with gambling
culture," red black in the context of the trees as zero meaning other
than as a name to find it on the internet, Search for that name enough
and you will undoubtedly be getting ads for online roulette sites
within hours, if you have a problem gambling past, this might not be
the desired effect you'd want.

The reasons something was named a particular thing can and will be
different from what a societal context for them means now, and I
believe it's more important to worry about current societal contexts
than legacy historical namings. I'm not seriously suggesting we rename
red-black trees, but if someone who had a problematic gambling
background had issues with them I'd definitely be open for considering
it.

Dave.

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 705 bytes --]

Hi Dan,

On Sat, 04 Jul 2020 13:02:51 -0700 Dan Williams <dan.j.williams@intel.com> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Dave Airlie]

On Sun, 5 Jul 2020 at 06:45, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Dan,
>
> On Sat, 04 Jul 2020 13:02:51 -0700 Dan Williams <dan.j.williams@intel.com> 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.

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2019 bytes --]

Hi Dave,

On Sun, 5 Jul 2020 09:34:57 +1000 Dave Airlie <airlied@gmail.com> wrote:
>
> On Sun, 5 Jul 2020 at 06:45, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Sat, 04 Jul 2020 13:02:51 -0700 Dan Williams <dan.j.williams@intel.com> 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
users@linux.kernel.org mailing list.  Also, I made no statement about
my support (or otherwise) for any of this.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Dave Airlie]

On Sun, 5 Jul 2020 at 12:12, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Dave,
>
> On Sun, 5 Jul 2020 09:34:57 +1000 Dave Airlie <airlied@gmail.com> wrote:
> >
> > On Sun, 5 Jul 2020 at 06:45, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > On Sat, 04 Jul 2020 13:02:51 -0700 Dan Williams <dan.j.williams@intel.com> 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.

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[James Bottomley]

On Sun, 2020-07-05 at 12:56 +1000, Dave Airlie wrote:
> On Sun, 5 Jul 2020 at 12:12, Stephen Rothwell <sfr@canb.auug.org.au>
> 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

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 476 bytes --]

Hi Dave,

On Sun, 5 Jul 2020 12:56:23 +1000 Dave Airlie <airlied@gmail.com> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Olof Johansson]

On Sat, Jul 4, 2020 at 1:19 PM Dan Williams <dan.j.williams@intel.com> wrote:
>
> Recent events have prompted a Linux position statement on inclusive
> terminology. Given that Linux maintains a coding-style and its own
> idiomatic set of terminology here is a proposal to answer the call to
> replace non-inclusive terminology.
>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Kees Cook <keescook@chromium.org>
> Signed-off-by: Chris Mason <clm@fb.clm>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>

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 <olof@lixom.net>

Or Acked-by, or whatever other label you prefer to use to show
agreement and support.


-Olof

Re: [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[James Bottomley]

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

Re: [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Joe Perches]

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.

Re: [Ksummit-discuss] [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Dave Airlie]

On Sun, 5 Jul 2020 at 07:25, James Bottomley
<James.Bottomley@hansenpartnership.com> 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.

Re: [Ksummit-discuss] [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Joe Perches]

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?

Re: [Ksummit-discuss] [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[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

Re: [Ksummit-discuss] [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[opal hart]

On Sun, 5 Jul 2020 09:39:29 +1000
Dave Airlie <airlied@gmail.com> 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>

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Dave Airlie]

On Sun, 5 Jul 2020 at 06:19, Dan Williams <dan.j.williams@intel.com> wrote:
>
> Recent events have prompted a Linux position statement on inclusive
> terminology. Given that Linux maintains a coding-style and its own
> idiomatic set of terminology here is a proposal to answer the call to
> replace non-inclusive terminology.
>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Kees Cook <keescook@chromium.org>
> Signed-off-by: Chris Mason <clm@fb.clm>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>

I'm sure the language could be fine tuned, but the intent is something
I support.

Acked-by: Dave Airlie <airlied@redhat.com>

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

Re: [PATCH] CodingStyle: Inclusive Terminology

[Kees Cook]

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 <corbet@lwn.net>
> Cc: Kees Cook <keescook@chromium.org>
> Signed-off-by: Chris Mason <clm@fb.clm>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>

(nit: isn't this a Co-developed-by chain, not a SoB chain?)

Acked-by: Kees Cook <keescook@chromium.org>

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

Re: [PATCH] CodingStyle: Inclusive Terminology

[Dan Williams]

On Sat, Jul 4, 2020 at 5:41 PM Kees Cook <keescook@chromium.org> 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 <corbet@lwn.net>
> > Cc: Kees Cook <keescook@chromium.org>
> > Signed-off-by: Chris Mason <clm@fb.clm>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>
> (nit: isn't this a Co-developed-by chain, not a SoB chain?)
>
> Acked-by: Kees Cook <keescook@chromium.org>
>
> 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.

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Andy Lutomirski]

On Mon, Jul 6, 2020 at 9:30 PM Dan Williams <dan.j.williams@intel.com> wrote:
>
> On Sat, Jul 4, 2020 at 5:41 PM Kees Cook <keescook@chromium.org> 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 <corbet@lwn.net>
> > > Cc: Kees Cook <keescook@chromium.org>
> > > Signed-off-by: Chris Mason <clm@fb.clm>
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> >
> > (nit: isn't this a Co-developed-by chain, not a SoB chain?)
> >
> > Acked-by: Kees Cook <keescook@chromium.org>
> >
> > 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.

Re: [PATCH] CodingStyle: Inclusive Terminology

[Willy Tarreau]

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

Re: [PATCH] CodingStyle: Inclusive Terminology

[Daniel Palmer]

Hi Willy,

On Sun, 5 Jul 2020 at 13:55, Willy Tarreau <w@1wt.eu> 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

Re: [PATCH] CodingStyle: Inclusive Terminology

[Chris Mason]

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

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Laurent Pinchart]

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

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Chris Mason]

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

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Mike Rapoport]

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
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

-- 
Sincerely yours,
Mike.

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Dan Williams]

On Mon, Jul 6, 2020 at 9:07 AM Mike Rapoport <rppt@linux.ibm.com> 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.

Re: [PATCH] CodingStyle: Inclusive Terminology

[Arvind Sankar]

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.

Re: [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Steven Rostedt]

On Mon, 6 Jul 2020 11:22:10 -0400
Arvind Sankar <nivedita@alum.mit.edu> 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

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 7174 bytes --]

On Sat, Jul 04 2020, Matthew Wilcox wrote:

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

Ugh.  Please, no.  "device" doesn't mean anything, in that you can use
it to refer to any thing.  (i.e. it is almost semantically equivalent to
"thing").
Look in /sys/devices.  Everything in there is a device, and (nearly)
every thing is in there.

NeilBrown

>
> On Sat., Jul. 4, 2020, 16:19 Dan Williams, <dan.j.williams@intel.com> wrote:
>
>> Recent events have prompted a Linux position statement on inclusive
>> terminology. Given that Linux maintains a coding-style and its own
>> idiomatic set of terminology here is a proposal to answer the call to
>> replace non-inclusive terminology.
>>
>> Cc: Jonathan Corbet <corbet@lwn.net>
>> Cc: Kees Cook <keescook@chromium.org>
>> Signed-off-by: Chris Mason <clm@fb.clm>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>> ---
>>  Documentation/process/coding-style.rst          |   12 ++++
>>  Documentation/process/inclusive-terminology.rst |   64
>> +++++++++++++++++++++++
>>  Documentation/process/index.rst                 |    1
>>  3 files changed, 77 insertions(+)
>>  create mode 100644 Documentation/process/inclusive-terminology.rst
>>
>> diff --git a/Documentation/process/coding-style.rst
>> b/Documentation/process/coding-style.rst
>> index 2657a55c6f12..4b15ab671089 100644
>> --- a/Documentation/process/coding-style.rst
>> +++ b/Documentation/process/coding-style.rst
>> @@ -319,6 +319,18 @@ If you are afraid to mix up your local variable
>> names, you have another
>>  problem, which is called the function-growth-hormone-imbalance syndrome.
>>  See chapter 6 (Functions).
>>
>> +For symbol names, avoid introducing new usage of the words 'slave' and
>> +'blacklist'. Recommended replacements for 'slave' are: 'secondary',
>> +'subordinate', 'replica', 'responder', 'follower', 'proxy', or
>> +'performer'.  Recommended replacements for blacklist are: 'blocklist' or
>> +'denylist'.
>> +
>> +Exceptions for introducing new usage is to maintain a userspace ABI, or
>> +when updating code for an existing (as of 2020) hardware or protocol
>> +specification that mandates those terms. For new specifications consider
>> +translating specification usage of the terminology to the kernel coding
>> +standard where possible. See :ref:`process/inclusive-terminology.rst
>> +<inclusiveterminology>` for details.
>>
>>  5) Typedefs
>>  -----------
>> diff --git a/Documentation/process/inclusive-terminology.rst
>> b/Documentation/process/inclusive-terminology.rst
>> new file mode 100644
>> index 000000000000..a8eb26690eb4
>> --- /dev/null
>> +++ b/Documentation/process/inclusive-terminology.rst
>> @@ -0,0 +1,64 @@
>> +.. _inclusiveterminology:
>> +
>> +Linux kernel inclusive terminology
>> +==================================
>> +
>> +The Linux kernel is a global software project, and in 2020 there was a
>> +global reckoning on race relations that caused many organizations to
>> +re-evaluate their policies and practices relative to the inclusion of
>> +people of African descent. This document describes why the 'Naming'
>> +section in :ref:`process/coding-style.rst <codingstyle>` recommends
>> +avoiding usage of 'slave' and 'blacklist' in new additions to the Linux
>> +kernel.
>> +
>> +On the triviality of replacing words
>> +====================================
>> +
>> +The African slave trade was a brutal system of human misery deployed at
>> +global scale. Some word choice decisions in a modern software project
>> +does next to nothing to compensate for that legacy. So why put any
>> +effort into something so trivial in comparison? Because the goal is not
>> +to repair, or erase the past. The goal is to maximize availability and
>> +efficiency of the global developer community to participate in the Linux
>> +kernel development process.
>> +
>> +Word choice and developer efficiency
>> +====================================
>> +
>> +Why does any software project go through the trouble of developing a
>> +document like :ref:`process/coding-style.rst <codingstyle>`? It does so
>> +because a common coding style maximizes the efficiency of both
>> +maintainers and developers. Developers learn common design patterns and
>> +idiomatic expressions while maintainers can spot deviations from those
>> +norms. Even non-compliant whitespace is considered a leading indicator
>> +to deeper problems in a patchset. Coding style violations are known to
>> +take a maintainer "out of the zone" of reviewing code. Maintainers are
>> +also sensitive to word choice across specifications and often choose to
>> +deploy Linux terminology to replace non-idiomatic word-choice in a
>> +specification.
>> +
>> +Non-inclusive terminology has that same distracting effect which is why
>> +it is a style issue for Linux, it injures developer efficiency.
>> +
>> +Of course it is around this point someone jumps in with an etymological
>> +argument about why people should not be offended. Etymological arguments
>> +do not scale. The scope and pace of Linux to reach new developers
>> +exceeds the ability of historical terminology defenders to describe "no,
>> +not that connotation". The revelation of 2020 was that black voices were
>> +heard on a global scale and the Linux kernel project has done its small
>> +part to answer that call as it wants black voices, among all voices, in
>> +its developer community.
>> +
>> +Really, 'blacklist' too?
>> +========================
>> +
>> +While 'slave' has a direct connection to human suffering the etymology
>> +of 'blacklist' is devoid of a historical racial connection. However, one
>> +thought exercise is to consider replacing 'blacklist/whitelist' with
>> +'redlist/greenlist'. Realize that the replacement only makes sense if
>> +you have been socialized with the concepts that 'red/green' implies
>> +'stop/go'. Colors to represent a policy requires an indirection. The
>> +socialization of 'black/white' to have the connotation of
>> +'impermissible/permissible' does not support inclusion.
>> +
>> +Inclusion == global developer community efficiency.
>> diff --git a/Documentation/process/index.rst
>> b/Documentation/process/index.rst
>> index f07c9250c3ac..ed861f6f8d25 100644
>> --- a/Documentation/process/index.rst
>> +++ b/Documentation/process/index.rst
>> @@ -27,6 +27,7 @@ Below are the essential guides that every developer
>> should read.
>>     submitting-patches
>>     programming-language
>>     coding-style
>> +   inclusive-terminology
>>     maintainer-pgp-guide
>>     email-clients
>>     kernel-enforcement-statement
>>
>> _______________________________________________
>> Ksummit-discuss mailing list
>> Ksummit-discuss@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 7174 bytes --]

On Sat, Jul 04 2020, Matthew Wilcox wrote:

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

Ugh.  Please, no.  "device" doesn't mean anything, in that you can use
it to refer to any thing.  (i.e. it is almost semantically equivalent to
"thing").
Look in /sys/devices.  Everything in there is a device, and (nearly)
every thing is in there.

NeilBrown

>
> On Sat., Jul. 4, 2020, 16:19 Dan Williams, <dan.j.williams@intel.com> wrote:
>
>> Recent events have prompted a Linux position statement on inclusive
>> terminology. Given that Linux maintains a coding-style and its own
>> idiomatic set of terminology here is a proposal to answer the call to
>> replace non-inclusive terminology.
>>
>> Cc: Jonathan Corbet <corbet@lwn.net>
>> Cc: Kees Cook <keescook@chromium.org>
>> Signed-off-by: Chris Mason <clm@fb.clm>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>> ---
>>  Documentation/process/coding-style.rst          |   12 ++++
>>  Documentation/process/inclusive-terminology.rst |   64
>> +++++++++++++++++++++++
>>  Documentation/process/index.rst                 |    1
>>  3 files changed, 77 insertions(+)
>>  create mode 100644 Documentation/process/inclusive-terminology.rst
>>
>> diff --git a/Documentation/process/coding-style.rst
>> b/Documentation/process/coding-style.rst
>> index 2657a55c6f12..4b15ab671089 100644
>> --- a/Documentation/process/coding-style.rst
>> +++ b/Documentation/process/coding-style.rst
>> @@ -319,6 +319,18 @@ If you are afraid to mix up your local variable
>> names, you have another
>>  problem, which is called the function-growth-hormone-imbalance syndrome.
>>  See chapter 6 (Functions).
>>
>> +For symbol names, avoid introducing new usage of the words 'slave' and
>> +'blacklist'. Recommended replacements for 'slave' are: 'secondary',
>> +'subordinate', 'replica', 'responder', 'follower', 'proxy', or
>> +'performer'.  Recommended replacements for blacklist are: 'blocklist' or
>> +'denylist'.
>> +
>> +Exceptions for introducing new usage is to maintain a userspace ABI, or
>> +when updating code for an existing (as of 2020) hardware or protocol
>> +specification that mandates those terms. For new specifications consider
>> +translating specification usage of the terminology to the kernel coding
>> +standard where possible. See :ref:`process/inclusive-terminology.rst
>> +<inclusiveterminology>` for details.
>>
>>  5) Typedefs
>>  -----------
>> diff --git a/Documentation/process/inclusive-terminology.rst
>> b/Documentation/process/inclusive-terminology.rst
>> new file mode 100644
>> index 000000000000..a8eb26690eb4
>> --- /dev/null
>> +++ b/Documentation/process/inclusive-terminology.rst
>> @@ -0,0 +1,64 @@
>> +.. _inclusiveterminology:
>> +
>> +Linux kernel inclusive terminology
>> +==================================
>> +
>> +The Linux kernel is a global software project, and in 2020 there was a
>> +global reckoning on race relations that caused many organizations to
>> +re-evaluate their policies and practices relative to the inclusion of
>> +people of African descent. This document describes why the 'Naming'
>> +section in :ref:`process/coding-style.rst <codingstyle>` recommends
>> +avoiding usage of 'slave' and 'blacklist' in new additions to the Linux
>> +kernel.
>> +
>> +On the triviality of replacing words
>> +====================================
>> +
>> +The African slave trade was a brutal system of human misery deployed at
>> +global scale. Some word choice decisions in a modern software project
>> +does next to nothing to compensate for that legacy. So why put any
>> +effort into something so trivial in comparison? Because the goal is not
>> +to repair, or erase the past. The goal is to maximize availability and
>> +efficiency of the global developer community to participate in the Linux
>> +kernel development process.
>> +
>> +Word choice and developer efficiency
>> +====================================
>> +
>> +Why does any software project go through the trouble of developing a
>> +document like :ref:`process/coding-style.rst <codingstyle>`? It does so
>> +because a common coding style maximizes the efficiency of both
>> +maintainers and developers. Developers learn common design patterns and
>> +idiomatic expressions while maintainers can spot deviations from those
>> +norms. Even non-compliant whitespace is considered a leading indicator
>> +to deeper problems in a patchset. Coding style violations are known to
>> +take a maintainer "out of the zone" of reviewing code. Maintainers are
>> +also sensitive to word choice across specifications and often choose to
>> +deploy Linux terminology to replace non-idiomatic word-choice in a
>> +specification.
>> +
>> +Non-inclusive terminology has that same distracting effect which is why
>> +it is a style issue for Linux, it injures developer efficiency.
>> +
>> +Of course it is around this point someone jumps in with an etymological
>> +argument about why people should not be offended. Etymological arguments
>> +do not scale. The scope and pace of Linux to reach new developers
>> +exceeds the ability of historical terminology defenders to describe "no,
>> +not that connotation". The revelation of 2020 was that black voices were
>> +heard on a global scale and the Linux kernel project has done its small
>> +part to answer that call as it wants black voices, among all voices, in
>> +its developer community.
>> +
>> +Really, 'blacklist' too?
>> +========================
>> +
>> +While 'slave' has a direct connection to human suffering the etymology
>> +of 'blacklist' is devoid of a historical racial connection. However, one
>> +thought exercise is to consider replacing 'blacklist/whitelist' with
>> +'redlist/greenlist'. Realize that the replacement only makes sense if
>> +you have been socialized with the concepts that 'red/green' implies
>> +'stop/go'. Colors to represent a policy requires an indirection. The
>> +socialization of 'black/white' to have the connotation of
>> +'impermissible/permissible' does not support inclusion.
>> +
>> +Inclusion == global developer community efficiency.
>> diff --git a/Documentation/process/index.rst
>> b/Documentation/process/index.rst
>> index f07c9250c3ac..ed861f6f8d25 100644
>> --- a/Documentation/process/index.rst
>> +++ b/Documentation/process/index.rst
>> @@ -27,6 +27,7 @@ Below are the essential guides that every developer
>> should read.
>>     submitting-patches
>>     programming-language
>>     coding-style
>> +   inclusive-terminology
>>     maintainer-pgp-guide
>>     email-clients
>>     kernel-enforcement-statement
>>
>> _______________________________________________
>> Ksummit-discuss mailing list
>> Ksummit-discuss@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Greg Kroah-Hartman]

On Mon, Jul 06, 2020 at 05:10:37PM +1000, NeilBrown wrote:
> On Sat, Jul 04 2020, Matthew Wilcox wrote:
> 
> > Another suggestion for "slave" replacement should be "device". This is in
> > the context of the w1 bus which is by far the largest user of the
> > master/slave terminology in the kernel.
> 
> Ugh.  Please, no.  "device" doesn't mean anything, in that you can use
> it to refer to any thing.  (i.e. it is almost semantically equivalent to
> "thing").

Context is everything, you can have a "controller" and a "device" that
the controller controls.  These are common terms in many specs today,
look at the USB spec for an example of these terms being used in this
way for many decades.

So while the term might be generic, like the word it is replacing, it
makes sense when used in the context it will show up in, so it is a good
replacement in many instances.

thanks,

greg k-h

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Geert Uytterhoeven]

On Mon, Jul 6, 2020 at 9:22 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Mon, Jul 06, 2020 at 05:10:37PM +1000, NeilBrown wrote:
> > On Sat, Jul 04 2020, Matthew Wilcox wrote:
> > > Another suggestion for "slave" replacement should be "device". This is in
> > > the context of the w1 bus which is by far the largest user of the
> > > master/slave terminology in the kernel.

W1 the largest? Really?

> >
> > Ugh.  Please, no.  "device" doesn't mean anything, in that you can use
> > it to refer to any thing.  (i.e. it is almost semantically equivalent to
> > "thing").
>
> Context is everything, you can have a "controller" and a "device" that
> the controller controls.  These are common terms in many specs today,

A "controller" is also any block of electronics that performs a function
involving a state machine.
So for SPI and I2C, we'll have Linux drivers talking to an "SPI controller
controller", an "SPI device controller", an "I2C controller controller",
and an "I2C device controller".
For W1, Linux is still limited to supporting "W1 controller controllers",
but supporting "W1 device controllers" might be just beyond the horizon...

> look at the USB spec for an example of these terms being used in this
> way for many decades.

And when does the "gadget" enter the show? ;-)

P.S. In Dutch, we just assimilate all English technical words, and
     they'll only have that specific meaning.  E.g. if someone
     talks about the "cloud", even lay people know they're not talking
     about those things that may ruin your holiday outside.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Greg Kroah-Hartman]

On Mon, Jul 06, 2020 at 09:53:55AM +0200, Geert Uytterhoeven wrote:
> On Mon, Jul 6, 2020 at 9:22 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > look at the USB spec for an example of these terms being used in this
> > way for many decades.
> 
> And when does the "gadget" enter the show? ;-)

It doesn't, as the USB spec does not describe that in any reasonable way
for us to use when dealing with drivers for both "types" of devices.  So
we came up with the word "gadget" on purpose to be able to talk about
those things in a specific manner.

thanks,

greg k-h

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Matthew Wilcox]

On Mon, Jul 6, 2020 at 3:54 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Mon, Jul 6, 2020 at 9:22 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Mon, Jul 06, 2020 at 05:10:37PM +1000, NeilBrown wrote:
> > > On Sat, Jul 04 2020, Matthew Wilcox wrote:
> > > > Another suggestion for "slave" replacement should be "device". This is in
> > > > the context of the w1 bus which is by far the largest user of the
> > > > master/slave terminology in the kernel.
>
> W1 the largest? Really?

I should have said "most obnoxious".  They managed to put that terminology in
filenames, eg drivers/w1/slaves and Documentation/w1/slaves

In terms of number of lines of code using the word, it's only seventh
in drivers/:

$ for i in drivers/*; do c=$(find $i -type f |xargs grep slave |wc
-l); echo "$c $i"; done |sort -rn |head
5218 drivers/net
1341 drivers/dma
988 drivers/i2c
695 drivers/gpu
666 drivers/soundwire
665 drivers/spi
559 drivers/w1
461 drivers/infiniband
389 drivers/media
301 drivers/scsi

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Joe Perches]

On Mon, 2020-07-06 at 08:51 -0400, Matthew Wilcox wrote:
[]
> In terms of number of lines of code using the word, it's only seventh
> in drivers/:
> 
> $ for i in drivers/*; do c=$(find $i -type f |xargs grep slave |wc
> -l); echo "$c $i"; done |sort -rn |head
> 5218 drivers/net
> 1341 drivers/dma
> 988 drivers/i2c
> 695 drivers/gpu
> 666 drivers/soundwire
> 665 drivers/spi
> 559 drivers/w1
> 461 drivers/infiniband
> 389 drivers/media
> 301 drivers/scsi

I get rather different and much lower numbers

$ git grep -i -w slave drivers | \
  cut -f1,2 -d/ | uniq -c | sort -rn | head -20 | cat -n
     1	   3091 drivers/net
     2	    654 drivers/i2c
     3	    595 drivers/soundwire
     4	    483 drivers/dma
     5	    284 drivers/infiniband
     6	    269 drivers/gpu
     7	    198 drivers/media
     8	    192 drivers/fsi
     9	    174 drivers/spi
    10	    131 drivers/ata
    11	    111 drivers/w1
    12	    110 drivers/staging
    13	     89 drivers/iio
    14	     71 drivers/usb
    15	     60 drivers/mfd
    16	     53 drivers/soc
    17	     52 drivers/tty
    18	     32 drivers/vme
    19	     32 drivers/mtd
    20	     28 drivers/ide

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Matthew Wilcox]

On Mon, Jul 6, 2020 at 8:59 AM Joe Perches <joe@perches.com> wrote:
> On Mon, 2020-07-06 at 08:51 -0400, Matthew Wilcox wrote:
> > In terms of number of lines of code using the word, it's only seventh
> > in drivers/:
> >
> > $ for i in drivers/*; do c=$(find $i -type f |xargs grep slave |wc
> > -l); echo "$c $i"; done |sort -rn |head
> > 5218 drivers/net
> > 1341 drivers/dma
> > 988 drivers/i2c
> > 695 drivers/gpu
> > 666 drivers/soundwire
> > 665 drivers/spi
> > 559 drivers/w1
> > 461 drivers/infiniband
> > 389 drivers/media
> > 301 drivers/scsi
>
> I get rather different and much lower numbers
>
> $ git grep -i -w slave drivers | \
>   cut -f1,2 -d/ | uniq -c | sort -rn | head -20 | cat -n

That's because you're using grep -w which excludes, for example,
slave_configure in drivers/scsi.

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Joe Perches]

On Mon, 2020-07-06 at 09:04 -0400, Matthew Wilcox wrote:
> On Mon, Jul 6, 2020 at 8:59 AM Joe Perches <joe@perches.com> wrote:
> > On Mon, 2020-07-06 at 08:51 -0400, Matthew Wilcox wrote:
> > > In terms of number of lines of code using the word, it's only seventh
> > > in drivers/:
> > > 
> > > $ for i in drivers/*; do c=$(find $i -type f |xargs grep slave |wc
> > > -l); echo "$c $i"; done |sort -rn |head
> > > 5218 drivers/net
> > > 1341 drivers/dma
> > > 988 drivers/i2c
> > > 695 drivers/gpu
> > > 666 drivers/soundwire
> > > 665 drivers/spi
> > > 559 drivers/w1
> > > 461 drivers/infiniband
> > > 389 drivers/media
> > > 301 drivers/scsi
> > 
> > I get rather different and much lower numbers
> > 
> > $ git grep -i -w slave drivers | \
> >   cut -f1,2 -d/ | uniq -c | sort -rn | head -20 | cat -n
> 
> That's because you're using grep -w which excludes, for example,
> slave_configure in drivers/scsi.

upper/lower case uses too...  (anyway, there are a lot)

$ git grep -i -w -P '\w*slave\w*' drivers | \
  cut -f1,2 -d/ | uniq -c | sort -rn | head -20 | cat -n
     1	   5683 drivers/net
     2	   2118 drivers/gpu
     3	   1807 drivers/dma
     4	   1389 drivers/i2c
     5	    866 drivers/interconnect
     6	    835 drivers/soundwire
     7	    821 drivers/spi
     8	    698 drivers/w1
     9	    508 drivers/media
    10	    481 drivers/infiniband
    11	    440 drivers/ata
    12	    317 drivers/scsi
    13	    267 drivers/fsi
    14	    240 drivers/tty
    15	    225 drivers/vme
    16	    223 drivers/staging
    17	    157 drivers/mmc
    18	    155 drivers/usb
    19	    141 drivers/video
    20	    140 drivers/char

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Mauro Carvalho Chehab]

Em Mon, 06 Jul 2020 06:30:01 -0700
Joe Perches <joe@perches.com> escreveu:

> On Mon, 2020-07-06 at 09:04 -0400, Matthew Wilcox wrote:
> > On Mon, Jul 6, 2020 at 8:59 AM Joe Perches <joe@perches.com> wrote:  
> > > On Mon, 2020-07-06 at 08:51 -0400, Matthew Wilcox wrote:  
> > > > In terms of number of lines of code using the word, it's only seventh
> > > > in drivers/:
> > > > 
> > > > $ for i in drivers/*; do c=$(find $i -type f |xargs grep slave |wc
> > > > -l); echo "$c $i"; done |sort -rn |head
> > > > 5218 drivers/net
> > > > 1341 drivers/dma
> > > > 988 drivers/i2c
> > > > 695 drivers/gpu
> > > > 666 drivers/soundwire
> > > > 665 drivers/spi
> > > > 559 drivers/w1
> > > > 461 drivers/infiniband
> > > > 389 drivers/media
> > > > 301 drivers/scsi  
> > > 
> > > I get rather different and much lower numbers
> > > 
> > > $ git grep -i -w slave drivers | \
> > >   cut -f1,2 -d/ | uniq -c | sort -rn | head -20 | cat -n  
> > 
> > That's because you're using grep -w which excludes, for example,
> > slave_configure in drivers/scsi.  
> 
> upper/lower case uses too...  (anyway, there are a lot)
> 
> $ git grep -i -w -P '\w*slave\w*' drivers | \
>   cut -f1,2 -d/ | uniq -c | sort -rn | head -20 | cat -n
>      1	   5683 drivers/net
>      2	   2118 drivers/gpu
>      3	   1807 drivers/dma
>      4	   1389 drivers/i2c
>      5	    866 drivers/interconnect
>      6	    835 drivers/soundwire
>      7	    821 drivers/spi
>      8	    698 drivers/w1
>      9	    508 drivers/media
>     10	    481 drivers/infiniband
>     11	    440 drivers/ata
>     12	    317 drivers/scsi
>     13	    267 drivers/fsi
>     14	    240 drivers/tty
>     15	    225 drivers/vme
>     16	    223 drivers/staging
>     17	    157 drivers/mmc
>     18	    155 drivers/usb
>     19	    141 drivers/video
>     20	    140 drivers/char

It sounds that, as soon after this patch gets merged, the mailing lists
will be flooded by lots of patches replacing such terms with something
else :-(

Doing a quick look at the media subsystem, it sounds that most terms
come from I2C master/slave and DiSEqC terminology, as defined by their
specs (and the others seem to be derived from some hardware vendor 
specific terminology).

As they're all supported by the current specs, if one would want
to replace them, it should first ensure that the supporting specs
should be using a different terminology, as otherwise replacing
them would just make harder for anyone trying to understand the
code.

Thanks,
Mauro

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Vinod Koul]

Hi Mauro,

On 09-07-20, 13:11, Mauro Carvalho Chehab wrote:
> Em Mon, 06 Jul 2020 06:30:01 -0700
> Joe Perches <joe@perches.com> escreveu:
> > 
> > $ git grep -i -w -P '\w*slave\w*' drivers | \
> >   cut -f1,2 -d/ | uniq -c | sort -rn | head -20 | cat -n
> >      1	   5683 drivers/net
> >      2	   2118 drivers/gpu
> >      3	   1807 drivers/dma
> >      4	   1389 drivers/i2c
> >      5	    866 drivers/interconnect
> >      6	    835 drivers/soundwire
> >      7	    821 drivers/spi
> >      8	    698 drivers/w1
> >      9	    508 drivers/media
> >     10	    481 drivers/infiniband
> >     11	    440 drivers/ata
> >     12	    317 drivers/scsi
> >     13	    267 drivers/fsi
> >     14	    240 drivers/tty
> >     15	    225 drivers/vme
> >     16	    223 drivers/staging
> >     17	    157 drivers/mmc
> >     18	    155 drivers/usb
> >     19	    141 drivers/video
> >     20	    140 drivers/char
> 
> It sounds that, as soon after this patch gets merged, the mailing lists
> will be flooded by lots of patches replacing such terms with something
> else :-(
> 
> Doing a quick look at the media subsystem, it sounds that most terms
> come from I2C master/slave and DiSEqC terminology, as defined by their
> specs (and the others seem to be derived from some hardware vendor 
> specific terminology).
> 
> As they're all supported by the current specs, if one would want
> to replace them, it should first ensure that the supporting specs
> should be using a different terminology, as otherwise replacing
> them would just make harder for anyone trying to understand the
> code.

I think waiting for specs may result in long delays, we all know how
'fast' spec bodies work!

Putting my soundwire maintainer hat, I see more than 1K uses of 'slave'
in the subsystem due to MIPI defined terms of SoundWire Master/Slave, so
I am planning to replace that and not wait for MIPI to update the spec.

A similar approach where we discuss with relevant stakeholder and arrive
at replacement terms and swap them would be great

Thanks
-- 
~Vinod

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Dan Williams]

On Sun, Jul 12, 2020 at 9:26 PM Vinod Koul <vkoul@kernel.org> wrote:
>
> Hi Mauro,
>
> On 09-07-20, 13:11, Mauro Carvalho Chehab wrote:
> > Em Mon, 06 Jul 2020 06:30:01 -0700
> > Joe Perches <joe@perches.com> escreveu:
> > >
> > > $ git grep -i -w -P '\w*slave\w*' drivers | \
> > >   cut -f1,2 -d/ | uniq -c | sort -rn | head -20 | cat -n
> > >      1         5683 drivers/net
> > >      2         2118 drivers/gpu
> > >      3         1807 drivers/dma
> > >      4         1389 drivers/i2c
> > >      5          866 drivers/interconnect
> > >      6          835 drivers/soundwire
> > >      7          821 drivers/spi
> > >      8          698 drivers/w1
> > >      9          508 drivers/media
> > >     10          481 drivers/infiniband
> > >     11          440 drivers/ata
> > >     12          317 drivers/scsi
> > >     13          267 drivers/fsi
> > >     14          240 drivers/tty
> > >     15          225 drivers/vme
> > >     16          223 drivers/staging
> > >     17          157 drivers/mmc
> > >     18          155 drivers/usb
> > >     19          141 drivers/video
> > >     20          140 drivers/char
> >
> > It sounds that, as soon after this patch gets merged, the mailing lists
> > will be flooded by lots of patches replacing such terms with something
> > else :-(
> >
> > Doing a quick look at the media subsystem, it sounds that most terms
> > come from I2C master/slave and DiSEqC terminology, as defined by their
> > specs (and the others seem to be derived from some hardware vendor
> > specific terminology).
> >
> > As they're all supported by the current specs, if one would want
> > to replace them, it should first ensure that the supporting specs
> > should be using a different terminology, as otherwise replacing
> > them would just make harder for anyone trying to understand the
> > code.
>
> I think waiting for specs may result in long delays, we all know how
> 'fast' spec bodies work!
>
> Putting my soundwire maintainer hat, I see more than 1K uses of 'slave'
> in the subsystem due to MIPI defined terms of SoundWire Master/Slave, so
> I am planning to replace that and not wait for MIPI to update the spec.

Sounds good.

> A similar approach where we discuss with relevant stakeholder and arrive
> at replacement terms and swap them would be great

Right, just like any other coding-style cleanup, stage it the way that
makes the most sense for the subsystem you maintain.

Re: [PATCH] CodingStyle: Inclusive Terminology

[Tibor Raschko]

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.

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Andy Lutomirski]

On Sat, Jul 4, 2020 at 1:19 PM Dan Williams <dan.j.williams@intel.com> wrote:
>
> Recent events have prompted a Linux position statement on inclusive
> terminology. Given that Linux maintains a coding-style and its own
> idiomatic set of terminology here is a proposal to answer the call to
> replace non-inclusive terminology.
>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Kees Cook <keescook@chromium.org>
> Signed-off-by: Chris Mason <clm@fb.clm>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
>  Documentation/process/coding-style.rst          |   12 ++++
>  Documentation/process/inclusive-terminology.rst |   64 +++++++++++++++++++++++
>  Documentation/process/index.rst                 |    1
>  3 files changed, 77 insertions(+)
>  create mode 100644 Documentation/process/inclusive-terminology.rst
>
> diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
> index 2657a55c6f12..4b15ab671089 100644
> --- a/Documentation/process/coding-style.rst
> +++ b/Documentation/process/coding-style.rst
> @@ -319,6 +319,18 @@ If you are afraid to mix up your local variable names, you have another
>  problem, which is called the function-growth-hormone-imbalance syndrome.
>  See chapter 6 (Functions).
>
> +For symbol names, avoid introducing new usage of the words 'slave' and
> +'blacklist'

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.

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Dan Williams]

On Mon, Jul 6, 2020 at 9:30 AM Andy Lutomirski <luto@amacapital.net> wrote:
>
> On Sat, Jul 4, 2020 at 1:19 PM Dan Williams <dan.j.williams@intel.com> wrote:
> >
> > Recent events have prompted a Linux position statement on inclusive
> > terminology. Given that Linux maintains a coding-style and its own
> > idiomatic set of terminology here is a proposal to answer the call to
> > replace non-inclusive terminology.
> >
> > Cc: Jonathan Corbet <corbet@lwn.net>
> > Cc: Kees Cook <keescook@chromium.org>
> > Signed-off-by: Chris Mason <clm@fb.clm>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> > ---
> >  Documentation/process/coding-style.rst          |   12 ++++
> >  Documentation/process/inclusive-terminology.rst |   64 +++++++++++++++++++++++
> >  Documentation/process/index.rst                 |    1
> >  3 files changed, 77 insertions(+)
> >  create mode 100644 Documentation/process/inclusive-terminology.rst
> >
> > diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
> > index 2657a55c6f12..4b15ab671089 100644
> > --- a/Documentation/process/coding-style.rst
> > +++ b/Documentation/process/coding-style.rst
> > @@ -319,6 +319,18 @@ If you are afraid to mix up your local variable names, you have another
> >  problem, which is called the function-growth-hormone-imbalance syndrome.
> >  See chapter 6 (Functions).
> >
> > +For symbol names, avoid introducing new usage of the words 'slave' and
> > +'blacklist'
>
> 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.

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Kees Cook]

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

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Mike Rapoport]

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
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

-- 
Sincerely yours,
Mike.

Re: [Tech-board-discuss] [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Steven Rostedt]

On Tue, 7 Jul 2020 09:49:21 +0300
Mike Rapoport <rppt@linux.ibm.com> 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

RE: [Ksummit-discuss] [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Bird, Tim]

> -----Original Message-----
> From: Steven Rostedt
> 
> On Tue, 7 Jul 2020 09:49:21 +0300
> Mike Rapoport <rppt@linux.ibm.com> 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

Re: [Ksummit-discuss] [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Randy Dunlap]

On 7/7/20 8:24 AM, Bird, Tim wrote:
> 
> 
>> -----Original Message-----
>> From: Steven Rostedt
>>
>> On Tue, 7 Jul 2020 09:49:21 +0300
>> Mike Rapoport <rppt@linux.ibm.com> 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.

That matches what I was about to say:
Just using yes/no does not tell someone what they are saying yes or no about.
It should be more descriptive, like allow/block.

-- 
~Randy

Re: [Ksummit-discuss] [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Steven Rostedt]

On Tue, 7 Jul 2020 08:33:33 -0700
Randy Dunlap <rdunlap@infradead.org> wrote:

> >> 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.  
> 
> That matches what I was about to say:
> Just using yes/no does not tell someone what they are saying yes or no about.
> It should be more descriptive, like allow/block.

After doing two days worth of git bisect, good/bad is hardcoded in my head :-p

-- Steve

RE: [Ksummit-discuss] [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Bird, Tim]

> -----Original Message-----
> From: Steven Rostedt <rostedt@goodmis.org>
> 
> On Tue, 7 Jul 2020 08:33:33 -0700
> Randy Dunlap <rdunlap@infradead.org> wrote:
> 
> > >> 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.
> >
> > That matches what I was about to say:
> > Just using yes/no does not tell someone what they are saying yes or no about.
> > It should be more descriptive, like allow/block.
> 
> After doing two days worth of git bisect, good/bad is hardcoded in my head :-p

Maybe I have the same bias, because good/bad there doesn't bother me at all. ;-)
Here is some 'motivated reasoning' on my part...

In the git case, the good/bad terms describe the result status of the test, not the action that git
is going to take based on that status.  It's pretty clear from context that a 'good'
result will cause that commit and other commits to be added to the 'good' set.  I think what
git actually does in constructing the sets is a bit too magical to describe with a  simple
verb.

As an aside I just looked up 'git-bisect' documentation, and found it has support
for changing the terms used ('git bisect terms ..') so you can use words like 'fast/slow'
or 'fixed/broken'.  That's something I didn't know about. :-)
 -- Tim

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Harrosh, Boaz]

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

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Kees Cook]

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

Re: [Tech-board-discuss] [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Steven Rostedt]

On Tue, 7 Jul 2020 01:54:23 -0700
Kees Cook <keescook@chromium.org> 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

Re: [Ksummit-discuss] [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Mike Rapoport]

On Tue, Jul 07, 2020 at 09:41:47AM -0400, Steven Rostedt wrote:
> On Tue, 7 Jul 2020 01:54:23 -0700
> Kees Cook <keescook@chromium.org> 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.

Re: [Ksummit-discuss] [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Kees Cook]

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 <keescook@chromium.org> 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

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Arvind Sankar]

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.

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Shuah Khan]

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 <corbet@lwn.net>
> Cc: Kees Cook <keescook@chromium.org>
> Signed-off-by: Chris Mason <clm@fb.clm>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
>   Documentation/process/coding-style.rst          |   12 ++++
>   Documentation/process/inclusive-terminology.rst |   64 +++++++++++++++++++++++
>   Documentation/process/index.rst                 |    1
>   3 files changed, 77 insertions(+)
>   create mode 100644 Documentation/process/inclusive-terminology.rst
> 
> diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
> index 2657a55c6f12..4b15ab671089 100644
> --- a/Documentation/process/coding-style.rst
> +++ b/Documentation/process/coding-style.rst
> @@ -319,6 +319,18 @@ If you are afraid to mix up your local variable names, you have another
>   problem, which is called the function-growth-hormone-imbalance syndrome.
>   See chapter 6 (Functions).
>   
> +For symbol names, avoid introducing new usage of the words 'slave' and
> +'blacklist'. Recommended replacements for 'slave' are: 'secondary',
> +'subordinate', 'replica', 'responder', 'follower', 'proxy', or
> +'performer'.  Recommended replacements for blacklist are: 'blocklist' or
> +'denylist'.

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 <skhan@linuxfoundation.org>
or Acked-by: Shuah Khan <skhan@linuxfoundation.org>

thanks,
-- Shuah

Re: [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Tibor Raschko]

> 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.

Re: [Ksummit-discuss] [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Mauro Carvalho Chehab]

Em Tue, 7 Jul 2020 01:58:21 +0200
Tibor Raschko <tibrasch@gmail.com> 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

Re: [Ksummit-discuss] [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Shuah Khan]

On 7/9/20 4:43 AM, Mauro Carvalho Chehab wrote:
> Em Tue, 7 Jul 2020 01:58:21 +0200
> Tibor Raschko <tibrasch@gmail.com> 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

Re: [Tech-board-discuss] [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 449 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [Ksummit-discuss] [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[James Bottomley]

[-- Attachment #1: Type: text/plain, Size: 1337 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [Tech-board-discuss] [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Steven Rostedt]

On Thu, 9 Jul 2020 17:13:51 +0100
Mark Brown <broonie@kernel.org> 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

Re: [Ksummit-discuss] [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Tibor Raschko]

>>> 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.

Re: [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Dan Williams]

On Mon, Jul 6, 2020 at 11:30 AM Shuah Khan <skhan@linuxfoundation.org> 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 <corbet@lwn.net>
> > Cc: Kees Cook <keescook@chromium.org>
> > Signed-off-by: Chris Mason <clm@fb.clm>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> > ---
> >   Documentation/process/coding-style.rst          |   12 ++++
> >   Documentation/process/inclusive-terminology.rst |   64 +++++++++++++++++++++++
> >   Documentation/process/index.rst                 |    1
> >   3 files changed, 77 insertions(+)
> >   create mode 100644 Documentation/process/inclusive-terminology.rst
> >
> > diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
> > index 2657a55c6f12..4b15ab671089 100644
> > --- a/Documentation/process/coding-style.rst
> > +++ b/Documentation/process/coding-style.rst
> > @@ -319,6 +319,18 @@ If you are afraid to mix up your local variable names, you have another
> >   problem, which is called the function-growth-hormone-imbalance syndrome.
> >   See chapter 6 (Functions).
> >
> > +For symbol names, avoid introducing new usage of the words 'slave' and
> > +'blacklist'. Recommended replacements for 'slave' are: 'secondary',
> > +'subordinate', 'replica', 'responder', 'follower', 'proxy', or
> > +'performer'.  Recommended replacements for blacklist are: 'blocklist' or
> > +'denylist'.
>
> 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 <skhan@linuxfoundation.org>
> or Acked-by: Shuah Khan <skhan@linuxfoundation.org>

Thanks Shuah.

Re: [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]

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?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Tibor Raschko]

> 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?

Re: [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Arvind Sankar]

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.

Re: [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Tibor Raschko]

> 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.

Re: [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Dan Williams]

On Mon, Jul 6, 2020 at 12:16 PM Mark Brown <broonie@kernel.org> 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.

Re: [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]

On Mon, Jul 06, 2020 at 09:08:57PM -0700, Dan Williams wrote:
> On Mon, Jul 6, 2020 at 12:16 PM Mark Brown <broonie@kernel.org> 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] CodingStyle: Inclusive Terminology

[Pavel Begunkov]

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 <corbet@lwn.net>
> Cc: Kees Cook <keescook@chromium.org>
> Signed-off-by: Chris Mason <clm@fb.clm>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
>  Documentation/process/coding-style.rst          |   12 ++++
>  Documentation/process/inclusive-terminology.rst |   64 +++++++++++++++++++++++
>  Documentation/process/index.rst                 |    1 
>  3 files changed, 77 insertions(+)
>  create mode 100644 Documentation/process/inclusive-terminology.rst
> 
> diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
> index 2657a55c6f12..4b15ab671089 100644
> --- a/Documentation/process/coding-style.rst
> +++ b/Documentation/process/coding-style.rst
> @@ -319,6 +319,18 @@ If you are afraid to mix up your local variable names, you have another
>  problem, which is called the function-growth-hormone-imbalance syndrome.
>  See chapter 6 (Functions).
>  
> +For symbol names, avoid introducing new usage of the words 'slave' and
> +'blacklist'. Recommended replacements for 'slave' are: 'secondary',
> +'subordinate', 'replica', 'responder', 'follower', 'proxy', or
> +'performer'.  Recommended replacements for blacklist are: 'blocklist' or
> +'denylist'.

"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

Re: [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Steven Rostedt]

On Tue, 7 Jul 2020 00:31:49 +0300
Pavel Begunkov <asml.silence@gmail.com> 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

Re: [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Pavel Begunkov]

On 07/07/2020 01:10, Steven Rostedt wrote:
> On Tue, 7 Jul 2020 00:31:49 +0300
> Pavel Begunkov <asml.silence@gmail.com> 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

Re: [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Steven Rostedt]

On Tue, 7 Jul 2020 01:17:47 +0300
Pavel Begunkov <asml.silence@gmail.com> 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

Re: [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Pavel Begunkov]

On 07/07/2020 01:28, Steven Rostedt wrote:
> On Tue, 7 Jul 2020 01:17:47 +0300
> Pavel Begunkov <asml.silence@gmail.com> 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

Re: [Ksummit-discuss] [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Stephen Hemminger]

On Tue, 7 Jul 2020 02:03:36 +0300
Pavel Begunkov <asml.silence@gmail.com> wrote:

> On 07/07/2020 01:28, Steven Rostedt wrote:
> > On Tue, 7 Jul 2020 01:17:47 +0300
> > Pavel Begunkov <asml.silence@gmail.com> 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.

Re: [Ksummit-discuss] [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Pavel Begunkov]

On 08/07/2020 06:42, Stephen Hemminger wrote:
> On Tue, 7 Jul 2020 02:03:36 +0300
> Pavel Begunkov <asml.silence@gmail.com> wrote:
> 
>> On 07/07/2020 01:28, Steven Rostedt wrote:
>>> On Tue, 7 Jul 2020 01:17:47 +0300
>>> Pavel Begunkov <asml.silence@gmail.com> 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

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[SeongJae Park]

Hello,

On Sat, 04 Jul 2020 13:02:51 -0700 Dan Williams <dan.j.williams@intel.com> wrote:

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

I'm glad to see this patch.

> 
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Kees Cook <keescook@chromium.org>
> Signed-off-by: Chris Mason <clm@fb.clm>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>

Acked-by: SeongJae Park <sjpark@amazon.de>

> ---
>  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

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Dan Williams]

On Mon, Jul 6, 2020 at 11:56 PM SeongJae Park <sjpark@amazon.com> wrote:
>
> Hello,
>
> On Sat, 04 Jul 2020 13:02:51 -0700 Dan Williams <dan.j.williams@intel.com> wrote:
>
> > Recent events have prompted a Linux position statement on inclusive
> > terminology. Given that Linux maintains a coding-style and its own
> > idiomatic set of terminology here is a proposal to answer the call to
> > replace non-inclusive terminology.
>
> I'm glad to see this patch.
>
> >
> > Cc: Jonathan Corbet <corbet@lwn.net>
> > Cc: Kees Cook <keescook@chromium.org>
> > Signed-off-by: Chris Mason <clm@fb.clm>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>
> Acked-by: SeongJae Park <sjpark@amazon.de>
>
> > ---
> >  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".

Re: Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[SeongJae Park]

On Wed, 8 Jul 2020 00:12:03 -0700 Dan Williams <dan.j.williams@intel.com> wrote:

> On Mon, Jul 6, 2020 at 11:56 PM SeongJae Park <sjpark@amazon.com> wrote:
> >
> > Hello,
> >
> > On Sat, 04 Jul 2020 13:02:51 -0700 Dan Williams <dan.j.williams@intel.com> wrote:
> >
> > > Recent events have prompted a Linux position statement on inclusive
> > > terminology. Given that Linux maintains a coding-style and its own
> > > idiomatic set of terminology here is a proposal to answer the call to
> > > replace non-inclusive terminology.
> >
> > I'm glad to see this patch.
> >
> > >
> > > Cc: Jonathan Corbet <corbet@lwn.net>
> > > Cc: Kees Cook <keescook@chromium.org>
> > > Signed-off-by: Chris Mason <clm@fb.clm>
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> >
> > Acked-by: SeongJae Park <sjpark@amazon.de>
> >
> > > ---
> > >  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

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Christian Brauner]

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 <corbet@lwn.net>
> Cc: Kees Cook <keescook@chromium.org>
> Signed-off-by: Chris Mason <clm@fb.clm>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---

This is the right thing to do.

Acked-by: Christian Brauner <christian.brauner@ubuntu.com>

(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
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Daniel Vetter]

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 <corbet@lwn.net>
> Cc: Kees Cook <keescook@chromium.org>
> Signed-off-by: Chris Mason <clm@fb.clm>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>

Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>

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

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] CodingStyle: Inclusive Terminology

[Pavel Machek]

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

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Laurent Pinchart]

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 <corbet@lwn.net>
> Cc: Kees Cook <keescook@chromium.org>
> Signed-off-by: Chris Mason <clm@fb.clm>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
>  Documentation/process/coding-style.rst          |   12 ++++
>  Documentation/process/inclusive-terminology.rst |   64 +++++++++++++++++++++++
>  Documentation/process/index.rst                 |    1 
>  3 files changed, 77 insertions(+)
>  create mode 100644 Documentation/process/inclusive-terminology.rst
> 
> diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
> index 2657a55c6f12..4b15ab671089 100644
> --- a/Documentation/process/coding-style.rst
> +++ b/Documentation/process/coding-style.rst
> @@ -319,6 +319,18 @@ If you are afraid to mix up your local variable names, you have another
>  problem, which is called the function-growth-hormone-imbalance syndrome.
>  See chapter 6 (Functions).
>  
> +For symbol names, avoid introducing new usage of the words 'slave' and
> +'blacklist'. Recommended replacements for 'slave' are: 'secondary',
> +'subordinate', 'replica', 'responder', 'follower', 'proxy', or
> +'performer'.  Recommended replacements for blacklist are: 'blocklist' or
> +'denylist'.
> +
> +Exceptions for introducing new usage is to maintain a userspace ABI, or
> +when updating code for an existing (as of 2020) hardware or protocol
> +specification that mandates those terms. For new specifications consider
> +translating specification usage of the terminology to the kernel coding
> +standard where possible. See :ref:`process/inclusive-terminology.rst
> +<inclusiveterminology>` for details.
>  
>  5) Typedefs
>  -----------
> diff --git a/Documentation/process/inclusive-terminology.rst b/Documentation/process/inclusive-terminology.rst
> new file mode 100644
> index 000000000000..a8eb26690eb4
> --- /dev/null
> +++ b/Documentation/process/inclusive-terminology.rst
> @@ -0,0 +1,64 @@
> +.. _inclusiveterminology:
> +
> +Linux kernel inclusive terminology
> +==================================
> +
> +The Linux kernel is a global software project, and in 2020 there was a
> +global reckoning on race relations that caused many organizations to
> +re-evaluate their policies and practices relative to the inclusion of
> +people of African descent. This document describes why the 'Naming'
> +section in :ref:`process/coding-style.rst <codingstyle>` recommends
> +avoiding usage of 'slave' and 'blacklist' in new additions to the Linux
> +kernel.
> +
> +On the triviality of replacing words
> +====================================
> +
> +The African slave trade was a brutal system of human misery deployed at
> +global scale. Some word choice decisions in a modern software project
> +does next to nothing to compensate for that legacy. So why put any
> +effort into something so trivial in comparison? Because the goal is not
> +to repair, or erase the past. The goal is to maximize availability and
> +efficiency of the global developer community to participate in the Linux
> +kernel development process.
> +
> +Word choice and developer efficiency
> +====================================
> +
> +Why does any software project go through the trouble of developing a
> +document like :ref:`process/coding-style.rst <codingstyle>`? It does so
> +because a common coding style maximizes the efficiency of both
> +maintainers and developers. Developers learn common design patterns and
> +idiomatic expressions while maintainers can spot deviations from those
> +norms. Even non-compliant whitespace is considered a leading indicator
> +to deeper problems in a patchset. Coding style violations are known to
> +take a maintainer "out of the zone" of reviewing code. Maintainers are
> +also sensitive to word choice across specifications and often choose to
> +deploy Linux terminology to replace non-idiomatic word-choice in a
> +specification.
> +
> +Non-inclusive terminology has that same distracting effect which is why
> +it is a style issue for Linux, it injures developer efficiency.
> +
> +Of course it is around this point someone jumps in with an etymological
> +argument about why people should not be offended. Etymological arguments
> +do not scale. The scope and pace of Linux to reach new developers
> +exceeds the ability of historical terminology defenders to describe "no,
> +not that connotation". The revelation of 2020 was that black voices were
> +heard on a global scale and the Linux kernel project has done its small
> +part to answer that call as it wants black voices, among all voices, in
> +its developer community.

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

Re: [PATCH] CodingStyle: Inclusive Terminology

[Michael Shigorin]

	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