[v3,00/10] rename blacklist/whitelist to block/allow
mbox series

Message ID 20200613000055.7909-1-stephen@networkplumber.org
Headers show
Series
  • rename blacklist/whitelist to block/allow
Related show

Message

Stephen Hemminger June 13, 2020, midnight UTC
The terms blacklist and whitelist are often seen as reminders
of the divisions in society. Instead, use more exact terms for
handling of which devices are used in DPDK.

This is a proposed change for DPDK 20.08 to replace the names
blacklist and whitelist in API and command lines.

The first three patches fix some other unnecessary use of
blacklist/whitelist and have no user visible impact.

The rest change the PCI blacklist to be blocklist and
whitelist to be allowlist.

v3 - fix some typo and spelling errors

Stephen Hemminger (10):
  rte_ethdev: change comment to rte_dev_eth_mac_addr_add
  mk: replace reference to blacklist/whitelist
  check_maintainers: change variable names
  eal: replace usage of blacklist/whitelist in enum
  drivers: replace references to blacklist
  eal: replace pci-whitelist/pci-blacklist options
  doc: replace references to blacklist/whitelist
  app/test: use new allowlist and blocklist
  doc: add note about blacklist/whitelist changes
  eal: mark old macros for blacklist/whitelist as deprecated

 app/test/autotest.py                          | 16 +++---
 app/test/autotest_runner.py                   | 18 +++----
 app/test/test.c                               |  2 +-
 app/test/test_eal_flags.c                     | 52 +++++++++----------
 devtools/check-maintainers.sh                 |  8 +--
 doc/guides/cryptodevs/dpaa2_sec.rst           |  4 +-
 doc/guides/cryptodevs/dpaa_sec.rst            |  4 +-
 doc/guides/cryptodevs/qat.rst                 |  4 +-
 doc/guides/freebsd_gsg/build_sample_apps.rst  |  2 +-
 doc/guides/linux_gsg/build_sample_apps.rst    |  2 +-
 doc/guides/linux_gsg/eal_args.include.rst     | 14 ++---
 doc/guides/nics/bnxt.rst                      |  6 +--
 doc/guides/nics/cxgbe.rst                     |  4 +-
 doc/guides/nics/dpaa.rst                      |  4 +-
 doc/guides/nics/dpaa2.rst                     |  4 +-
 doc/guides/nics/enic.rst                      |  6 +--
 doc/guides/nics/fail_safe.rst                 | 14 ++---
 doc/guides/nics/features.rst                  |  2 +-
 doc/guides/nics/ice.rst                       |  2 +-
 doc/guides/nics/mlx4.rst                      |  6 +--
 doc/guides/nics/mlx5.rst                      |  2 +-
 doc/guides/nics/sfc_efx.rst                   |  2 +-
 doc/guides/nics/tap.rst                       |  2 +-
 .../prog_guide/env_abstraction_layer.rst      |  7 ++-
 doc/guides/prog_guide/multi_proc_support.rst  |  4 +-
 doc/guides/rel_notes/known_issues.rst         |  4 +-
 doc/guides/rel_notes/release_20_08.rst        |  5 ++
 doc/guides/rel_notes/release_2_1.rst          |  2 +-
 doc/guides/sample_app_ug/bbdev_app.rst        |  6 +--
 doc/guides/sample_app_ug/ipsec_secgw.rst      |  4 +-
 doc/guides/sample_app_ug/l3_forward.rst       |  2 +-
 .../sample_app_ug/l3_forward_access_ctrl.rst  |  2 +-
 drivers/bus/dpaa/dpaa_bus.c                   |  7 ++-
 drivers/bus/fslmc/fslmc_bus.c                 |  9 ++--
 drivers/bus/fslmc/fslmc_vfio.c                |  8 +--
 drivers/bus/pci/pci_common.c                  | 24 ++++-----
 drivers/bus/vmbus/vmbus_common.c              |  4 +-
 drivers/crypto/virtio/virtio_pci.c            |  2 +-
 drivers/net/fm10k/fm10k_ethdev.c              |  2 +-
 drivers/net/virtio/virtio_pci.c               |  2 +-
 lib/librte_eal/common/eal_common_devargs.c    | 14 ++---
 lib/librte_eal/common/eal_common_options.c    | 29 ++++++-----
 lib/librte_eal/common/eal_options.h           |  8 +--
 lib/librte_eal/include/rte_bus.h              | 13 ++++-
 lib/librte_eal/include/rte_dev.h              | 12 ++++-
 lib/librte_eal/include/rte_devargs.h          | 12 ++++-
 lib/librte_ethdev/rte_ethdev.h                |  3 +-
 mk/rte.sdktest.mk                             | 14 ++---
 48 files changed, 203 insertions(+), 176 deletions(-)

Comments

Mcnamara, John June 17, 2020, 12:05 p.m. UTC | #1
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Stephen Hemminger
> Sent: Saturday, June 13, 2020 1:01 AM
> To: dev@dpdk.org
> Cc: Stephen Hemminger <stephen@networkplumber.org>
> Subject: [dpdk-dev] [PATCH v3 00/10] rename blacklist/whitelist to
> block/allow
> 
> The terms blacklist and whitelist are often seen as reminders of the
> divisions in society. Instead, use more exact terms for handling of which
> devices are used in DPDK.
> 
> This is a proposed change for DPDK 20.08 to replace the names blacklist
> and whitelist in API and command lines.
> 
> The first three patches fix some other unnecessary use of
> blacklist/whitelist and have no user visible impact.
> 
> The rest change the PCI blacklist to be blocklist and whitelist to be
> allowlist.
> 
> v3 - fix some typo and spelling errors

