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

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

> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Wednesday, 27 August 2025 17.12
> 
> 27/08/2025 17:08, Morten Brørup:
> > > 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.
> 
> I disagree here, it is something due by the OS libc,
> but not reliably available everywhere.
> 
> > 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.
> 
> I agree with the goal of having a thinner EAL.
> 
> I'm not sure about this one.

I thought this file might be a good place to start separating utilities from abstraction.
However, a well designed roadmap to re-organize the EAL is probably better than starting with this specific library.

Sorry (not sorry) about the noise. I will keep reminding the community about the bloated EAL from time to time. :-)