[v11,4/4] doc: replace usage of blacklist/whitelist

Message ID 20201115225320.68408-5-thomas@monjalon.net (mailing list archive)
State Accepted, archived
Headers
Series replace blacklist/whitelist with block/allow |

Checks

Context Check Description
ci/checkpatch warning coding style issues
ci/Intel-compilation success Compilation OK
ci/iol-broadcom-Functional success Functional Testing PASS
ci/iol-broadcom-Performance success Performance Testing PASS
ci/iol-testing warning Testing issues
ci/iol-intel-Functional fail Functional Testing issues
ci/iol-intel-Performance success Performance Testing PASS
ci/iol-mellanox-Performance success Performance Testing PASS
ci/travis-robot success Travis build: passed

Commit Message

Thomas Monjalon Nov. 15, 2020, 10:53 p.m. UTC
  From: Stephen Hemminger <stephen@networkplumber.org>

The words blacklist and whitelist are avoided in text
about MAC filtering or kernel module.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Luca Boccassi <bluca@debian.org>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
 doc/guides/nics/bnxt.rst                            | 10 +++++-----
 doc/guides/nics/enic.rst                            |  4 ++--
 doc/guides/nics/features.rst                        |  2 +-
 doc/guides/nics/ice.rst                             |  2 +-
 doc/guides/sample_app_ug/l3_forward_access_ctrl.rst |  2 +-
 5 files changed, 10 insertions(+), 10 deletions(-)
  

Patch

diff --git a/doc/guides/nics/bnxt.rst b/doc/guides/nics/bnxt.rst
index de0c37ce5b..d9a7d87930 100644
--- a/doc/guides/nics/bnxt.rst
+++ b/doc/guides/nics/bnxt.rst
@@ -258,8 +258,8 @@  The BNXT PMD supports hardware-based packet filtering:
 Unicast MAC Filter
 ^^^^^^^^^^^^^^^^^^
 
-The application adds (or removes) MAC addresses to enable (or disable)
-whitelist filtering to accept packets.
+The application can add (or remove) MAC addresses to enable (or disable)
+filtering on MAC address used to accept packets.
 
 .. code-block:: console
 
@@ -269,8 +269,8 @@  whitelist filtering to accept packets.
 Multicast MAC Filter
 ^^^^^^^^^^^^^^^^^^^^
 
-Application adds (or removes) Multicast addresses to enable (or disable)
-whitelist filtering to accept packets.
+The application can add (or remove) Multicast addresses that enable (or disable)
+filtering on multicast MAC address used to accept packets.
 
 .. code-block:: console
 
@@ -278,7 +278,7 @@  whitelist filtering to accept packets.
     testpmd> mcast_addr (add|remove) (port_id) (XX:XX:XX:XX:XX:XX)
 
 Application adds (or removes) Multicast addresses to enable (or disable)
-whitelist filtering to accept packets.
+allowlist filtering to accept packets.
 
 Note that the BNXT PMD supports up to 16 MC MAC filters. if the user adds more
 than 16 MC MACs, the BNXT PMD puts the port into the Allmulticast mode.
diff --git a/doc/guides/nics/enic.rst b/doc/guides/nics/enic.rst
index 163ae3f47b..5d1cc9f7fa 100644
--- a/doc/guides/nics/enic.rst
+++ b/doc/guides/nics/enic.rst
@@ -180,7 +180,7 @@  or ``vfio`` in non-IOMMU mode.
 
 In the VM, the kernel enic driver may be automatically bound to the VF during
 boot. Unbinding it currently hangs due to a known issue with the driver. To
-work around the issue, blacklist the enic module as follows.
+work around the issue, block the enic module as follows.
 Please see :ref:`Limitations <enic_limitations>` for limitations in
 the use of SR-IOV.
 
@@ -430,7 +430,7 @@  PKT_RX_VLAN_STRIPPED mbuf flags would not be set. This mode is enabled with the
   - VF devices are not usable directly from the host. They can  only be used
     as assigned devices on VM instances.
   - Currently, unbind of the ENIC kernel mode driver 'enic.ko' on the VM
-    instance may hang. As a workaround, enic.ko should be blacklisted or removed
+    instance may hang. As a workaround, enic.ko should be blocked or removed
     from the boot process.
   - pci_generic cannot be used as the uio module in the VM. igb_uio or
     vfio in non-IOMMU mode can be used.
diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index a4b288abcf..43f74e02ab 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -261,7 +261,7 @@  Supports enabling/disabling receiving multicast frames.
 Unicast MAC filter
 ------------------
 
-Supports adding MAC addresses to enable whitelist filtering to accept packets.
+Supports adding MAC addresses to enable incoming filtering of packets.
 
 * **[implements] eth_dev_ops**: ``mac_addr_set``, ``mac_addr_add``, ``mac_addr_remove``.
 * **[implements] rte_eth_dev_data**: ``mac_addrs``.
diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst
index bde78f98e4..c5a76a2a21 100644
--- a/doc/guides/nics/ice.rst
+++ b/doc/guides/nics/ice.rst
@@ -41,7 +41,7 @@  Runtime Config Options
   In pipeline mode, a flow can be set at one specific stage by setting parameter
   ``priority``. Currently, we support two stages: priority = 0 or !0. Flows with
   priority 0 located at the first pipeline stage which typically be used as a firewall
-  to drop the packet on a blacklist(we called it permission stage). At this stage,
+  to drop the packet on a blocklist(we called it permission stage). At this stage,
   flow rules are created for the device's exact match engine: switch. Flows with priority
   !0 located at the second stage, typically packets are classified here and be steered to
   specific queue or queue group (we called it distribution stage), At this stage, flow
diff --git a/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst b/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
index 4a96800ec6..eee5d81850 100644
--- a/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
+++ b/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
@@ -18,7 +18,7 @@  The application loads two types of rules at initialization:
 
 *   Route information rules, which are used for L3 forwarding
 
-*   Access Control List (ACL) rules that blacklist (or block) packets with a specific characteristic
+*   Access Control List (ACL) rules that block packets with a specific characteristic
 
 When packets are received from a port,
 the application extracts the necessary information from the TCP/IP header of the received packet and