[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

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(-)
  

> -----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>
  

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.
  

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.
  

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.
  

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?
  

On Wed, 15 Jul 2020 12:01:27 +0200
Thomas Monjalon <thomas@monjalon.net> wrote:

> 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?
> 
> 

These were in the 20.08 deprecation notice.
  

22/09/2020 16:28, Stephen Hemminger:
> On Wed, 15 Jul 2020 12:01:27 +0200
> Thomas Monjalon <thomas@monjalon.net> wrote:
> 
> > 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?
> 
> These were in the 20.08 deprecation notice.

Do you mean this?
"
  The ``master-lcore`` argument to testpmd will be replaced
  with ``initial-lcore``. The old ``master-lcore`` argument
  will produce a runtime notification in 20.11 release, and
  be removed completely in a future release.
"
  

22/09/2020 18:16, Thomas Monjalon:
> 22/09/2020 16:28, Stephen Hemminger:
> > On Wed, 15 Jul 2020 12:01:27 +0200
> > Thomas Monjalon <thomas@monjalon.net> wrote:
> > 
> > > 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?
> > 
> > These were in the 20.08 deprecation notice.
> 
> Do you mean this?
> "
>   The ``master-lcore`` argument to testpmd will be replaced
>   with ``initial-lcore``. The old ``master-lcore`` argument
>   will produce a runtime notification in 20.11 release, and
>   be removed completely in a future release.
> "
For completeness, I see this as well:
"
  The command line arguments to ``rte_eal_init`` will change from
  ``-b, --pci-blacklist`` to ``-x, --exclude`` and
  ``-w, --pci-whitelist`` to ``-i, --include``.
  The old command line arguments will continue to be accepted in 20.11
  but will cause a runtime warning message. The old arguments will
  be removed in a future release.
"
  

On Tue, 22 Sep 2020 18:16:58 +0200
Thomas Monjalon <thomas@monjalon.net> wrote:

> 22/09/2020 16:28, Stephen Hemminger:
> > On Wed, 15 Jul 2020 12:01:27 +0200
> > Thomas Monjalon <thomas@monjalon.net> wrote:
> >   
> > > 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?  
> > 
> > These were in the 20.08 deprecation notice.  
> 
> Do you mean this?
> "
>   The ``master-lcore`` argument to testpmd will be replaced
>   with ``initial-lcore``. The old ``master-lcore`` argument
>   will produce a runtime notification in 20.11 release, and
>   be removed completely in a future release.
> "
> 
> 

Yes, went back to the wrong old thread while looking up the blacklist patches.
Just ignore this.