Re: [RFC 0/8] Cleanup VFIO API and import Linux uAPI header

["Burakov, Anatoly" <anatoly.burakov@intel.com>]

On 9/3/2025 11:52 AM, David Marchand wrote:
> Hello,
> 
> On Wed, 3 Sept 2025 at 11:30, Burakov, Anatoly
> <anatoly.burakov@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