On 11/8/2024 4:02 AM, Nuno Das Neves wrote:
These headers contain definitions for regular Hyper-V guests (as in
hyperv-tlfs.h), as well as interfaces for more privileged guests like
Dom0.
These files are derived from headers exported from Hyper-V, rather than
being derived from the TLFS document. (Although, to preserve
compatibility with existing Linux code, some definitions are copied
directly from hyperv-tlfs.h too).
The new files follow a naming convention according to their original
use:
- hdk "host development kit"
- gdk "guest development kit"
With postfix "_mini" implying userspace-only headers, and "_ext" for
extended hypercalls.
Naming convention for mini (which may have come from HyperV code) is a
bit odd TBH. May be it has more to it than what is mentioned here or
what I know. If more information helps, or this can be changed, please see.
These names should be considered a rough guide only - since there are
many places already where both host and guest code are in the same
place, hvhdk.h (which includes everything) can be used most of the time.
The original names are kept intact primarily to keep the provenance of
exactly where they came from in Hyper-V code, which is helpful for
manual maintenance and extension of these definitions. Microsoft
maintainers importing new definitions should take care to put them in
the right file.
Note also that the files contain both arm64 and x86_64 code guarded by
\#ifdefs, which is how the definitions originally appear in Hyper-V.
Keeping this convention from Hyper-V code is another tactic for
simplying the process of importing new definitions.
These headers are a step toward importing headers directly from Hyper-V
in the future, similar to Xen public files in include/xen/interface/.
Signed-off-by: Nuno Das Neves <nunodasneves@xxxxxxxxxxxxxxxxxxx>
While I understand the motivation behind this series that this is going
to ease out the process of updating the header files with respect to
HyperV, I think, we will need to pay attention to what we are bringing
in with these headers, whether there are any users of it or not, and
make sure that TLFS document is updated regularly, to avoid having bunch
of code with no information of it.
The code comments in these files are one step forward towards that.
And from your cover letter it seems that some changes which actually
make use of these additional interfaces are underway, so things will
make more sense later. For now, this looks good to me.
Regards,
Naman
<snip>
