linux-kernel - Re: [PATCH v2] 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: <CAPcyv4iz6TzMhMvDzSvOgOvuu68z2YpxHeOycXrrjOfjaceHwQ@mail.gmail.com>
Date:   Wed, 8 Jul 2020 08:14:27 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Joe Perches <joe@...ches.com>
Cc:     Jonathan Corbet <corbet@....net>,
        Randy Dunlap <rdunlap@...radead.org>,
        Dave Airlie <airlied@...hat.com>,
        Kees Cook <keescook@...omium.org>,
        SeongJae Park <sjpark@...zon.de>,
        Olof Johansson <olof@...om.net>, Chris Mason <clm@...clm>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        tech-board-discuss@...ts.linuxfoundation.org,
        ksummit <ksummit-discuss@...ts.linuxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] CodingStyle: Inclusive Terminology

On Wed, Jul 8, 2020 at 4:05 AM Joe Perches <joe@...ches.com> wrote:
>
> On Wed, 2020-07-08 at 00:23 -0700, Dan Williams wrote:
> > Linux maintains a coding-style and its own idiomatic set of terminology.
> > Update the style guidelines to recommend replacements for the terms
> > master/slave and blacklist/whitelist.
> >
> > Link: http://lore.kernel.org/r/159389297140.2210796.13590142254668787525.stgit@dwillia2-desk3.amr.corp.intel.com
> > Cc: Jonathan Corbet <corbet@....net>
> > Acked-by: Randy Dunlap <rdunlap@...radead.org>
> > Acked-by: Dave Airlie <airlied@...hat.com>
> > Acked-by: Kees Cook <keescook@...omium.org>
> > Acked-by: SeongJae Park <sjpark@...zon.de>
> > Signed-off-by: Olof Johansson <olof@...om.net>
> > 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>
> > ---
> > Changes since v1 [1]
> > - Drop inclusive-terminology.rst, it is in the lore archives if the
> >   arguments are needed for future debates, but otherwise no pressing
> >   need to carry it in the tree (Linus, James)
>
> Where did Linus publicly state this was unnecessary?

James suggested dropping the document, Linus agreed, I agreed.

>
> > diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
> []
> > @@ -319,6 +319,19 @@ 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 'master/slave' (or
> > +'slave' independent of 'master') and 'blacklist/whitelist'. Recommended
> > +replacements for 'master/slave' are: 'main/{secondary,subordinate}',
> > +'primary/replica', '{initiator,requester}/{target,responder}',
> > +'host/{device,proxy}', or 'leader/{performer,follower}'. Recommended
> > +replacements for 'blacklist/whitelist' are: 'denylist/allowlist' or
> > +'blocklist/passlist'.
>
> Adding a reference to SeongJae Park's introduction of
> scripts/deprecated_terms.txt or the like might help
> make this list unnecessary if more terms are added.

Per his last mail he's going to update his checker to refer to coding-style.

> > +Exceptions for introducing new usage is to maintain a userspace ABI/API,
> > +or when updating code for an existing (as of 2020) hardware or protocol
> > +specification that mandates those terms. For new specifications
> > +translate specification usage of the terminology to the kernel coding
> > +standard where possible.
>
> I believe any existing code should not be changed,
> not just code that is required to be maintained
> for userspace.

We have existing practices around coding-style changes that can be
applied here. Some subsystems are open to modernizing their code with
respect to the latest coding style recommendations and others,
especially those with ancient drivers don't want the churn. So, I
would hold these cleanups to the same standard.