On 9/3/2025 11:52 AM, David Marchand wrote:
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.
Feel free to submit v2 at your own pace, as it might take a few days
before I can get to review this properly. I must say including uAPI in
DPDK is not something I thought of as I would've considered this to be a
very bold step, but it actually fixes a lot of problems in a really neat
way, so I like this idea.
--
Thanks,
Anatoly
