Message ID | 20200613000055.7909-1-stephen@networkplumber.org (mailing list archive) |
---|---|
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2614FA00BE; Sat, 13 Jun 2020 02:01:07 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E6D3D1BF93; Sat, 13 Jun 2020 02:01:05 +0200 (CEST) Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) by dpdk.org (Postfix) with ESMTP id 616FD1BF91 for <dev@dpdk.org>; Sat, 13 Jun 2020 02:01:04 +0200 (CEST) Received: by mail-pl1-f179.google.com with SMTP id g12so4377572pll.10 for <dev@dpdk.org>; Fri, 12 Jun 2020 17:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=CaqFyQRB/dzLLQiqeSkFJcM0F7UZtJobLCuqVin8T4o=; b=Fir6qQDJ+5Ob4z6vZVP2mRKsKF57GKDNQkft3pn+uq4rIh4iZdhFWWnNBNYZ/HFrr/ uazTynvaNtkP2PYtY/kl0qAr/6/rwTp1t9v75o2S/MTDEBA+hw/BfvbTtnarLSDmwPdJ 5acwmWiPOLl99eb9mTLKXhtXNpFqpFj+ijNUTIZ5ZlTUnbk0YryDMSwLBcH1hkG5q11h P3I121RowJ6Yyxp6rUsFpw8bIqohhQ+3k4Ly6lVdGGHFycqKhzdrktvu/LGa9093wqF4 MiYcpTC0Wpf0Fq1NRnid8c/XvmDGOj92Dh5Nzojr3+pT3J9oYDN68xHiwFBu7rVRiUP9 YT4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=CaqFyQRB/dzLLQiqeSkFJcM0F7UZtJobLCuqVin8T4o=; b=IG7l64hBwHA9DeZuaaHNq+fHVs0YY+fjCpF8rVRQyBD3GlmJ1IwE6WF+dBaXLqk1YY zjf//xoDMpOGY1A2JEz8w0yxMIRYjuTqwkYa8HT4TR1i28OrL/8YUKBUNSf6H7vMaFDz 0tJkCXrMHWv+rYlEVGiMPoQ58eJxHV8GssVjYhAazxcfAzJ+t1IMcrhq59uTV4OHYh6N e0OULwC4Cej7wMVTyVE8fPMZavyMbcAQjUlY/KG2TXomC6cR8Uac4844MsXVsO1ue1E8 zg5tnSIiaqNvLKJayVQIiid2mPGyyfse5hSrDXg0VNIsPioHdP/FQBbilDHBIFTv7gg7 eb7w== X-Gm-Message-State: AOAM530Gexmuq+z896zqZ1GOCweQs4f5OOijw2vL93+fDoteEFpsW+Br y8bWewKzyWZA4Bjbiv3p6K7KH8ktN4U= X-Google-Smtp-Source: ABdhPJwrs+5tN3KUv3WX2m5NnryZQZNndhX6kLEhgkRIcah9usUv7jTFYNgLtq02lN5hhSVVfNiOZw== X-Received: by 2002:a17:902:7288:: with SMTP id d8mr11290340pll.18.1592006462734; Fri, 12 Jun 2020 17:01:02 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id 6sm7205921pfi.170.2020.06.12.17.01.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Jun 2020 17:01:01 -0700 (PDT) From: Stephen Hemminger <stephen@networkplumber.org> To: dev@dpdk.org Cc: Stephen Hemminger <stephen@networkplumber.org> Date: Fri, 12 Jun 2020 17:00:45 -0700 Message-Id: <20200613000055.7909-1-stephen@networkplumber.org> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [dpdk-dev] [PATCH v3 00/10] rename blacklist/whitelist to block/allow X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Series |
rename blacklist/whitelist to block/allow
|
|
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
> -----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.