[PATCH v3 05/25] bpf/validate: introduce debugging interface

[Thomas Monjalon]

23/06/2026 12:29, Marat Khalili:
> > -----Original Message-----
> > From: Thomas Monjalon <thomas at monjalon.net>
> > Sent: Tuesday 23 June 2026 11:19
> > To: Marat Khalili <marat.khalili at huawei.com>
> > Cc: Konstantin Ananyev <konstantin.ananyev at huawei.com>; dev at dpdk.org
> > Subject: Re: [PATCH v3 05/25] bpf/validate: introduce debugging interface
> > 
> > 12/06/2026 12:47, Marat Khalili:
> > > +#ifndef LIST_FOREACH_SAFE
> > > +/* We need this macro which neither Linux nor EAL for Linux include yet. */
> > > +#define        LIST_FOREACH_SAFE(var, head, field, tvar)                       \
> > > +       for ((var) = LIST_FIRST((head));                                \
> > > +           (var) && ((tvar) = LIST_NEXT((var), field), 1);             \
> > > +           (var) = (tvar))
> > > +#else
> > > +#ifdef RTE_EXEC_ENV_LINUX
> > > +#error "Don't need LIST_FOREACH_SAFE in this version of DPDK anymore, remove it."
> > > +#endif
> > > +#endif
> > 
> > It fails on Alpine Linux.
> > Why adding this #error?
> > 
> 
> This is interesting. My mental model was that Linux is never going to have
> LIST_FOREACH_SAFE, but DPDK will eventually gain its own polyfill. I was
> actually expecting it to happen before my patch is published, so this was a
> reminder to remove my own definition since it clearly belongs to some common
> library. Turns out I was wrong on both accounts: there are Linuxes that define
> LIST_FOREACH_SAFE, and I managed to submit faster. Apart from these
> organizational issues the whole else branch can be safely removed. Do you want
> me to submit an updated version?

Yes would be nice so we will have a full CI run on it
now that the dependency is merged in main.