[PATCH v2 13/15] uapi: hyperv: Add mshv driver headers hvhdk.h, hvhdk_mini.h, hvgdk.h, hvgdk_mini.h

[Greg KH]

On Thu, Aug 17, 2023 at 11:01:46PM +0000, Wei Liu wrote:
> On Thu, Aug 17, 2023 at 03:01:49PM -0700, Nuno Das Neves wrote:
> > Containing hypervisor ABI definitions to use in mshv driver.
> > 
> > Version numbers for each file:
> > hvhdk.h		25212
> > hvhdk_mini.h	25294
> > hvgdk.h		25125
> > hvgdk_mini.h	25294
> > 
> > These are unstable interfaces and as such must be compiled independently
> > from published interfaces found in hyperv-tlfs.h.
> > 
> > These are in uapi because they will be used in the mshv ioctl API.
> > 
> > Signed-off-by: Nuno Das Neves <nunodasneves at linux.microsoft.com>
> > Acked-by: Wei Liu <wei.liu at kernel.org>
> 
> There were some concerns raised internally about the stability of the
> APIs when they are put into UAPI.
> 
> I think this is still okay, for a few reasons:
> 
>   1. When KVM was first introduced into the kernel tree, it was
>      experimental. It was only made stable after some time.
>   2. There are other experimental or unstable APIs in UAPI. They
>      are clearly marked so.
>   3. The coda file system, which has been in tree since 2008, has a
>      header file in UAPI which clearly marks as experimental.
> 
> All in all introducing a set of unstable / experimental APIs under UAPI
> is not unheard of. Rules could've changed now, but I don't find any
> document under Documentation/.
> 
> I think it will be valuable to have this driver in tree sooner rather
> than later, so that it can evolve with Linux kernel, and we can in turn
> go back to the hypervisor side to gradually stabilize the APIs.
> 
> Greg, I'm told that you may have a strong opinion in this area. Please
> let me know what you think about this.

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.

It's really really hard to make a stable api the first time around, but
we have "tricks" for how to do it well, and ensure that you can slowly
change it over time (proper use of flags and zero-checked padding), but
almost always the simplest way is to just add new apis and keep
supporting the old ones by internally calling the new functions instead.

So, what do you think will change here in the future and why can't you
say "this is stable" now?  You have working userspace code for this api,
right?  What is left to be developed for it?

thanks,

greg k-h