On Mon, Jul 6, 2020 at 11:30 AM Shuah Khan <sk...@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 <cor...@lwn.net> > > Cc: Kees Cook <keesc...@chromium.org> > > Signed-off-by: Chris Mason <c...@fb.clm> > > Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> > > Signed-off-by: Dan Williams <dan.j.willi...@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 <sk...@linuxfoundation.org> > or Acked-by: Shuah Khan <sk...@linuxfoundation.org> Thanks Shuah.
