> From: Burakov, Anatoly [mailto:anatoly.bura...@intel.com] > Sent: Wednesday, 27 August 2025 16.14 > > On 8/20/2025 8:42 AM, Morten Brørup wrote: > >> From: Stephen Hemminger [mailto:step...@networkplumber.org] > >> Sent: Monday, 18 August 2025 18.34 > >> > >> On Wed, 12 Mar 2025 16:15:29 -0700 > >> Stephen Hemminger <step...@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.
