Re: [Xen-devel] kdump with xen-unstable on efi machine

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2014-11-27 at 11:05 +0000, Andrew Cooper wrote:
> On 27/11/14 09:49, Ian Campbell wrote:
> > On Wed, 2014-11-26 at 14:26 +0000, Andrew Cooper wrote:
> >> libxc (or some new alternative) should suck it up and gain some notion
> >> of a stable API or ABI (like the rest of the world appears to be able to
> >> manage), such that it is possible to compile with an older header and
> >> use a newer .so at runtime.
> > Retrofitting a stable API/ABI to the melting pot which is libxc simply
> > isn't going to work in practice.
> >
> > IMO the most likely to succeed approach would be to split off the bits
> > of libxc which 3rd party's can/should/need to rely on into one of more
> > libraries, probably by functional area.
> >
> > So far I'm aware of plans (or at least desires) to do that for:
> >
> >       * Interfaces used by device-models/qemu.
> >       * The bits which are useful inside a guest (i.e. the
> >         various /dev/xen/* related helpers).
> >
> > So it sounds like libxenkexec should be added to that list.
> >
> > Ian.
> >
> 
> Agreed.
> 
> For a domU, I think we need libxenevt, libxengnt and libxenstore with
> stable API and ABIs.  This in turn will permit libvchan to work without
> needing libxenctrl.
>
> For dom0, each of the libraries is going to need basic hypercall
> functionality.  It might be worth considering making libxenbasic (name
> looking for improvement) which is more along the lines of a privcmd
> driver, providing do_hypercall() and bounce buffering.

> libxenctrl and
> others can then avoid reimplementing the wheel many times.

NB that if such a library contains the h/call wrappers for any
non-stable hypercall interface (I'm not sure if that was what you were
suggesting or not) then it would itself remain ABI/API unstable.

But anyway there's nothing stopping libxen* using interfaces exposed by
an unstable libxenctrl or libxenbasic and remaining interface stable
themselves, so you can avoid reimplementing the wheel that way.

Those libraries just need to do the impedance matching and link the
correct SONAME for the unstable library, the linker will take care of
the rest.

I don't think it is going to be realistic in practice to support keeping
the exact same libxenfoo.so.N binary working across multiple releases,
but rather each release will provide its own libxenfoo.so.N with the
same N and supporting the same ABI, such that it can just be swapped in
under the feet of the application.

The alternative is to do dlopen stuff on the unstable backend library,
which is going to be a nightmare, from the test matrix PoV if nothing
else.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel