On 09/30/2015 06:39 PM, Jan Beulich wrote: >>>> On 30.09.15 at 17:27, <rcojoc...@bitdefender.com> wrote: >> On 09/30/2015 06:23 PM, Jan Beulich wrote: >>>>>> On 30.09.15 at 17:16, <rcojoc...@bitdefender.com> wrote: >>>> VM_EVENT_FLAG_SET_REGISTERS and xc_monitor_emulate_each_rep() are >>>> not available in Xen 4.6, hence the bump. >>> >>> I don't follow: These are additions, not changes that require >>> consumers to adapt their code. >> >> I have code that checks for __XEN_LATEST_INTERFACE_VERSION__ and if it >> is 0x00040700 then it uses xc_monitor_emulate_each_rep(), otherwise it >> knows it can't - I thought that consumers that want to make use of the >> latest API should be able to tell that they're allowed to do so. >> >> But if the Xen convention is to only bump it when the interface is no >> longer backward compatible then I've misunderstood (in which case, sorry >> for the noise, and also, is there another way to tell which Xen version >> I'm compiling against?). > > Just check for the relevant #define to be there.
That does work for VM_EVENT_FLAG_SET_REGISTERS in this case, but it wouldn't have worked if the only addition would have been xc_monitor_emulate_each_rep(). I like the XEN_VERSION and XEN_SUBVERSION #defines in compile.h, but those don't make it into the public headers (that end up in dist/install/usr/include after make dist). But yes, in this case that #define is helpful, and then with autotools or something similar libxc can be checked for xc_monitor_emulate_each_rep(). Again, sorry for the noise and thanks for the help. Thanks, Razvan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
