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