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

From: Dan Williams <dan.j.williams@intel.com>
To: Joe Perches <joe@perches.com>
Cc: ksummit <ksummit-discuss@lists.linuxfoundation.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	SeongJae Park <sjpark@amazon.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	tech-board-discuss@lists.linuxfoundation.org,
	Chris Mason <clm@fb.clm>, Dave Airlie <airlied@redhat.com>
Subject: Re: [Ksummit-discuss] [PATCH v2] CodingStyle: Inclusive Terminology
Date: Wed, 8 Jul 2020 08:14:27 -0700	[thread overview]
Message-ID: <CAPcyv4iz6TzMhMvDzSvOgOvuu68z2YpxHeOycXrrjOfjaceHwQ@mail.gmail.com> (raw)
In-Reply-To: <b15e2652aba06dbe244f5ed447e6e96f12302198.camel@perches.com>

On Wed, Jul 8, 2020 at 4:05 AM Joe Perches <joe@perches.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@lwn.net>
> > Acked-by: Randy Dunlap <rdunlap@infradead.org>
> > Acked-by: Dave Airlie <airlied@redhat.com>
> > Acked-by: Kees Cook <keescook@chromium.org>
> > Acked-by: SeongJae Park <sjpark@amazon.de>
> > Signed-off-by: Olof Johansson <olof@lixom.net>
> > 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>
> > ---
> > 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.
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss