On Fri, Jan 13, 2017 at 04:56:55AM -0700, Jan Beulich wrote: > >>> On 13.01.17 at 12:40, <daniel.ki...@oracle.com> wrote: > > On Fri, Jan 13, 2017 at 04:16:01AM -0700, Jan Beulich wrote: > >> >>> On 12.01.17 at 22:59, <eric.devol...@oracle.com> wrote: > >> > CC: Elena Ufimtseva <elena.ufimts...@oracle.com> > >> > CC: Daniel Kiper <daniel.ki...@oracle.com> > >> > >> Cc: Andrew Cooper <andrew.coop...@citrix.com> > >> (as the kexec maintainer) > >> > >> > Note: The __XEN_LATEST_INTERFACE_VERSION__ has been bumped to > >> > 0x00040900 due to the introduction of a new hypervisor call. > >> > >> This bumping is required only if something changes in the interface > >> such that e.g. source code would need adjustment to not fail to > >> build. > > > > We need a check in kexec-tools to verify that STATUS hypercall > > is available. Otherwise we can disable relevant functionality. > > I thought that we can do that because __XEN_LATEST_INTERFACE_VERSION__ > > is exposed via public headers. > > No, you should check for KEXEC_CMD_kexec_status being defined > instead. That'll also cover someone backporting the change to their > packages.
OK, this also works for us. Eric, please drop __XEN_LATEST_INTERFACE_VERSION__ change and add KEXEC_CMD_kexec_status check to kexec-tools configure script. Sorry for confusion. Jan, so, __XEN_LATEST_INTERFACE_VERSION__ is used only for Xen internal purposes (eg. for xl build, etc.) and should not be used as a reference point externally, e.g. in kexec-tools? Daniel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
