linux-modules.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lucas De Marchi <lucas.de.marchi@gmail.com>
To: Reuben Varghese <rvarghes@redhat.com>
Cc: linux-modules <linux-modules@vger.kernel.org>,
	Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
Subject: Re: [PATCH 0/2] Introduce inclusive language in kmod
Date: Sat, 15 May 2021 15:31:44 -0700	[thread overview]
Message-ID: <CAKi4VA+QqSkZMk+8=-9j7qH+_e7CRjW1mc+tVZ2V9Y+f=khe0w@mail.gmail.com> (raw)
In-Reply-To: <20210503105347.979635-1-rvarghes@redhat.com>

On Mon, May 3, 2021 at 3:54 AM Reuben Varghese <rvarghes@redhat.com> wrote:
>
> In July 2020, linux moved to adopt inclusive and neutral language.
> This includes replacing words slave/master with alternative terms
> like primary/secondary or the words blacklist/whitelist with
> blocklist/passlist.
>
> This patchset aims at editing the existing kmod code to make it inclusive.
> This is mainly achieved by refactoring the blacklist command to blocklist.
>
> The first patch refactors the term and updates the relevant documentation.
>
> Since changing blacklist to blocklist and completely removing support for the
> term blacklist will most likely break many systems, temporary support for the
> term blacklist with a warning is introduced as part of the fallback patch.

no warning should be added. The conf file with the blacklist command
spans through
OS packages and system administrators' files.

> That being said, two possible approaches of phasing out the term
> blacklist are listed below:
> Approach 1: The moment the word blacklist is seen when reading the config file,
> overwrite it to blocklist in the user's config file. The benefit of this approach
> would be that we could stop support for the term blacklist immediately while at
> the same time not breaking any systems.

that is out of question. You can't write to the system's config file.
The fs may even be readonly,
or you may actually be writing to initrd instead of rootfs

>
> Approach 2: Add a warning each time the term blacklist is encountered.
> This is the approach that is currently implemented. It is less aggresive
> than approach 1 and serves the purpose of removing the term blacklist from
> most places in the code.

As I said, no warning should be added... That would be, I guess, option 3.

thanks
Lucas De Marchi

>
> Reuben Varghese (2):
>   Refactor all instances of blacklist to blocklist and update
>     documentation
>   Continue temporary support for Blacklist command with warnings
>
>  Makefile.am                                   |  6 +--
>  NEWS                                          | 12 ++---
>  libkmod/docs/libkmod-sections.txt             |  4 +-
>  libkmod/libkmod-config.c                      | 50 ++++++++++--------
>  libkmod/libkmod-internal.h                    |  4 +-
>  libkmod/libkmod-module.c                      | 52 +++++++++----------
>  libkmod/libkmod.h                             | 12 ++---
>  libkmod/libkmod.sym                           |  4 +-
>  libkmod/python/kmod/_libkmod_h.pxd            |  2 +-
>  libkmod/python/kmod/kmod.pyx                  |  2 +-
>  man/modprobe.d.xml                            |  8 ++-
>  man/modprobe.xml                              |  4 +-
>  testsuite/.gitignore                          |  6 +--
>  .../etc/modprobe.d/modprobe.conf              |  2 -
>  .../etc/modprobe.d/modprobe.conf              |  2 +
>  .../{test-blacklist.c => test-blocklist.c}    | 12 ++---
>  tools/insert.c                                |  6 +--
>  tools/modprobe.c                              | 18 +++----
>  18 files changed, 109 insertions(+), 97 deletions(-)
>  delete mode 100644 testsuite/rootfs-pristine/test-blacklist/etc/modprobe.d/modprobe.conf
>  create mode 100644 testsuite/rootfs-pristine/test-blocklist/etc/modprobe.d/modprobe.conf
>  rename testsuite/{test-blacklist.c => test-blocklist.c} (90%)
>
> --
> 2.27.0
>

  parent reply	other threads:[~2021-05-15 22:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-03 10:53 [PATCH 0/2] Introduce inclusive language in kmod Reuben Varghese
2021-05-03 10:53 ` [PATCH 1/2] Refactor all instances of blacklist to blocklist and update documentation Reuben Varghese
2021-05-03 10:53 ` [PATCH 2/2] Continue temporary support for Blacklist command with warnings Reuben Varghese
2021-05-15 22:31 ` Lucas De Marchi [this message]
2021-05-18 15:03   ` [PATCH v2 0/3] Introduce inclusive language in kmod Reuben Varghese
2021-05-18 15:03     ` [PATCH v2 1/3] Refactor all instances of blacklist to blocklist Reuben Varghese
2021-05-21 21:42       ` Lucas De Marchi
2021-05-18 15:03     ` [PATCH v2 2/3] Update documentation reflecting change from " Reuben Varghese
2021-05-18 15:03     ` [PATCH v2 3/3] Continue temporary support for Blacklist command Reuben Varghese

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKi4VA+QqSkZMk+8=-9j7qH+_e7CRjW1mc+tVZ2V9Y+f=khe0w@mail.gmail.com' \
    --to=lucas.de.marchi@gmail.com \
    --cc=linux-modules@vger.kernel.org \
    --cc=rvarghes@redhat.com \
    --cc=yauheni.kaliuta@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).