linux-kernel - Re: [PATCH] CodingStyle: Inclusive Terminology

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1cceba0f-c8ad-260d-9a09-5417bee32d50@gmail.com>
Date:   Tue, 7 Jul 2020 00:31:49 +0300
From:   Pavel Begunkov <asml.silence@...il.com>
To:     Dan Williams <dan.j.williams@...el.com>
Cc:     torvalds@...ux-foundation.org, Jonathan Corbet <corbet@....net>,
        Kees Cook <keescook@...omium.org>, Chris Mason <clm@...clm>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        ksummit-discuss@...ts.linuxfoundation.org,
        tech-board-discuss@...ts.linuxfoundation.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] CodingStyle: Inclusive Terminology

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@....net>
> Cc: Kees Cook <keescook@...omium.org>
> Signed-off-by: Chris Mason <clm@...clm>
> Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> Signed-off-by: Dan Williams <dan.j.williams@...el.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