Re: [Xen-devel] [PATCH] tools: set migration constraints from cmdline

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2013-02-04 at 13:09 +0000, Olaf Hering wrote:
> On Mon, Feb 04, Ian Campbell wrote:
> 
> > On Mon, 2013-02-04 at 09:57 +0000, Olaf Hering wrote:
> > > On Wed, Jan 30, Ian Campbell wrote:
> > > 
> > > > On Mon, 2013-01-28 at 17:32 +0000, Olaf Hering wrote:
> > > > > A variant of this change has been tested with xend, the patch below is
> > > > > only compile tested. The changes to libxl change the API, is that
> > > > > approach acceptable?
> > > > 
> > > > I'm afraid not, the compatibility requirements are covered in the
> > > > comment near the top of libxl.h.
> > > > 
> > > > So you either need a new function or to leverage the LIBXL_API_VERSION
> > > > define (which the user must supply) such that people providing 0x040200
> > > > see the current interface and people providing 0x040300 (or nothing) see
> > > > the new one.
> > > 
> > > And to avoid the API change at all, should max_iters and max_factor be
> > > passed via xenstore to xc_domain_save()? So that either the caller of
> > > xc_domain_save reads the values from xenstore, or the function itself
> > > reads it from there. What do you think?
> > 
> > Unfortunately libxc cannot access xenstore.
> 
> In case of xm, it would be the xc_save binary, which can receive both
> values from argv[].
> In case of xl, it would be a xenstore write in main_migrate and a read
> in libxl_domain_suspend. Which would cover also other callers of
> libxl_domain_suspend.

I see, I think this is worse than the LIBXL_API_VERSION approach you've
already implemented.

Also, now I think about it, users of libxl are not expected to have to
use xenstore either.

Ian.


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