[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)
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |