RE: [PATCH v3 0/9] introduce common FOREACH_SAFE macros

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Burakov, Anatoly [mailto:anatoly.burakov@intel.com]
> Sent: Wednesday, 27 August 2025 16.14
> 
> On 8/20/2025 8:42 AM, Morten Brørup wrote:
> >> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> >> Sent: Monday, 18 August 2025 18.34
> >>
> >> On Wed, 12 Mar 2025 16:15:29 -0700
> >> Stephen Hemminger <stephen@networkplumber.org> wrote:
> >>
> >>> This series adds common macros for safe iteration over lists.
> >>> It is a subset copy of the macros from FreeBSD that are
> >>> missing from the Linux header sys/queue.h
> >>>
> >>> Chose this over several other options:
> >>>    - let each driver define their own as needed.
> >>>      One Intel driver got it wrong, others will as well.
> >>>    - rename all the queue macros to RTE_XXX variants.
> >>>      Seems like useless renaming and confusion.
> >>>    - Several distros have libbsd package with the correct macros.
> >>>      But adding yet another dependency to DPDK would be annoying
> >>>      for something this basic.
> >>>
> >>> There are more macros in FreeBSD header that could be useful,
> >>> but we can add those later as needed here.
> >>>
> >>>   lib/eal/include/rte_queue.h              | 174 +++++++++++++++++++++++
> >>
> >> Revisiting this and wondering about naming...
> >> The file rte_queue.h is not really DPDK (ie not related to runtime
> >> environment).
> >> Thinking of calling it bsd_queue.h as a compromise
> >
> > Since it replaces sys/queue.h, then maybe sys_queue.h (or rte_sys_queue.h).
> >
> > But more importantly:
> > It is not really DPDK, and thus shouldn't really be part of the EAL.
> > So here's an idea:
> > As part of de-bloating the EAL, can we somehow add a new directory structure
> for independent "libraries" like this?
> > And treat this rte_queue.h file as a "header file only" library, and put it
> there.
> > Then, build wise, the EAL could depend on this "library".
> >
> 
> IMO it depends on what you mean by "EAL". EAL is environment abstraction
> layer, and this header abstracts OS, thereby meeting description of an
> "environment abstraction layer"?

This library (header file) is generic, and has zero interaction with the hardware and OS, so it's not an environment abstraction.
The EAL has become a dump for "everything else" that isn't an individual library with its own subdirectory of the /lib directory.
IMO, it would be nice if we could separate generic utility libraries from the EAL.