Re: [Minios-devel] [PATCH 3/3] mini-os: support "make config" for out-of-tree users

[Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>]

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

_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/minios-devel