This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


libxl API changes for 4.2 (Was: Re: [Xen-devel] [PATCH] libxl: do not ex

To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: libxl API changes for 4.2 (Was: Re: [Xen-devel] [PATCH] libxl: do not expose libxenctrl/libxenstore headers via libxl.h)
From: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Date: Wed, 13 Apr 2011 12:03:48 +0100
Cc: Jim Fehlig <jfehlig@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Wed, 13 Apr 2011 04:04:47 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1302689173.5997.22.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <3aecf852f357e9217144.1302103165@xxxxxxxxxxxxxxxxxxxxx> <19868.35898.53337.358242@xxxxxxxxxxxxxxxxxxxxxxxx> <4D9D9263020000780003A58E@xxxxxxxxxxxxxxxxxx> <1302166342.27835.22.camel@xxxxxxxxxxxxxxxxxxxxxx> <19869.35524.73748.363114@xxxxxxxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1104071122140.3290@kaball-desktop> <4DA52169.5080502@xxxxxxxxxx> <1302689173.5997.22.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Ian Campbell writes ("libxl API changes for 4.2 (Was: Re: [Xen-devel] [PATCH] 
libxl: do not expose libxenctrl/libxenstore headers via libxl.h)"):
> We're sorry about this, the API in 4.1 isn't one we are comfortable
> supporting as a long term thing, it has some rough edges and various
> inconsistencies. There's a bit of a chicken and egg situation with the
> clients since sometimes you need to see what users are doing in practice
> in order to figure out what the best long term API is.

My apologies too.

> We hope to iron it out for the 4.2 release and have a more stable
> interface from then, although of course the API will still evolve, but
> more slowly and the intention is to try and preserve compatibility where
> possible.

Indeed so.

> I think IanJ wants to fixup the event API as well, it's a bit barking at
> the moment.

Yes, it's completely mad and needs to be redone.

> IanJ is also going to be looking at the handling of storage backends, I
> expect that is moistly going to be internal to the library but it might
> have an impact on the API too.

Indeed so.  It's likely to make domain creation in principle
asynchronous, since we want to call out to scripts which might block.

> >   Seems best for clients to target new releases (4.1, 4.2, ...)
> > and expect branch releases (4.1.1, 4.1.2, ...) to have a stable
> > API?
> That seems like a reasonable expectation to me.

Yes.  And, we hope the changes after 4.2 will be much smaller although
it will depend on how many of our fixes we manage to get into 4.1.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>