Series Acked-by: John McNamara <john.mcnamara@intel.com>
David Marchand July 10, 2020, 3:06 p.m. UTC | #2
On Sat, Jun 13, 2020 at 2:01 AM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> The terms blacklist and whitelist are often seen as reminders
> of the divisions in society. Instead, use more exact terms for
> handling of which devices are used in DPDK.
>
> This is a proposed change for DPDK 20.08 to replace the names
> blacklist and whitelist in API and command lines.
>
> The first three patches fix some other unnecessary use of
> blacklist/whitelist and have no user visible impact.
>
> The rest change the PCI blacklist to be blocklist and
> whitelist to be allowlist.

Thanks for working on this.

I agree, the first patches can go in right now.

But I have some concerns about the rest.

New options in EAL are not consistent with "allow"/"block" list:
+    "b:" /* pci-skip-probe */
+    "w:" /* pci-only-probe */
+#define OPT_PCI_SKIP_PROBE     "pci-skip-probe"
+    OPT_PCI_SKIP_PROBE_NUM  = 'b',
+#define OPT_PCI_ONLY_PROBE     "pci-only-probe"
+    OPT_PCI_ONLY_PROBE_NUM  = 'w',

The CI flagged the series as failing, because the unit test for EAL
flags is unaligned:
+#define pci_allowlist "--pci-allowlist"
https://travis-ci.com/github/ovsrobot/dpdk/jobs/348668299#L5657


The ABI check complains about the enum update:
https://travis-ci.com/github/ovsrobot/dpdk/jobs/348668301#L2400
Either we deal with this, or we need a libabigail exception rule.


About deprecating existing API/EAL flags in this release, this should
go through the standard deprecation process.
I would go with introducing new options + full compatibility + a
deprecation notice in the 20.08 release.
The actual deprecation/API flagging will go in 20.11.
Removal will come later.
Stephen Hemminger July 14, 2020, 4:43 a.m. UTC | #3
On Fri, 10 Jul 2020 17:06:11 +0200
David Marchand <david.marchand@redhat.com> wrote:

> On Sat, Jun 13, 2020 at 2:01 AM Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> >
> > The terms blacklist and whitelist are often seen as reminders
> > of the divisions in society. Instead, use more exact terms for
> > handling of which devices are used in DPDK.
> >
> > This is a proposed change for DPDK 20.08 to replace the names
> > blacklist and whitelist in API and command lines.
> >
> > The first three patches fix some other unnecessary use of
> > blacklist/whitelist and have no user visible impact.
> >
> > The rest change the PCI blacklist to be blocklist and
> > whitelist to be allowlist.  
> 
> Thanks for working on this.
> 
> I agree, the first patches can go in right now.
> 
> But I have some concerns about the rest.
> 
> New options in EAL are not consistent with "allow"/"block" list:
> +    "b:" /* pci-skip-probe */
> +    "w:" /* pci-only-probe */
> +#define OPT_PCI_SKIP_PROBE     "pci-skip-probe"
> +    OPT_PCI_SKIP_PROBE_NUM  = 'b',
> +#define OPT_PCI_ONLY_PROBE     "pci-only-probe"
> +    OPT_PCI_ONLY_PROBE_NUM  = 'w',
> 
> The CI flagged the series as failing, because the unit test for EAL
> flags is unaligned:
> +#define pci_allowlist "--pci-allowlist"
> https://travis-ci.com/github/ovsrobot/dpdk/jobs/348668299#L5657
> 
> 
> The ABI check complains about the enum update:
> https://travis-ci.com/github/ovsrobot/dpdk/jobs/348668301#L2400
> Either we deal with this, or we need a libabigail exception rule.
> 
> 
> About deprecating existing API/EAL flags in this release, this should
> go through the standard deprecation process.
> I would go with introducing new options + full compatibility + a
> deprecation notice in the 20.08 release.
> The actual deprecation/API flagging will go in 20.11.
> Removal will come later.
> 
> 

The next version will use different flags, and the old flags will cause
runtime deprecation warning.
Stephen Hemminger July 14, 2020, 5:33 a.m. UTC | #4
On Fri, 10 Jul 2020 17:06:11 +0200
David Marchand <david.marchand@redhat.com> wrote:

> About deprecating existing API/EAL flags in this release, this should
> go through the standard deprecation process.
> I would go with introducing new options + full compatibility + a
> deprecation notice in the 20.08 release.
> The actual deprecation/API flagging will go in 20.11.
> Removal will come later.

Like Make deprecation for 20.08 will leave the flags but add nag.
Want to make full removal in 20.11. Otherwise it will end up being 21.11
which is too far out.
Thomas Monjalon July 15, 2020, 10:01 a.m. UTC | #5
14/07/2020 07:33, Stephen Hemminger:
> On Fri, 10 Jul 2020 17:06:11 +0200
> David Marchand <david.marchand@redhat.com> wrote:
> 
> > About deprecating existing API/EAL flags in this release, this should
> > go through the standard deprecation process.
> > I would go with introducing new options + full compatibility + a
> > deprecation notice in the 20.08 release.
> > The actual deprecation/API flagging will go in 20.11.
> > Removal will come later.
> 
> Like Make deprecation for 20.08 will leave the flags but add nag.
> Want to make full removal in 20.11. Otherwise it will end up being 21.11
> which is too far out.

Excuse me I may lack a bit of context.
Are you asking for removing some EAL options without following
the deprecation process?