From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: kdump with xen-unstable on efi machine Date: Thu, 27 Nov 2014 11:51:15 +0000 Message-ID: <54771033.605@citrix.com> References: <5475C466.6010605@suse.com> <5475CA7A.7050200@citrix.com> <5475DD4F.9060203@suse.com> <5475E311.6070501@citrix.com> <1417081768.11944.70.camel@citrix.com> <54770582.80207@citrix.com> <1417087963.12784.11.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1417087963.12784.11.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Juergen Gross , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org 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