Hello, Juergen Gross, on Thu 01 Sep 2016 08:21:33 +0200, wrote: > I stumbled over the problem with xenstore-stubdom: xenstore is using > __XEN_LATEST_INTERFACE_VERSION__ when being compiled. This produced a > build error with Mini-OS (console_evtchn in include/console.h was > #define'd to console.domU.evtchn by include/xen/xen.h). It was pure > luck such a problem didn't occur before my recent changes. > > I think it is much more reasonable to compile all parts of a stubdom > with the same Xen interface version instead of letting use the core of > Mini-OS an ancient version and the App using Mini-OS another one.
Ok, I agree with that. > So I added XEN_INTERFACE_VERSION to be configurable. > This requires some adjustments in Mini-OS, of course. That is the > purpose of patch 1 of this series. Ok, now I better understand the issue, pros and cons, etc. It would be better to clearly document and test it: AIUI, - interface version compatibility is not so great: some features are e.g. just *not* available when using interface version 0, so if mini-os tries to use newer interfaces while stubdom asks for an older interface version, it will fail to build, so it may need #ifs to check for presence of the interface, and gracefully disable using the feature instead of failing-to-build. - mini-os happens not to be able to build with interface version 0, basically because the current default is 0x00030205 and so nobody tests with 0. Notably due to the console_evtchn #define, but also the use of set_xen_guest_handle. Ideally we'd fix it, but I guess nobody will want something older than that anyway, so we probably don't want to handle the burden. - to be able to let the stubdom application decide which interface version it wants to build against, mini-os must be buildable standalone with all versions from 0x00030205 to latest supported (which is what patch 1 fixes). A not too bad approximation of this would be to be able to build it with the minimum supported version and with latest version. Perhaps we can declare that Config.mk's default interface version is the minimum supported, so building standalone mini-os will test that, and since as you say we already build the xenstore-stubdom with latest version, building the xenstore-stubdom will test that. - that way, stubdom applications can choose the level of compatibility they wish from mini-os' minimum supported to mini-os' latest supported. - whenever somebody would like to use an interface version which is not supported by mini-os headers yet, we just need to update mini-os' headers, and we have to fix the build with the minimum supported version and with the latest supported version. So if you agree with my reasoning, I'd say that the patch series should document all that along the definition of XEN_INTERFACE_VERSION in Config.mk: explaining that this default is the minimum supported interface version, which the application can override up to the latest supported by mini-os, and if a yet-newer interface is needed, one should upgrade the headers, and before committing, try to build mini-os both with the same minimum supported version for compatibility, and with the latest version. Samuel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel