[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZN6m2gVmtVStuEfA@liuwe-devbox-debian-v2>
Date: Thu, 17 Aug 2023 23:01:46 +0000
From: Wei Liu <wei.liu@...nel.org>
To: Nuno Das Neves <nunodasneves@...ux.microsoft.com>
Cc: linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org,
x86@...nel.org, linux-arm-kernel@...ts.infradead.org,
linux-arch@...r.kernel.org, patches@...ts.linux.dev,
mikelley@...rosoft.com, kys@...rosoft.com, wei.liu@...nel.org,
haiyangz@...rosoft.com, decui@...rosoft.com,
apais@...ux.microsoft.com, Tianyu.Lan@...rosoft.com,
ssengar@...ux.microsoft.com, mukeshrathor@...rosoft.com,
stanislav.kinsburskiy@...il.com, jinankjain@...ux.microsoft.com,
vkuznets@...hat.com, tglx@...utronix.de, mingo@...hat.com,
bp@...en8.de, dave.hansen@...ux.intel.com, hpa@...or.com,
will@...nel.org, catalin.marinas@....com,
Greg KH <gregkh@...uxfoundation.org>
Subject: Re: [PATCH v2 13/15] uapi: hyperv: Add mshv driver headers hvhdk.h,
hvhdk_mini.h, hvgdk.h, hvgdk_mini.h
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@...ux.microsoft.com>
> Acked-by: Wei Liu <wei.liu@...nel.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.
KY, do you have an opinion here?
Thanks,
Wei.
Powered by blists - more mailing lists