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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 27/11/14 11:32, Ian Campbell wrote:
> 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.

I was suggesting do_hypercall() and specifically not things like
do_domctl().  do_hypercall() is a think wrapper around ioctl(), which
will be stable going forwards.  This allows a consumer to use stable
hypercalls and keep stability.

libxenctrl/libxenguest can implement do_domctl() in terms of
do_hypercall(), and gain the inherent instability that comes with this.

However, I think all of these are design decisions to be considered by
whomever tackles this chunk of work :)

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

libxenctrl, being an explicit unstable API and ABI cannot reasonably be
used by something claiming to provide a stable ABI, without libxenctrl
changing its stance on what is considered stable and what is not.  I
suppose the advantage of this is that it can be sorted with some paperwork.

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

I believe that this covers our intentions, and appears to be the common
way of doing things.

~Andrew


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