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

[Bruce Richardson <bruce.richardson@intel.com>]

On Wed, Aug 27, 2025 at 05:08:50PM +0200, Morten Brørup wrote:
> > 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.
>
We could start fairly easily by extracting out generic utility headers, no?

/Bruce