diff mbox series

[v9,1/6] eal: replace usage of blacklist/whitelist in enum

Message ID 20201105223602.5965-2-stephen@networkplumber.org (mailing list archive)
State Superseded, archived
Delegated to: Thomas Monjalon
Headers
Series replace blacklist/whitelist with allow/block |

Checks

Context Check Description
ci/checkpatch warning coding style issues

Commit Message

Stephen Hemminger Nov. 5, 2020, 10:35 p.m. UTC 
  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

Bruce Richardson Nov. 9, 2020, 1:49 p.m. UTC | #1 
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
Stephen Hemminger Nov. 9, 2020, 3:54 p.m. UTC | #2 
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
David Marchand Nov. 9, 2020, 4:03 p.m. UTC | #3 
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
Bruce Richardson Nov. 9, 2020, 4:03 p.m. UTC | #4 
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
Bruce Richardson Nov. 9, 2020, 4:05 p.m. UTC | #5 
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
David Marchand Nov. 9, 2020, 4:07 p.m. UTC | #6 
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.
Bruce Richardson Nov. 9, 2020, 4:10 p.m. UTC | #7 
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
Stephen Hemminger Nov. 9, 2020, 4:20 p.m. UTC | #8 
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.
Luca Boccassi Nov. 10, 2020, 12:33 p.m. UTC | #9 
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?
Stephen Hemminger Nov. 10, 2020, 4:40 p.m. UTC | #10 
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.
Luca Boccassi Nov. 10, 2020, 4:46 p.m. UTC | #11 
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.
diff mbox series

Patch

diff --git a/lib/librte_eal/common/eal_common_devargs.c b/lib/librte_eal/common/eal_common_devargs.c
index 2123773ef840..fcf3d9a3ccb2 100644
--- a/lib/librte_eal/common/eal_common_devargs.c
+++ b/lib/librte_eal/common/eal_common_devargs.c
@@ -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;
diff --git a/lib/librte_eal/include/rte_bus.h b/lib/librte_eal/include/rte_bus.h
index d3034d0edf77..80b154fb982c 100644
--- a/lib/librte_eal/include/rte_bus.h
+++ b/lib/librte_eal/include/rte_bus.h
@@ -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.
  */
diff --git a/lib/librte_eal/include/rte_dev.h b/lib/librte_eal/include/rte_dev.h
index 81905b3ae35f..6dd72c11a14a 100644
--- a/lib/librte_eal/include/rte_dev.h
+++ b/lib/librte_eal/include/rte_dev.h
@@ -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.
  */
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,
 };
 
+/* 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
  *