[v2,1/7] eal: add queue macro extensions from FreeBSD
Checks
Commit Message
The Linux version of sys/queue.h is frozen at an older version
and is missing the _SAFE macro variants. Several drivers started
introducing the own workarounds for this. Should be handled in EAL.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/eal/include/meson.build | 3 +-
lib/eal/include/rte_queue.h | 174 ++++++++++++++++++++++++++++++++++++
2 files changed, 176 insertions(+), 1 deletion(-)
create mode 100644 lib/eal/include/rte_queue.h
Comments
14/02/2025 18:20, Stephen Hemminger:
> The Linux version of sys/queue.h is frozen at an older version
> and is missing the _SAFE macro variants. Several drivers started
> introducing the own workarounds for this. Should be handled in EAL.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
We may want to unify with lib/eal/windows/include/sys/queue.h
On Wed, 19 Feb 2025 15:55:17 +0100
Thomas Monjalon <thomas@monjalon.net> wrote:
> 14/02/2025 18:20, Stephen Hemminger:
> > The Linux version of sys/queue.h is frozen at an older version
> > and is missing the _SAFE macro variants. Several drivers started
> > introducing the own workarounds for this. Should be handled in EAL.
> >
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>
> We may want to unify with lib/eal/windows/include/sys/queue.h
Do we want to just not use the local Linux version of queue.h entirely?
Maybe just put in current FreeBSD one? It has lots more useful variations.
The point is to avoid broken versions (like one Intel driver) or
having same macro in multiple places.
22/02/2025 00:05, Stephen Hemminger:
> On Wed, 19 Feb 2025 15:55:17 +0100
> Thomas Monjalon <thomas@monjalon.net> wrote:
>
> > 14/02/2025 18:20, Stephen Hemminger:
> > > The Linux version of sys/queue.h is frozen at an older version
> > > and is missing the _SAFE macro variants. Several drivers started
> > > introducing the own workarounds for this. Should be handled in EAL.
> > >
> > > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> >
> > We may want to unify with lib/eal/windows/include/sys/queue.h
>
> Do we want to just not use the local Linux version of queue.h entirely?
> Maybe just put in current FreeBSD one? It has lots more useful variations.
Yes but it should be global in EAL, no need to duplicate it for EAL Windows and others.
> The point is to avoid broken versions (like one Intel driver) or
> having same macro in multiple places.
Got it.
On Wed, 19 Feb 2025 15:55:17 +0100
Thomas Monjalon <thomas@monjalon.net> wrote:
> 14/02/2025 18:20, Stephen Hemminger:
> > The Linux version of sys/queue.h is frozen at an older version
> > and is missing the _SAFE macro variants. Several drivers started
> > introducing the own workarounds for this. Should be handled in EAL.
> >
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>
> We may want to unify with lib/eal/windows/include/sys/queue.h
>
>
Not sure, we have several options here:
1. Keep using Linux sys/queue.h and add enhancements in rte_queue.h
2. Make rte_queue.h a copy of FreeBSD version of queue.h (that is what Windows did)
3. Use the bsd version of queue.h.
On Debian/Ubuntu this in libbsd-dev package and referred to as bsd/sys/queue.h
I chose #1 as simplest. But all of these could work. #3 means DPDK has least new
code, but adds another dependency to the build.
No matter what, should add to checkpatch to block any new files that include sys/queue.h
directly.
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Thursday, 13 March 2025 00.02
>
> On Wed, 19 Feb 2025 15:55:17 +0100
> Thomas Monjalon <thomas@monjalon.net> wrote:
>
> > 14/02/2025 18:20, Stephen Hemminger:
> > > The Linux version of sys/queue.h is frozen at an older version
> > > and is missing the _SAFE macro variants. Several drivers started
> > > introducing the own workarounds for this. Should be handled in EAL.
> > >
> > > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> >
> > We may want to unify with lib/eal/windows/include/sys/queue.h
> >
> >
>
> Not sure, we have several options here:
> 1. Keep using Linux sys/queue.h and add enhancements in rte_queue.h
> 2. Make rte_queue.h a copy of FreeBSD version of queue.h (that is
> what Windows did)
> 3. Use the bsd version of queue.h.
> On Debian/Ubuntu this in libbsd-dev package and referred to as
> bsd/sys/queue.h
>
> I chose #1 as simplest. But all of these could work. #3 means DPDK has
> least new
> code, but adds another dependency to the build.
+1 to #2:
If Linux sys/queue.h is frozen, and is a subset of FreeBSD queue.h, #2 would consolidate all the queue macros in one file.
That seems easier to navigate (for a developer/reviewer looking at the macro definitions/implementations) than including sys/queue.h, queue.h or lib/eal/windows/include/sys/queue.h depending on O/S, and then defining the missing macros in rte_queue.h.
A comment at the top of the rte_queue.h file could mention that it is a copy of the FreeBSD queue.h file.
-1 to #3; it adds an unnecessary dependency.
>
> No matter what, should add to checkpatch to block any new files that
> include sys/queue.h
> directly.
+1 to this.
On Thu, Mar 13, 2025 at 09:00:09AM +0100, Morten Brørup wrote:
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Thursday, 13 March 2025 00.02
> >
> > On Wed, 19 Feb 2025 15:55:17 +0100
> > Thomas Monjalon <thomas@monjalon.net> wrote:
> >
> > > 14/02/2025 18:20, Stephen Hemminger:
> > > > The Linux version of sys/queue.h is frozen at an older version
> > > > and is missing the _SAFE macro variants. Several drivers started
> > > > introducing the own workarounds for this. Should be handled in EAL.
> > > >
> > > > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > >
> > > We may want to unify with lib/eal/windows/include/sys/queue.h
> > >
> > >
> >
> > Not sure, we have several options here:
> > 1. Keep using Linux sys/queue.h and add enhancements in rte_queue.h
> > 2. Make rte_queue.h a copy of FreeBSD version of queue.h (that is
> > what Windows did)
> > 3. Use the bsd version of queue.h.
> > On Debian/Ubuntu this in libbsd-dev package and referred to as
> > bsd/sys/queue.h
> >
> > I chose #1 as simplest. But all of these could work. #3 means DPDK has
> > least new
> > code, but adds another dependency to the build.
>
> +1 to #2:
> If Linux sys/queue.h is frozen, and is a subset of FreeBSD queue.h, #2 would consolidate all the queue macros in one file.
> That seems easier to navigate (for a developer/reviewer looking at the macro definitions/implementations) than including sys/queue.h, queue.h or lib/eal/windows/include/sys/queue.h depending on O/S, and then defining the missing macros in rte_queue.h.
> A comment at the top of the rte_queue.h file could mention that it is a copy of the FreeBSD queue.h file.
>
> -1 to #3; it adds an unnecessary dependency.
>
> >
> > No matter what, should add to checkpatch to block any new files that
> > include sys/queue.h
> > directly.
>
> +1 to this.
>
I agree with Morten, #2 looks the best option to me too.
/Bruce
13/03/2025 09:56, Bruce Richardson:
> On Thu, Mar 13, 2025 at 09:00:09AM +0100, Morten Brørup wrote:
> > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > Sent: Thursday, 13 March 2025 00.02
> > >
> > > On Wed, 19 Feb 2025 15:55:17 +0100
> > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > >
> > > > 14/02/2025 18:20, Stephen Hemminger:
> > > > > The Linux version of sys/queue.h is frozen at an older version
> > > > > and is missing the _SAFE macro variants. Several drivers started
> > > > > introducing the own workarounds for this. Should be handled in EAL.
> > > > >
> > > > > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > > >
> > > > We may want to unify with lib/eal/windows/include/sys/queue.h
> > > >
> > > >
> > >
> > > Not sure, we have several options here:
> > > 1. Keep using Linux sys/queue.h and add enhancements in rte_queue.h
> > > 2. Make rte_queue.h a copy of FreeBSD version of queue.h (that is
> > > what Windows did)
> > > 3. Use the bsd version of queue.h.
> > > On Debian/Ubuntu this in libbsd-dev package and referred to as
> > > bsd/sys/queue.h
> > >
> > > I chose #1 as simplest. But all of these could work. #3 means DPDK has
> > > least new
> > > code, but adds another dependency to the build.
> >
> > +1 to #2:
> > If Linux sys/queue.h is frozen, and is a subset of FreeBSD queue.h, #2 would consolidate all the queue macros in one file.
> > That seems easier to navigate (for a developer/reviewer looking at the macro definitions/implementations) than including sys/queue.h, queue.h or lib/eal/windows/include/sys/queue.h depending on O/S, and then defining the missing macros in rte_queue.h.
> > A comment at the top of the rte_queue.h file could mention that it is a copy of the FreeBSD queue.h file.
> >
> > -1 to #3; it adds an unnecessary dependency.
> >
> > >
> > > No matter what, should add to checkpatch to block any new files that
> > > include sys/queue.h
> > > directly.
> >
> > +1 to this.
> >
>
> I agree with Morten, #2 looks the best option to me too.
It means we want to remove lib/eal/windows/include/sys/queue.h, right?
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
>
> 13/03/2025 09:56, Bruce Richardson:
> > On Thu, Mar 13, 2025 at 09:00:09AM +0100, Morten Brørup wrote:
> > > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > > Sent: Thursday, 13 March 2025 00.02
> > > >
> > > > On Wed, 19 Feb 2025 15:55:17 +0100
> > > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > > >
> > > > > 14/02/2025 18:20, Stephen Hemminger:
> > > > > > The Linux version of sys/queue.h is frozen at an older
> version
> > > > > > and is missing the _SAFE macro variants. Several drivers
> started
> > > > > > introducing the own workarounds for this. Should be handled
> in EAL.
> > > > > >
> > > > > > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > > > >
> > > > > We may want to unify with lib/eal/windows/include/sys/queue.h
> > > > >
> > > > >
> > > >
> > > > Not sure, we have several options here:
> > > > 1. Keep using Linux sys/queue.h and add enhancements in
> rte_queue.h
> > > > 2. Make rte_queue.h a copy of FreeBSD version of queue.h (that
> is
> > > > what Windows did)
> > > > 3. Use the bsd version of queue.h.
> > > > On Debian/Ubuntu this in libbsd-dev package and referred to
> as
> > > > bsd/sys/queue.h
> > > >
> > > > I chose #1 as simplest. But all of these could work. #3 means
> DPDK has
> > > > least new
> > > > code, but adds another dependency to the build.
> > >
> > > +1 to #2:
> > > If Linux sys/queue.h is frozen, and is a subset of FreeBSD queue.h,
> #2 would consolidate all the queue macros in one file.
> > > That seems easier to navigate (for a developer/reviewer looking at
> the macro definitions/implementations) than including sys/queue.h,
> queue.h or lib/eal/windows/include/sys/queue.h depending on O/S, and
> then defining the missing macros in rte_queue.h.
> > > A comment at the top of the rte_queue.h file could mention that it
> is a copy of the FreeBSD queue.h file.
> > >
> > > -1 to #3; it adds an unnecessary dependency.
> > >
> > > >
> > > > No matter what, should add to checkpatch to block any new files
> that
> > > > include sys/queue.h
> > > > directly.
> > >
> > > +1 to this.
> > >
> >
> > I agree with Morten, #2 looks the best option to me too.
>
> It means we want to remove lib/eal/windows/include/sys/queue.h, right?
Correct.
All queue macros are consolidated into rte_queue.h.
On Thu, 13 Mar 2025 15:41:33 +0100
Morten Brørup <mb@smartsharesystems.com> wrote:
> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> >
> > 13/03/2025 09:56, Bruce Richardson:
> > > On Thu, Mar 13, 2025 at 09:00:09AM +0100, Morten Brørup wrote:
> > > > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > > > Sent: Thursday, 13 March 2025 00.02
> > > > >
> > > > > On Wed, 19 Feb 2025 15:55:17 +0100
> > > > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > > > >
> > > > > > 14/02/2025 18:20, Stephen Hemminger:
> > > > > > > The Linux version of sys/queue.h is frozen at an older
> > version
> > > > > > > and is missing the _SAFE macro variants. Several drivers
> > started
> > > > > > > introducing the own workarounds for this. Should be handled
> > in EAL.
> > > > > > >
> > > > > > > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > > > > >
> > > > > > We may want to unify with lib/eal/windows/include/sys/queue.h
> > > > > >
> > > > > >
> > > > >
> > > > > Not sure, we have several options here:
> > > > > 1. Keep using Linux sys/queue.h and add enhancements in
> > rte_queue.h
> > > > > 2. Make rte_queue.h a copy of FreeBSD version of queue.h (that
> > is
> > > > > what Windows did)
> > > > > 3. Use the bsd version of queue.h.
> > > > > On Debian/Ubuntu this in libbsd-dev package and referred to
> > as
> > > > > bsd/sys/queue.h
> > > > >
> > > > > I chose #1 as simplest. But all of these could work. #3 means
> > DPDK has
> > > > > least new
> > > > > code, but adds another dependency to the build.
> > > >
> > > > +1 to #2:
> > > > If Linux sys/queue.h is frozen, and is a subset of FreeBSD queue.h,
> > #2 would consolidate all the queue macros in one file.
> > > > That seems easier to navigate (for a developer/reviewer looking at
> > the macro definitions/implementations) than including sys/queue.h,
> > queue.h or lib/eal/windows/include/sys/queue.h depending on O/S, and
> > then defining the missing macros in rte_queue.h.
> > > > A comment at the top of the rte_queue.h file could mention that it
> > is a copy of the FreeBSD queue.h file.
> > > >
> > > > -1 to #3; it adds an unnecessary dependency.
> > > >
> > > > >
> > > > > No matter what, should add to checkpatch to block any new files
> > that
> > > > > include sys/queue.h
> > > > > directly.
> > > >
> > > > +1 to this.
> > > >
> > >
> > > I agree with Morten, #2 looks the best option to me too.
> >
> > It means we want to remove lib/eal/windows/include/sys/queue.h, right?
>
> Correct.
> All queue macros are consolidated into rte_queue.h.
>
I have been trying this, and it possible but there is some fallout.
If application includes <sys/queue.h> and other DPDK headers include <rte_queue.h>
there are declaration conflicts. Ends up being a compilation failure.
Tedious, but not hard to fix all of DPDK to use rte_queue.h instead of sys/queue.h
but what about user applications?
Since that would be API break, best to put it off to 25.11.
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Thursday, 13 March 2025 17.25
>
> On Thu, 13 Mar 2025 15:41:33 +0100
> Morten Brørup <mb@smartsharesystems.com> wrote:
>
> > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > >
> > > 13/03/2025 09:56, Bruce Richardson:
> > > > On Thu, Mar 13, 2025 at 09:00:09AM +0100, Morten Brørup wrote:
> > > > > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > > > > Sent: Thursday, 13 March 2025 00.02
> > > > > >
> > > > > > On Wed, 19 Feb 2025 15:55:17 +0100
> > > > > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > > > > >
> > > > > > > 14/02/2025 18:20, Stephen Hemminger:
> > > > > > > > The Linux version of sys/queue.h is frozen at an older
> > > version
> > > > > > > > and is missing the _SAFE macro variants. Several drivers
> > > started
> > > > > > > > introducing the own workarounds for this. Should be
> handled
> > > in EAL.
> > > > > > > >
> > > > > > > > Signed-off-by: Stephen Hemminger
> <stephen@networkplumber.org>
> > > > > > >
> > > > > > > We may want to unify with
> lib/eal/windows/include/sys/queue.h
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > Not sure, we have several options here:
> > > > > > 1. Keep using Linux sys/queue.h and add enhancements in
> > > rte_queue.h
> > > > > > 2. Make rte_queue.h a copy of FreeBSD version of queue.h
> (that
> > > is
> > > > > > what Windows did)
> > > > > > 3. Use the bsd version of queue.h.
> > > > > > On Debian/Ubuntu this in libbsd-dev package and referred
> to
> > > as
> > > > > > bsd/sys/queue.h
> > > > > >
> > > > > > I chose #1 as simplest. But all of these could work. #3 means
> > > DPDK has
> > > > > > least new
> > > > > > code, but adds another dependency to the build.
> > > > >
> > > > > +1 to #2:
> > > > > If Linux sys/queue.h is frozen, and is a subset of FreeBSD
> queue.h,
> > > #2 would consolidate all the queue macros in one file.
> > > > > That seems easier to navigate (for a developer/reviewer looking
> at
> > > the macro definitions/implementations) than including sys/queue.h,
> > > queue.h or lib/eal/windows/include/sys/queue.h depending on O/S,
> and
> > > then defining the missing macros in rte_queue.h.
> > > > > A comment at the top of the rte_queue.h file could mention that
> it
> > > is a copy of the FreeBSD queue.h file.
> > > > >
> > > > > -1 to #3; it adds an unnecessary dependency.
> > > > >
> > > > > >
> > > > > > No matter what, should add to checkpatch to block any new
> files
> > > that
> > > > > > include sys/queue.h
> > > > > > directly.
> > > > >
> > > > > +1 to this.
> > > > >
> > > >
> > > > I agree with Morten, #2 looks the best option to me too.
> > >
> > > It means we want to remove lib/eal/windows/include/sys/queue.h,
> right?
> >
> > Correct.
> > All queue macros are consolidated into rte_queue.h.
> >
>
> I have been trying this, and it possible but there is some fallout.
> If application includes <sys/queue.h> and other DPDK headers include
> <rte_queue.h>
> there are declaration conflicts. Ends up being a compilation failure.
> Tedious, but not hard to fix all of DPDK to use rte_queue.h instead of
> sys/queue.h
> but what about user applications?
Perhaps this could work:
If _SYS_QUEUE_H_ is defined in rte_queue.h, including <sys/queue.h> after <rte_queue.h> will be harmless.
If each macro in rte_queue.h is surrounded by #ifndef MACRONAME, including <rte_queue.h> after <sys/queue.h> will be harmless.
Alternatively, surround a group of macros in rte_queue.h by #ifndef _SYS_QUEUE_H_.
>
> Since that would be API break, best to put it off to 25.11.
It might be impossible prohibiting user libraries from including <sys/queue.h>, especially if some 3rd party library includes <sys/queue.h> in the library's header file. The application developer would not want to modify the header files of 3rd party libraries.
On Thu, 13 Mar 2025 17:40:26 +0100
Morten Brørup <mb@smartsharesystems.com> wrote:
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Thursday, 13 March 2025 17.25
> >
> > On Thu, 13 Mar 2025 15:41:33 +0100
> > Morten Brørup <mb@smartsharesystems.com> wrote:
> >
> > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > >
> > > > 13/03/2025 09:56, Bruce Richardson:
> > > > > On Thu, Mar 13, 2025 at 09:00:09AM +0100, Morten Brørup wrote:
> > > > > > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > > > > > Sent: Thursday, 13 March 2025 00.02
> > > > > > >
> > > > > > > On Wed, 19 Feb 2025 15:55:17 +0100
> > > > > > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > > > > > >
> > > > > > > > 14/02/2025 18:20, Stephen Hemminger:
> > > > > > > > > The Linux version of sys/queue.h is frozen at an older
> > > > version
> > > > > > > > > and is missing the _SAFE macro variants. Several drivers
> > > > started
> > > > > > > > > introducing the own workarounds for this. Should be
> > handled
> > > > in EAL.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Stephen Hemminger
> > <stephen@networkplumber.org>
> > > > > > > >
> > > > > > > > We may want to unify with
> > lib/eal/windows/include/sys/queue.h
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > Not sure, we have several options here:
> > > > > > > 1. Keep using Linux sys/queue.h and add enhancements in
> > > > rte_queue.h
> > > > > > > 2. Make rte_queue.h a copy of FreeBSD version of queue.h
> > (that
> > > > is
> > > > > > > what Windows did)
> > > > > > > 3. Use the bsd version of queue.h.
> > > > > > > On Debian/Ubuntu this in libbsd-dev package and referred
> > to
> > > > as
> > > > > > > bsd/sys/queue.h
> > > > > > >
> > > > > > > I chose #1 as simplest. But all of these could work. #3 means
> > > > DPDK has
> > > > > > > least new
> > > > > > > code, but adds another dependency to the build.
> > > > > >
> > > > > > +1 to #2:
> > > > > > If Linux sys/queue.h is frozen, and is a subset of FreeBSD
> > queue.h,
> > > > #2 would consolidate all the queue macros in one file.
> > > > > > That seems easier to navigate (for a developer/reviewer looking
> > at
> > > > the macro definitions/implementations) than including sys/queue.h,
> > > > queue.h or lib/eal/windows/include/sys/queue.h depending on O/S,
> > and
> > > > then defining the missing macros in rte_queue.h.
> > > > > > A comment at the top of the rte_queue.h file could mention that
> > it
> > > > is a copy of the FreeBSD queue.h file.
> > > > > >
> > > > > > -1 to #3; it adds an unnecessary dependency.
> > > > > >
> > > > > > >
> > > > > > > No matter what, should add to checkpatch to block any new
> > files
> > > > that
> > > > > > > include sys/queue.h
> > > > > > > directly.
> > > > > >
> > > > > > +1 to this.
> > > > > >
> > > > >
> > > > > I agree with Morten, #2 looks the best option to me too.
> > > >
> > > > It means we want to remove lib/eal/windows/include/sys/queue.h,
> > right?
> > >
> > > Correct.
> > > All queue macros are consolidated into rte_queue.h.
> > >
> >
> > I have been trying this, and it possible but there is some fallout.
> > If application includes <sys/queue.h> and other DPDK headers include
> > <rte_queue.h>
> > there are declaration conflicts. Ends up being a compilation failure.
> > Tedious, but not hard to fix all of DPDK to use rte_queue.h instead of
> > sys/queue.h
> > but what about user applications?
>
> Perhaps this could work:
>
> If _SYS_QUEUE_H_ is defined in rte_queue.h, including <sys/queue.h> after <rte_queue.h> will be harmless.
>
> If each macro in rte_queue.h is surrounded by #ifndef MACRONAME, including <rte_queue.h> after <sys/queue.h> will be harmless.
> Alternatively, surround a group of macros in rte_queue.h by #ifndef _SYS_QUEUE_H_.
Most applications include system headers (ie. sys/queue.h) then DPDK headers (rte_queue.h)
> >
> > Since that would be API break, best to put it off to 25.11.
>
> It might be impossible prohibiting user libraries from including <sys/queue.h>, especially if some 3rd party library includes <sys/queue.h> in the library's header file. The application developer would not want to modify the header files of 3rd party libraries.
>
It is possible to bracket every macro with #ifdef to avoid collision
but gets messy.
@@ -19,8 +19,8 @@ headers += files(
'rte_eal.h',
'rte_eal_memconfig.h',
'rte_eal_trace.h',
- 'rte_errno.h',
'rte_epoll.h',
+ 'rte_errno.h',
'rte_fbarray.h',
'rte_hexdump.h',
'rte_hypervisor.h',
@@ -38,6 +38,7 @@ headers += files(
'rte_pci_dev_features.h',
'rte_per_lcore.h',
'rte_pflock.h',
+ 'rte_queue.h',
'rte_random.h',
'rte_reciprocal.h',
'rte_seqcount.h',
new file mode 100644
@@ -0,0 +1,174 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ *
+ * Original Copyright (c) 1991, 1993
+ * The Regents of the University of California. All rights reserved.
+ */
+
+#ifndef _RTE_QUEUE_H_
+#define _RTE_QUEUE_H_
+
+/**
+ * @file
+ * Defines macro's that exist in the FreeBSD version of queue.h
+ * which are missing in other versions.
+ */
+
+#include <sys/queue.h>
+
+/*
+ * This file defines four types of data structures: singly-linked lists,
+ * singly-linked tail queues, lists and tail queues.
+ *
+ * Below is a summary of implemented functions where:
+ * o means the macro exists in original version
+ * + means the macro is added here
+ * - means the macro is not available
+ * s means the macro is available but is slow (runs in O(n) time)
+ *
+ * SLIST LIST STAILQ TAILQ
+ * _HEAD o o o o
+ * _HEAD_INITIALIZER o o o o
+ * _ENTRY o o o o
+ * _INIT o o o o
+ * _EMPTY o o o o
+ * _FIRST o o o o
+ * _NEXT o o o o
+ * _FOREACH o o o o
+ * _FOREACH_FROM + + + +
+ * _FOREACH_SAFE + + + +
+ * _FOREACH_FROM_SAFE + + + +
+ * _FOREACH_REVERSE - - - o
+ * _FOREACH_REVERSE_FROM - - - +
+ * _FOREACH_REVERSE_SAFE - - - +
+ * _FOREACH_REVERSE_FROM_SAFE - - - +
+ * _INSERT_HEAD o o o o
+ * _INSERT_BEFORE - o - o
+ * _INSERT_AFTER o o o o
+ * _INSERT_TAIL - - o o
+ * _CONCAT s s o o
+ * _REMOVE_AFTER o - o -
+ * _REMOVE_HEAD o o o o
+ * _REMOVE s o s o
+ *
+ */
+
+
+/*
+ * Singly-linked List declarations.
+ */
+#ifndef SLIST_FOREACH_FROM
+#define SLIST_FOREACH_FROM(var, head, field) \
+ for ((var) = ((var) ? (var) : SLIST_FIRST((head))); \
+ (var); \
+ (var) = SLIST_NEXT((var), field))
+#endif
+
+#ifndef SLIST_FOREACH_SAFE
+#define SLIST_FOREACH_SAFE(var, head, field, tvar) \
+ for ((var) = SLIST_FIRST((head)); \
+ (var) && ((tvar) = SLIST_NEXT((var), field), 1); \
+ (var) = (tvar))
+#endif
+
+#ifndef SLIST_FOREACH_FROM_SAFE
+#define SLIST_FOREACH_FROM_SAFE(var, head, field, tvar) \
+ for ((var) = ((var) ? (var) : SLIST_FIRST((head))); \
+ (var) && ((tvar) = SLIST_NEXT((var), field), 1); \
+ (var) = (tvar))
+#endif
+
+
+/*
+ * Singly-linked Tail queue declarations.
+ */
+#ifndef STAILQ_FOREACH_FROM
+#define STAILQ_FOREACH_FROM(var, head, field) \
+ for ((var) = ((var) ? (var) : STAILQ_FIRST((head))); \
+ (var); \
+ (var) = STAILQ_NEXT((var), field))
+#endif
+
+#ifndef STAILQ_FOREACH_SAFE
+#define STAILQ_FOREACH_SAFE(var, head, field, tvar) \
+ for ((var) = STAILQ_FIRST((head)); \
+ (var) && ((tvar) = STAILQ_NEXT((var), field), 1); \
+ (var) = (tvar))
+#endif
+
+#ifndef STAILQ_FOREACH_FROM_SAFE
+#define STAILQ_FOREACH_FROM_SAFE(var, head, field, tvar) \
+ for ((var) = ((var) ? (var) : STAILQ_FIRST((head))); \
+ (var) && ((tvar) = STAILQ_NEXT((var), field), 1); \
+ (var) = (tvar))
+#endif
+
+/*
+ * List declarations.
+ */
+#ifndef LIST_FOREACH_FROM
+#define LIST_FOREACH_FROM(var, head, field) \
+ for ((var) = ((var) ? (var) : LIST_FIRST((head))); \
+ (var); \
+ (var) = LIST_NEXT((var), field))
+#endif
+
+#ifndef LIST_FOREACH_SAFE
+#define LIST_FOREACH_SAFE(var, head, field, tvar) \
+ for ((var) = LIST_FIRST((head)); \
+ (var) && ((tvar) = LIST_NEXT((var), field), 1); \
+ (var) = (tvar))
+#endif
+
+#ifndef LIST_FOREACH_FROM_SAFE
+#define LIST_FOREACH_FROM_SAFE(var, head, field, tvar) \
+ for ((var) = ((var) ? (var) : LIST_FIRST((head))); \
+ (var) && ((tvar) = LIST_NEXT((var), field), 1); \
+ (var) = (tvar))
+#endif
+
+/*
+ * Tail queue declarations.
+ */
+#ifndef TAILQ_FOREACH_FROM
+#define TAILQ_FOREACH_FROM(var, head, field) \
+ for ((var) = ((var) ? (var) : TAILQ_FIRST((head))); \
+ (var); \
+ (var) = TAILQ_NEXT((var), field))
+#endif
+
+#ifndef TAILQ_FOREACH_SAFE
+#define TAILQ_FOREACH_SAFE(var, head, field, tvar) \
+ for ((var) = TAILQ_FIRST((head)); \
+ (var) && ((tvar) = TAILQ_NEXT((var), field), 1); \
+ (var) = (tvar))
+#endif
+
+#ifndef TAILQ_FOREACH_FROM_SAFE
+#define TAILQ_FOREACH_FROM_SAFE(var, head, field, tvar) \
+ for ((var) = ((var) ? (var) : TAILQ_FIRST((head))); \
+ (var) && ((tvar) = TAILQ_NEXT((var), field), 1); \
+ (var) = (tvar))
+#endif
+
+#ifndef TAILQ_FOREACH_REVERSE_FROM
+#define TAILQ_FOREACH_REVERSE_FROM(var, head, headname, field) \
+ for ((var) = ((var) ? (var) : TAILQ_LAST((head), headname)); \
+ (var); \
+ (var) = TAILQ_PREV((var), headname, field))
+#endif
+
+#ifndef TAILQ_FOREACH_REVERSE_SAFE
+#define TAILQ_FOREACH_REVERSE_SAFE(var, head, headname, field, tvar) \
+ for ((var) = TAILQ_LAST((head), headname); \
+ (var) && ((tvar) = TAILQ_PREV((var), headname, field), 1); \
+ (var) = (tvar))
+#endif
+
+#ifndef TAILQ_FOREACH_REVERSE_FROM_SAFE
+#define TAILQ_FOREACH_REVERSE_FROM_SAFE(var, head, headname, field, tvar)\
+ for ((var) = ((var) ? (var) : TAILQ_LAST((head), headname)); \
+ (var) && ((tvar) = TAILQ_PREV((var), headname, field), 1); \
+ (var) = (tvar))
+#endif
+
+#endif /* !_RTE_QUEUE_H_ */