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

[Juergen Gross <jgross@xxxxxxxx>]

On 02/09/16 03:21, Samuel Thibault wrote:
> 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.

Very good.

>> 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.

I think 0x00030205 should be the minimum version Mini-OS has to support.

> - 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.

I think I'll add a new make target "test" which will test different
build configurations (PARAVIRT y/n, BALLOON y/n, 32/64 bit, Xen
interface versions, all/no frontends). This can be easily added to
OSStest.

> - 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.

Right.

> 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.

Okay, I'll update the patch description and add some README contents.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel