On Wed, Jan 19, 2022 at 09:06:14AM -0700, Alex Williamson wrote: > 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 How about we just order the arc-supported ioctl patch first, then the spec revision and include the language about how to use arc-supported that is currently in the arc-supported ioctl? I'm still completely mystified why you think we need to bump the sub-type at all?? If you insist, but I'd like a good reason because I know it is going to hurt a bunch of people out there. ie can you point at something that is actually practically incompatible? Jason
