From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 33AD2A04DD; Tue, 10 Nov 2020 17:47:01 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 04FB12B93; Tue, 10 Nov 2020 17:46:59 +0100 (CET) Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by dpdk.org (Postfix) with ESMTP id 2D71FF90 for ; Tue, 10 Nov 2020 17:46:56 +0100 (CET) Received: by mail-wm1-f65.google.com with SMTP id a65so3707665wme.1 for ; Tue, 10 Nov 2020 08:46:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:user-agent:mime-version; bh=o9ZX+A9R5OlYL0Bs7zKispifnrzCpiWh2k/MdWUEmfk=; b=Gk4/pm/rUVR4/df6d91vDfpCM+1VM0K4I9nVLbYlBM3oWMwrZy500W7BAKW0RiaLsY dqjNHV3V3GMyYzKQDLgS/jdVimNBM5ChTyqgdnNRB98V8W9wHylMhyk0wrMq7I1pAug6 28BRCbwTTUFQdpHQs6oEmWLjUWpdgFm+QOASWYAaVe6gR+UKERTb7hZWu79GEvDKO0iR jUwrJeWvkpHdWlGJeXf3tIm97BkUnvk+hyMg1nBLr1DPkTo7Pkrk8bo06xcIsMdsZwOL oquevJZnY7AMGRuNyWjmdNn1ZNSwMtG1nQKCm1eNWdyVyQyZNxS79B4KmqTak7uY3Ha5 Pumw== X-Gm-Message-State: AOAM531oQXc3uNI6YeNUIqwHys7pojx1tdHwulJJcDOXMe8UhHmGTxk6 xeAwF5wm3obya+LqjQ0WIel16oDFMxwy3lHgh2o= X-Google-Smtp-Source: ABdhPJzbE8rotHkUzCw/ae6CxO47UkffSiFlGXmCLnBL5Z1ovNmWiADwGtB918VPjSagL6gPQrUPOw== X-Received: by 2002:a1c:750b:: with SMTP id o11mr687338wmc.32.1605026814291; Tue, 10 Nov 2020 08:46:54 -0800 (PST) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id t17sm3474964wmi.3.2020.11.10.08.46.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Nov 2020 08:46:52 -0800 (PST) Message-ID: From: Luca Boccassi To: Stephen Hemminger Cc: dev@dpdk.org Date: Tue, 10 Nov 2020 16:46:52 +0000 In-Reply-To: <20201110084010.7b896efb@hermes.local> References: <20200922143202.8755-1-stephen@networkplumber.org> <20201105223602.5965-1-stephen@networkplumber.org> <20201105223602.5965-2-stephen@networkplumber.org> <6bc3f5b2b1814fb1824c6d4864155377d9413691.camel@debian.org> <20201110084010.7b896efb@hermes.local> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v9 1/6] eal: replace usage of blacklist/whitelist in enum X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, 2020-11-10 at 08:40 -0800, Stephen Hemminger wrote: > On Tue, 10 Nov 2020 12:33:48 +0000 > Luca Boccassi wrote: >=20 > > On Thu, 2020-11-05 at 14:35 -0800, Stephen Hemminger wrote: > > > This patch renames the enum values in the EAL include files. > > > As a backward compatible temporary migration tool, define > > > a replacement mapping for old values. > > >=20 > > > The old names relating to blacklist and whitelist are replaced > > > by block list and allow list, but applications may be using the > > > older compatibility macros. To help with conversion to new names > > > cause a message when the compatibility names are used. > > >=20 > > > Signed-off-by: Stephen Hemminger > > > Acked-by: Luca Boccassi > > > Acked-by: Gaetan Rivet > > > --- > > > lib/librte_eal/common/eal_common_devargs.c | 14 +++++++------- > > > lib/librte_eal/include/rte_bus.h | 10 ++++++++-- > > > lib/librte_eal/include/rte_dev.h | 10 ++++++++-- > > > lib/librte_eal/include/rte_devargs.h | 10 ++++++++-- > > > 4 files changed, 31 insertions(+), 13 deletions(-) =20 > >=20 > > <..> > >=20 > > > diff --git a/lib/librte_eal/include/rte_devargs.h b/lib/librte_eal/in= clude/rte_devargs.h > > > index 898efa0d667b..296f19324fae 100644 > > > --- a/lib/librte_eal/include/rte_devargs.h > > > +++ b/lib/librte_eal/include/rte_devargs.h > > > @@ -29,11 +29,17 @@ extern "C" { > > > * Type of generic device > > > */ > > > enum rte_devtype { > > > - RTE_DEVTYPE_WHITELISTED_PCI, > > > - RTE_DEVTYPE_BLACKLISTED_PCI, > > > + RTE_DEVTYPE_ALLOWED, > > > + RTE_DEVTYPE_BLOCKED, > > > RTE_DEVTYPE_VIRTUAL, =20 > >=20 > > Any particular reason to drop the _PCI suffix from the enums and > > command line parameters? Does it apply to more than PCI devices > > nowadays? >=20 > Yes, block/allow also works for VMBus devices and and I think other > busses use it as well. Ok, makes sense, thanks. --=20 Kind regards, Luca Boccassi