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

Dan Williams
2020-07-08T14:44:03Z

On Wed, Jul 8, 2020 at 1:22 AM Kees Cook <keescook@chromium.org> wrote:
>
> On Wed, Jul 08, 2020 at 12:23:59AM -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.com>
> > 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)
> >
> > - Update the recommended terms to include replacement for 'master' and
> > 'whitelist' (Kees, Andy)
> >
> > - Add 'target' as a replacement (Andy)
> >
> > - Add 'device' as a replacement (Mark)
> >
> > - Collect acks and signed-off-bys. Yes, the sign-offs are not reflective
> > of a submission chain, but I kept "Signed-off-by" if people offered
> > it.
>
> In that case, I will "upgrade" my Ack. ;)
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
>
> :)

Noted.

>
> > - Non-change: I did not add explicit language as to what to do with
> > existing usages. My personal inclination is to prioritize this
> > coding-style cleanup higher than others, but the coding-style document
> > has typically not indicated policy on how cleanups are handled by
> > subsystems. It will be a case by case effort and consideration.
>
> While I'd like to have published guidance on fixing existing language
> (which is already underway[1]), I agree: let's start here.
>
> > [...]
> > +For symbol names, avoid introducing new usage of 'master/slave' (or
>
> For symbol names, comments, documentation, and other language, avoid
> introducing ...

How about "symbol names and documentation" because I'm struggling to
think of an example of where this terminology would leak in outside
those broad categories.

> > +'slave' independent of 'master') and 'blacklist/whitelist'. Recommended
> > +replacements for 'master/slave' are: 'main/{secondary,subordinate}',
> > +'primary/replica', '{initiator,requester}/{target,responder}',
>
> the main and primary should be merged, IMO:
>
> '{primary,main}/{secondary,replica,subordinate}'

Ok.

>
> > +'host/{device,proxy}', or 'leader/{performer,follower}'. Recommended
>
> leader/performer does not track for me. Split it out?
>
> 'leader/follower', 'director/performer'

Sounds good.

> I have also seen:
>
> 'controller/worker'

Will add.

Thanks Kees.