[v9,1/6] eal: replace usage of blacklist/whitelist in enum
Checks
Commit Message
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.
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.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Luca Boccassi <bluca@debian.org>
Acked-by: Gaetan Rivet <grive@u256.net>
---
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(-)
Comments
On Thu, Nov 05, 2020 at 02:35:57PM -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.
>
> 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.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> Acked-by: Luca Boccassi <bluca@debian.org>
> Acked-by: Gaetan Rivet <grive@u256.net>
> ---
> 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(-)
>
<snip>
> +/* Backwards compatibility will be removed later */
> +#define RTE_DEVTYPE_WHITELISTED_PCI \
> + RTE_DEPRECATED(RTE_DEVTYPE_WHITELISTED_PCI) RTE_DEVTYPE_ALLOWED
> +#define RTE_DEVTYPE_BLACKLISTED_PCI \
> + RTE_DEPRECATED(RTE_DEVTYPE_BLACKLISTED_PCI) RTE_DEVTYPE_BLOCKED
> +
This patch causes build failures which persist until patch 3, because of
these deprecations. I think you need to define the backward-compatibility
macros here, but only mark them deprecated at the end of the set.
/Bruce
../lib/librte_eal/common/eal_common_options.c: In function ‘eal_parse_common_option’:
../lib/librte_eal/common/eal_common_options.c:1458:13: error: "RTE_DEVTYPE_BLACKLISTED_PCI" is deprecated [-Werror]
1458 | if (eal_option_device_add(RTE_DEVTYPE_BLACKLISTED_PCI,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../lib/librte_eal/common/eal_common_options.c:1468:13: error: "RTE_DEVTYPE_WHITELISTED_PCI" is deprecated [-Werror]
1468 | if (eal_option_device_add(RTE_DEVTYPE_WHITELISTED_PCI,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
On Mon, 9 Nov 2020 13:49:31 +0000
Bruce Richardson <bruce.richardson@intel.com> wrote:
> On Thu, Nov 05, 2020 at 02:35:57PM -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.
> >
> > 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.
> >
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > Acked-by: Luca Boccassi <bluca@debian.org>
> > Acked-by: Gaetan Rivet <grive@u256.net>
> > ---
> > 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(-)
> >
> <snip>
> > +/* Backwards compatibility will be removed later */
> > +#define RTE_DEVTYPE_WHITELISTED_PCI \
> > + RTE_DEPRECATED(RTE_DEVTYPE_WHITELISTED_PCI) RTE_DEVTYPE_ALLOWED
> > +#define RTE_DEVTYPE_BLACKLISTED_PCI \
> > + RTE_DEPRECATED(RTE_DEVTYPE_BLACKLISTED_PCI) RTE_DEVTYPE_BLOCKED
> > +
>
> This patch causes build failures which persist until patch 3, because of
> these deprecations. I think you need to define the backward-compatibility
> macros here, but only mark them deprecated at the end of the set.
>
> /Bruce
Is building without warnings in every step that important?
The previous patch series for master/slave had the same effect
On Mon, Nov 9, 2020 at 4:55 PM Stephen Hemminger
<stephen@networkplumber.org> wrote:
> > This patch causes build failures which persist until patch 3, because of
> > these deprecations. I think you need to define the backward-compatibility
> > macros here, but only mark them deprecated at the end of the set.
> >
> > /Bruce
>
> Is building without warnings in every step that important?
> The previous patch series for master/slave had the same effect
Thomas fixed it while applying.
https://patchwork.dpdk.org/cover/80987/#122107
On Mon, Nov 09, 2020 at 07:54:40AM -0800, Stephen Hemminger wrote:
> On Mon, 9 Nov 2020 13:49:31 +0000
> Bruce Richardson <bruce.richardson@intel.com> wrote:
>
> > On Thu, Nov 05, 2020 at 02:35:57PM -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.
> > >
> > > 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.
> > >
> > > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > > Acked-by: Luca Boccassi <bluca@debian.org>
> > > Acked-by: Gaetan Rivet <grive@u256.net>
> > > ---
> > > 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(-)
> > >
> > <snip>
> > > +/* Backwards compatibility will be removed later */
> > > +#define RTE_DEVTYPE_WHITELISTED_PCI \
> > > + RTE_DEPRECATED(RTE_DEVTYPE_WHITELISTED_PCI) RTE_DEVTYPE_ALLOWED
> > > +#define RTE_DEVTYPE_BLACKLISTED_PCI \
> > > + RTE_DEPRECATED(RTE_DEVTYPE_BLACKLISTED_PCI) RTE_DEVTYPE_BLOCKED
> > > +
> >
> > This patch causes build failures which persist until patch 3, because of
> > these deprecations. I think you need to define the backward-compatibility
> > macros here, but only mark them deprecated at the end of the set.
> >
> > /Bruce
>
> Is building without warnings in every step that important?
> The previous patch series for master/slave had the same effect
>
I assumed it was necessary, but maybe I'm mistaken.
Thomas, David, your feedback please? We really could do with getting this
patchset into the LTS release!
/Bruce
On Mon, Nov 09, 2020 at 05:03:06PM +0100, David Marchand wrote:
> On Mon, Nov 9, 2020 at 4:55 PM Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> > > This patch causes build failures which persist until patch 3, because of
> > > these deprecations. I think you need to define the backward-compatibility
> > > macros here, but only mark them deprecated at the end of the set.
> > >
> > > /Bruce
> >
> > Is building without warnings in every step that important?
> > The previous patch series for master/slave had the same effect
>
> Thomas fixed it while applying.
> https://patchwork.dpdk.org/cover/80987/#122107
>
>
In this case I believe the below needs to be applied to patch 1, and then
the inverse of it set as patch 4 to mark the compatibility macros as
deprecated.
/Bruce
diff --git a/lib/librte_eal/include/rte_bus.h b/lib/librte_eal/include/rte_bus.h
index 80b154fb9..db90422ab 100644
--- a/lib/librte_eal/include/rte_bus.h
+++ b/lib/librte_eal/include/rte_bus.h
@@ -221,9 +221,9 @@ enum rte_bus_scan_mode {
/* Backwards compatibility will be removed */
#define RTE_BUS_SCAN_WHITELIST \
- RTE_DEPRECATED(RTE_BUS_SCAN_WHITELIST) RTE_BUS_SCAN_ALLOWLIST
+ RTE_BUS_SCAN_ALLOWLIST
#define RTE_BUS_SCAN_BLACKLIST \
- RTE_DEPRECATED(RTE_BUS_SCAN_BLACKLIST) RTE_BUS_SCAN_BLOCKLIST
+ RTE_BUS_SCAN_BLOCKLIST
/**
* A structure used to configure bus operations.
diff --git a/lib/librte_eal/include/rte_dev.h b/lib/librte_eal/include/rte_dev.h
index 6dd72c11a..6cc56a769 100644
--- a/lib/librte_eal/include/rte_dev.h
+++ b/lib/librte_eal/include/rte_dev.h
@@ -58,9 +58,9 @@ enum rte_dev_policy {
/* Backwards compatibility will be removed */
#define RTE_DEV_WHITELISTED \
- RTE_DEPRECATED(RTE_DEV_WHITELISTED) RTE_DEV_ALLOWED
+ RTE_DEV_ALLOWED
#define RTE_DEV_BLACKLISTED \
- RTE_DEPRECATED(RTE_DEV_BLACKLISTED) RTE_DEV_BLOCKED
+ RTE_DEV_BLOCKED
/**
* A generic memory resource representation.
diff --git a/lib/librte_eal/include/rte_devargs.h b/lib/librte_eal/include/rte_devargs.h
index 296f19324..8fed046e9 100644
--- a/lib/librte_eal/include/rte_devargs.h
+++ b/lib/librte_eal/include/rte_devargs.h
@@ -36,9 +36,9 @@ enum rte_devtype {
/* Backwards compatibility will be removed later */
#define RTE_DEVTYPE_WHITELISTED_PCI \
- RTE_DEPRECATED(RTE_DEVTYPE_WHITELISTED_PCI) RTE_DEVTYPE_ALLOWED
+ RTE_DEVTYPE_ALLOWED
#define RTE_DEVTYPE_BLACKLISTED_PCI \
- RTE_DEPRECATED(RTE_DEVTYPE_BLACKLISTED_PCI) RTE_DEVTYPE_BLOCKED
+ RTE_DEVTYPE_BLOCKED
/**
* Structure that stores a device given by the user with its arguments
On Mon, Nov 9, 2020 at 5:06 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> On Mon, Nov 09, 2020 at 05:03:06PM +0100, David Marchand wrote:
> > On Mon, Nov 9, 2020 at 4:55 PM Stephen Hemminger
> > <stephen@networkplumber.org> wrote:
> > > > This patch causes build failures which persist until patch 3, because of
> > > > these deprecations. I think you need to define the backward-compatibility
> > > > macros here, but only mark them deprecated at the end of the set.
> > > >
> > > > /Bruce
> > >
> > > Is building without warnings in every step that important?
> > > The previous patch series for master/slave had the same effect
> >
> > Thomas fixed it while applying.
> > https://patchwork.dpdk.org/cover/80987/#122107
> >
> >
> In this case I believe the below needs to be applied to patch 1, and then
> the inverse of it set as patch 4 to mark the compatibility macros as
> deprecated.
Or just squash the patches and be done with it, like I already commented.
No one cares about this series anyway.
On Mon, Nov 09, 2020 at 05:07:16PM +0100, David Marchand wrote:
> On Mon, Nov 9, 2020 at 5:06 PM Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > On Mon, Nov 09, 2020 at 05:03:06PM +0100, David Marchand wrote:
> > > On Mon, Nov 9, 2020 at 4:55 PM Stephen Hemminger
> > > <stephen@networkplumber.org> wrote:
> > > > > This patch causes build failures which persist until patch 3, because of
> > > > > these deprecations. I think you need to define the backward-compatibility
> > > > > macros here, but only mark them deprecated at the end of the set.
> > > > >
> > > > > /Bruce
> > > >
> > > > Is building without warnings in every step that important?
> > > > The previous patch series for master/slave had the same effect
> > >
> > > Thomas fixed it while applying.
> > > https://patchwork.dpdk.org/cover/80987/#122107
> > >
> > >
> > In this case I believe the below needs to be applied to patch 1, and then
> > the inverse of it set as patch 4 to mark the compatibility macros as
> > deprecated.
>
> Or just squash the patches and be done with it, like I already commented.
> No one cares about this series anyway.
>
Ok, yep, that's fine too.
/Bruce
On Mon, 9 Nov 2020 16:10:45 +0000
Bruce Richardson <bruce.richardson@intel.com> wrote:
> On Mon, Nov 09, 2020 at 05:07:16PM +0100, David Marchand wrote:
> > On Mon, Nov 9, 2020 at 5:06 PM Bruce Richardson
> > <bruce.richardson@intel.com> wrote:
> > >
> > > On Mon, Nov 09, 2020 at 05:03:06PM +0100, David Marchand wrote:
> > > > On Mon, Nov 9, 2020 at 4:55 PM Stephen Hemminger
> > > > <stephen@networkplumber.org> wrote:
> > > > > > This patch causes build failures which persist until patch 3, because of
> > > > > > these deprecations. I think you need to define the backward-compatibility
> > > > > > macros here, but only mark them deprecated at the end of the set.
> > > > > >
> > > > > > /Bruce
> > > > >
> > > > > Is building without warnings in every step that important?
> > > > > The previous patch series for master/slave had the same effect
> > > >
> > > > Thomas fixed it while applying.
> > > > https://patchwork.dpdk.org/cover/80987/#122107
> > > >
> > > >
> > > In this case I believe the below needs to be applied to patch 1, and then
> > > the inverse of it set as patch 4 to mark the compatibility macros as
> > > deprecated.
> >
> > Or just squash the patches and be done with it, like I already commented.
> > No one cares about this series anyway.
> >
> Ok, yep, that's fine too.
>
> /Bruce
Agree, go ahead and combine the patches.
They were split for testing and review.
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.
>
> 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.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> Acked-by: Luca Boccassi <bluca@debian.org>
> Acked-by: Gaetan Rivet <grive@u256.net>
> ---
> 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(-)
<..>
> diff --git a/lib/librte_eal/include/rte_devargs.h b/lib/librte_eal/include/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,
Any particular reason to drop the _PCI suffix from the enums and
command line parameters? Does it apply to more than PCI devices
nowadays?
On Tue, 10 Nov 2020 12:33:48 +0000
Luca Boccassi <bluca@debian.org> wrote:
> 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.
> >
> > 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.
> >
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > Acked-by: Luca Boccassi <bluca@debian.org>
> > Acked-by: Gaetan Rivet <grive@u256.net>
> > ---
> > 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(-)
>
> <..>
>
> > diff --git a/lib/librte_eal/include/rte_devargs.h b/lib/librte_eal/include/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,
>
> Any particular reason to drop the _PCI suffix from the enums and
> command line parameters? Does it apply to more than PCI devices
> nowadays?
Yes, block/allow also works for VMBus devices and and I think other
busses use it as well.
On Tue, 2020-11-10 at 08:40 -0800, Stephen Hemminger wrote:
> On Tue, 10 Nov 2020 12:33:48 +0000
> Luca Boccassi <bluca@debian.org> wrote:
>
> > 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.
> > >
> > > 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.
> > >
> > > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > > Acked-by: Luca Boccassi <bluca@debian.org>
> > > Acked-by: Gaetan Rivet <grive@u256.net>
> > > ---
> > > 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(-)
> >
> > <..>
> >
> > > diff --git a/lib/librte_eal/include/rte_devargs.h b/lib/librte_eal/include/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,
> >
> > Any particular reason to drop the _PCI suffix from the enums and
> > command line parameters? Does it apply to more than PCI devices
> > nowadays?
>
> Yes, block/allow also works for VMBus devices and and I think other
> busses use it as well.
Ok, makes sense, thanks.
@@ -296,7 +296,7 @@ rte_devargs_insert(struct rte_devargs **da)
return 0;
}
-/* store a whitelist parameter for later parsing */
+/* store in allowed list parameter for later parsing */
int
rte_devargs_add(enum rte_devtype devtype, const char *devargs_str)
{
@@ -313,13 +313,13 @@ rte_devargs_add(enum rte_devtype devtype, const char *devargs_str)
goto fail;
devargs->type = devtype;
bus = devargs->bus;
- if (devargs->type == RTE_DEVTYPE_BLACKLISTED_PCI)
- devargs->policy = RTE_DEV_BLACKLISTED;
+ if (devargs->type == RTE_DEVTYPE_BLOCKED)
+ devargs->policy = RTE_DEV_BLOCKED;
if (bus->conf.scan_mode == RTE_BUS_SCAN_UNDEFINED) {
- if (devargs->policy == RTE_DEV_WHITELISTED)
- bus->conf.scan_mode = RTE_BUS_SCAN_WHITELIST;
- else if (devargs->policy == RTE_DEV_BLACKLISTED)
- bus->conf.scan_mode = RTE_BUS_SCAN_BLACKLIST;
+ if (devargs->policy == RTE_DEV_ALLOWED)
+ bus->conf.scan_mode = RTE_BUS_SCAN_ALLOWLIST;
+ else if (devargs->policy == RTE_DEV_BLOCKED)
+ bus->conf.scan_mode = RTE_BUS_SCAN_BLOCKLIST;
}
TAILQ_INSERT_TAIL(&devargs_list, devargs, next);
return 0;
@@ -215,10 +215,16 @@ typedef int (*rte_bus_sigbus_handler_t)(const void *failure_addr);
*/
enum rte_bus_scan_mode {
RTE_BUS_SCAN_UNDEFINED,
- RTE_BUS_SCAN_WHITELIST,
- RTE_BUS_SCAN_BLACKLIST,
+ RTE_BUS_SCAN_ALLOWLIST,
+ RTE_BUS_SCAN_BLOCKLIST,
};
+/* Backwards compatibility will be removed */
+#define RTE_BUS_SCAN_WHITELIST \
+ RTE_DEPRECATED(RTE_BUS_SCAN_WHITELIST) RTE_BUS_SCAN_ALLOWLIST
+#define RTE_BUS_SCAN_BLACKLIST \
+ RTE_DEPRECATED(RTE_BUS_SCAN_BLACKLIST) RTE_BUS_SCAN_BLOCKLIST
+
/**
* A structure used to configure bus operations.
*/
@@ -52,10 +52,16 @@ typedef void (*rte_dev_event_cb_fn)(const char *device_name,
* Device policies.
*/
enum rte_dev_policy {
- RTE_DEV_WHITELISTED,
- RTE_DEV_BLACKLISTED,
+ RTE_DEV_ALLOWED,
+ RTE_DEV_BLOCKED,
};
+/* Backwards compatibility will be removed */
+#define RTE_DEV_WHITELISTED \
+ RTE_DEPRECATED(RTE_DEV_WHITELISTED) RTE_DEV_ALLOWED
+#define RTE_DEV_BLACKLISTED \
+ RTE_DEPRECATED(RTE_DEV_BLACKLISTED) RTE_DEV_BLOCKED
+
/**
* A generic memory resource representation.
*/
@@ -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,
};
+/* Backwards compatibility will be removed later */
+#define RTE_DEVTYPE_WHITELISTED_PCI \
+ RTE_DEPRECATED(RTE_DEVTYPE_WHITELISTED_PCI) RTE_DEVTYPE_ALLOWED
+#define RTE_DEVTYPE_BLACKLISTED_PCI \
+ RTE_DEPRECATED(RTE_DEVTYPE_BLACKLISTED_PCI) RTE_DEVTYPE_BLOCKED
+
/**
* Structure that stores a device given by the user with its arguments
*