On 8/25/2023 11:24 AM, Nuno Das Neves wrote:
On 8/19/2023 3:26 AM, Greg KH wrote:
My "strong" opinion is the one kernel development rule that we have,
"you can not break userspace". So, if you change these
values/structures/whatever in the future, and userspace tools break,
that's not ok and the changes have to be reverted.
If you can control both sides of the API here (with open tools that you
can guarantee everyone will always update to), then yes, you can change
the api in the future.
This is true for us - we contribute and maintain support for this driver
in Cloud Hypervisor[1], an open source VMM.
Hi Greg,
Bringing up this discussion again so we can clear up any confusion on the
uapi headers in this patch set.
The headers consist of the ioctls in mshv.h, and the hypervisor ABIs in
the *hdk.h files. The ioctls depend on the hypervisor ABIs.
We will add (to the next version), an ioctl like KVM_GET_API_VERSION [1].
This will return a version number for the ioctl interface that increments
any time there is a breaking change. Userspace would be required to check
this before calling any other ioctl, and it can exit gracefully if there
is a mismatch.
That's how KVM evolved its userspace ABI. We want to use the same approach.
I also wanted to reiterate that we are the only maintainers and users of
the userspace code for this driver via Cloud Hypervisor [2]. We generate
rust bindings from these headers using bindgen [3].
Taking this into account, is the above a viable path for this patch set?
Thanks,
Nuno
[1] https://docs.kernel.org/virt/kvm/api.html#kvm-get-api-version
[2] https://github.com/cloud-hypervisor/cloud-hypervisor
[3] https://github.com/rust-lang/rust-bindgen
