Re: [Hackathon Minutes] Xen 4.4 Planning

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Fri, Jun 14, 2013 at 10:46:31AM +0100, Ian Murray wrote:
> 
> 
> 
> 
> ----- Original Message -----
> > From: Alex Bligh <alex@alex.org.uk>
> > To: Ian Murray <murrayie@yahoo.co.uk>; xen-devel@lists.xen.org
> > Cc: Alex Bligh <alex@alex.org.uk>
> > Sent: Friday, 14 June 2013, 8:01
> > Subject: Re: [Xen-devel] [Hackathon Minutes] Xen 4.4 Planning
> > 
> > Ian,
> > 
> > --On 14 June 2013 00:56:14 +0100 Ian Murray <murrayie@yahoo.co.uk> wrote:
> > 
> >>  When you talk about "stuff" breaking between major releases, are 
> > you
> >>  talking about Xen code not functioning or your code failing because of
> >>  changes in Xen? If the latter, are we talking designed changes in Xen's
> >>  behaviour or non-designed ones (=bugs)?
> > 
> > Both.
> > 
> > As an example of the first, the API changed very significantly between
> > 3.x and 4.1, and 4.1 and 4.2. Some of the API changes were subtle (e.g.
> > what you had to do across a fork()).
> 
> But surely, this is your business. This is what you do. Sounds like you want API changes to be held back for the entire community so your company has to do less work.

That is not true. I know what Alex is referring. I used to work
for VirtualIron and we had our own C based 'agent' that would interface
with libxc. Meaning we did not have 'xend', nor any 'xl'. Launching of
guests, etc was all done via our 'agent'.

What we had issues was that when compiling against a new hypervisor
API it all compiled, but launching guests was broken. What we found was
that some structures had changed and their corresponding XEN_VERSION_SOMETHING
changed as well. But it was not clear _which_ of the structures changed
so it took a while to figure out that the cpumap had been changed
(I think that is what it was). There was also some HVM parameter field
that had to be added otherwise the guest would not boot (can't remember
the details).

The XEN_VERSION_someting in the header doesn't really say - what
had changed. It is incremented to guard against this (so the call to
the hypervisor will error out with -ENOSYS if you don't use the
right version)- but worst it does not provide very much a backwards
compatible way of having a runtime work against Xen 4.1 vs Xen 4.3
(or Xen 3.4).

And now looking back at Xen 4.3 I have to admin that I did this as well
- so the xcinfo has an extra unsigned long in it expanding it.

I am not really sure how to solve that. The 'libxl' should provide a nice
isolation layer for this kind of stuff and guard the consumers
of the API with the #NEW_SOMETHING_FEATURE_ADDED defines.