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

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Wed, 2011-04-13 at 05:07 +0100, Jim Fehlig wrote:
> Stefano Stabellini wrote:
> > I agree with you on the general principle but I suspect it is going to
> > be almost a rewrite at the end of this development cycle :-/
> >   
> 
> :-( For clients' sake, I hope the API stabilizes in 4.2 timeframe,

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.

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.

> and no backports to 4.1 break the API in that branch.

I think that's something we should be avoiding.

>   IIRC, there have been
> other API-incompatible libxl changes since 4.1.

Yes, there have.

The removal of the domid field from the devices springs to mind (in many
cases you can omit setting it even on 4.1 though, as it happens). So
does the change of the ctx type from a struct to an opaque pointer (the
parent thread of this mail).

Going forward these are the things which spring to mind for 4.2:

Some of the enum value names will also be changed to allow them to be
more consistently autogenerated (although a compat.h style thing could
help here).

A related change is the fixing of the TaggedUnion type in the idl into
something with semantics which map onto language bindings in a sensible
way.

The specification of specific hvmloader and qemu-dm binaries is also
likely to be deprecated soon, the user will just need to ask for old or
new qemu and libxl will figure the rest out (it will still be possible
to override if desired)

I've also been wondering what can/should be done about the split between
libxl_domain_create_info, libxl_domain_build_info and
libxl_device_model_info now that they are all bundled together in
libxl_domain_config and not exposed directly in the API (since the
related functions became internal, that was before 4.1). It seems like
there ought to be scope for collapsing those datastructures somewhat but
I'm not sure how yet.

The topologyinfo datastructure should be a list of tuples, not a tuple
of lists.

The API seems to expose a bunch of console related datastructures but
not much in the way of functions to do anything with them. One of those
must be wrong.

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

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.

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

Ian.



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