On Fri, Apr 16, 2021 at 03:38:02PM +0200, Auger Eric wrote: > The redesign requirement came pretty late in the development process. > The iommu user API is upstream for a while, the VFIO interfaces have > been submitted a long time ago and under review for a bunch of time. > Redesigning everything with a different API, undefined at this point, is > a major setback for our work and will have a large impact on the > introduction of features companies are looking forward, hence our > frustration. I will answer both you and Jacob at once. This is uAPI, once it is set it can never be changed. The kernel process and philosophy is to invest heavily in uAPI development and review to converge on the best uAPI possible. Many past submissions have take a long time to get this right, there are several high profile uAPI examples. Do you think this case is so special, or the concerns so minor, that it should get to bypass all of the normal process? Ask yourself, is anyone advocating for the current direction on technical merits alone? Certainly the patches I last saw where completely disgusting from a uAPI design perspective. It was against the development process to organize this work the way it was done. Merging a wack of dead code to the kernel to support a uAPI vision that was never clearly articulated was a big mistake. Start from the beginning. Invest heavily in defining a high quality uAPI. Clearly describe the uAPI to all stake holders. Break up the implementation into patch series without dead code. Make the patches. Remove the dead code this group has already added. None of this should be a surprise. The VDPA discussion and related "what is a mdev" over a year ago made it pretty clear VFIO is not the exclusive user of "IOMMU in userspace" and that places limits on what kind of uAPIs expansion it should experience going forward. Jason
