[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

libxl API changes for 4.2 (Was: Re: [Xen-devel] [PATCH] libxl: do not expose libxenctrl/libxenstore headers via libxl.h)



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.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.