Hello, On Wed, 3 Sept 2025 at 11:30, Burakov, Anatoly <anatoly.bura...@intel.com> wrote: > > On 9/3/2025 9:28 AM, David Marchand wrote: > > The VFIO headers have a number of issues: > > - showing to the world a lot of internal considerations, > > - defining macros with the VFIO_ namespace (confusing, and a source of > > conflicts with the VFIO official uAPI), > > - wrapping around VFIO uAPI in case the kernel headers do not contain the > > expected API (putting the burden on DPDK developers to find the right > > way to detect the presence of a VFIO feature), > > - (somehow related to the previous point) supporting old version of the > > Linux kernel while DPDK now requires a v5.4 Linux kernel at least, > > > > This series proposes to cleanup those headers by hiding as much as > > possible internal macros and structures, then removing the explicit > > inclusion of linux/vfio.h from rte_vfio.h (pushing this inclusion to the > > application which may want to do some funny stuff with VFIO and should > > already include this header on its own) and finally importing the VFIO > > uAPI header from Linux v6.15 for internal consumption by DPDK > > components. > > > > > > I've been working on something like this myself, so it'll be interesting > to compare notes! I too found that refactoring VFIO is a nightmare due > to how much stuff is exposed to external headers.
Oh cool. A v2 is neeed, as this series breaks FreeBSD compilation. I'll wait for comments before sending. -- David Marchand
