On Wed, 19 Jan 2022 11:40:28 -0400 Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > On Wed, Jan 19, 2022 at 08:32:22AM -0700, Alex Williamson wrote: > > > If the order was to propose a new FSM uAPI compatible to the existing > > bit definitions without the P2P states, then add a new ioctl and P2P > > states, and require userspace to use the ioctl to validate support for > > those new P2P states, I might be able to swallow that. > > That is what this achieves! > > Are you really asking that we have to redo all the docs/etc again just > to split them slightly differently into patches? What benefit is this > make work to anyone? Only if you're really set on trying to claim compatibility with the existing migration sub-type. The simpler solution is to roll the arc-supported ioctl into this proposal, bump the sub-type to v2 and define the v2 uAPI to require this ioctl. The proposal presented here does not stand on it's own, it requires the new ioctl. Those new p2p states are not really usable without the ioctl. Seems like we're just expecting well behaved userspace to ignore them as presented in this stand alone RFC. Thanks, Alex
