Mailing List Archive: Xen: API

[Xen-devel] libxl stable API (Re: 4.2 TODO update)

Index | Next | Previous | View Threaded

Ian.Jackson at eu

Mar 14, 2012, 4:16 AM

Post #1 of 2 (160 views)
Permalink

[Xen-devel] libxl stable API (Re: 4.2 TODO update)

Ian Campbell writes ("[Xen-devel] libxl stable API (Re: 4.2 TODO update)"):
> Lastly we also to decide what we want to do about ABI (as opposed to
> API) compatibility. Obviously if we change the ABI then we should change
> the SONAME, but is this something we want to commit to avoiding? i.e.
> should it be possible to build a downstream against libxl.so.2.0 (the
> current libxl soname) from 4.2 and expect that dropping in libxl.so.2.0
> >from 4.3 will Just Work against the new hypervisor interfaces? Or do we
> expect that 4.3 will provide libxl.so.2.1 and that the same downstream
> source can be built twice? (e.g. with the correct one selected via some
> plugin mechanism). Obviously avoiding ABI changes is a lot harder and
> I'm not sure if that is something we are able to commit to at this stage
> (and I'm not sure how good we would be at it even if we did try and make
> that commitment).

I agree with most of what you say.

I don't think we can commit to not making ABI changes. It is thus an
unfortunate fact that the whole stack, from libxl caller on down to
the hypervisor, will have to change together when the version of Xen
is updated.

> > * Safe fork vs. fd handling hooks. This is an API
> > addition, so maybe not required fro stable API, bit need
> > to have for 4.2? (Ian J, patches posted)

I think this is important to have. It will imply changes to quite a
few ordinary api functions.

Ian.

_______________________________________________
xen-api mailing list
xen-api [at] lists
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api

Ian.Campbell at citrix

Mar 14, 2012, 6:37 AM

Post #2 of 2 (172 views)
Permalink

Re: [Xen-devel] libxl stable API (Re: 4.2 TODO update) [In reply to]

On Wed, 2012-03-14 at 11:16 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] libxl stable API (Re: 4.2 TODO update)"):
> > Lastly we also to decide what we want to do about ABI (as opposed to
> > API) compatibility. Obviously if we change the ABI then we should change
> > the SONAME, but is this something we want to commit to avoiding? i.e.
> > should it be possible to build a downstream against libxl.so.2.0 (the
> > current libxl soname) from 4.2 and expect that dropping in libxl.so.2.0
> > >from 4.3 will Just Work against the new hypervisor interfaces? Or do we
> > expect that 4.3 will provide libxl.so.2.1 and that the same downstream
> > source can be built twice? (e.g. with the correct one selected via some
> > plugin mechanism). Obviously avoiding ABI changes is a lot harder and
> > I'm not sure if that is something we are able to commit to at this stage
> > (and I'm not sure how good we would be at it even if we did try and make
> > that commitment).
>
> I agree with most of what you say.

Thanks. I shall add "agree & document compatibility guarantees +
associated technical measures" to the TODO list.

> I don't think we can commit to not making ABI changes. It is thus an
> unfortunate fact that the whole stack, from libxl caller on down to
> the hypervisor, will have to change together when the version of Xen
> is updated.

Right. We can strive to make this a straight rebuild with no source
changes (somewhat akin to a binNMU in Debian-speak).

>
> > > * Safe fork vs. fd handling hooks. This is an API
> > > addition, so maybe not required fro stable API, bit need
> > > to have for 4.2? (Ian J, patches posted)
>
> I think this is important to have. It will imply changes to quite a
> few ordinary api functions.

Thanks, I will update the commentary accordingly in the next iteration.

Ian.

_______________________________________________
xen-api mailing list
xen-api [at] lists
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads