Re: [PATCH v2 08/13] libxc: Check xc_domain_maximum_gpfn for negative return values

[Ian Campbell <ian.campbell@citrix.com>]

On Thu, 2015-03-19 at 14:54 -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Mar 19, 2015 at 04:47:58PM +0000, Ian Campbell wrote:
> > On Wed, 2015-03-18 at 20:24 -0400, Konrad Rzeszutek Wilk wrote:
> > > Instead of assuming everything is always OK. We stash
> > > the gpfns value as an parameter.
> > > 
> > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > ---
> > >  tools/libxc/xc_core_arm.c    | 17 ++++++++++++++---
> > >  tools/libxc/xc_core_x86.c    | 24 ++++++++++++++++++++----
> > >  tools/libxc/xc_domain_save.c |  8 +++++++-
> > >  3 files changed, 41 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/tools/libxc/xc_core_arm.c b/tools/libxc/xc_core_arm.c
> > > index 16508e7..26cec04 100644
> > > --- a/tools/libxc/xc_core_arm.c
> > > +++ b/tools/libxc/xc_core_arm.c
> > > @@ -31,9 +31,16 @@ xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
> > >  }
> > >  
> > > 
> > > -static int nr_gpfns(xc_interface *xch, domid_t domid)
> > > +static int nr_gpfns(xc_interface *xch, domid_t domid, unsigned long *gpfns)
> > 
> > You didn't fancy merging the two versions of this then ;-)
> 
> I was not sure where you would want to put them. xc_private looks
> like the best place, but perhaps it should be in an new file?

I also suggested just changing the interface of xc_domain_maximum_gpfn,
in which case it can stay in xc_domain.c. TBH there seems little point
in xc_domain_maximum_gpfn if all callers are using a wrapper, so I think
I'd advocate this approach.

If you want to stick with a wrapper for some reason then xc_private.c
would be an ok choice (its a dumping ground already), or xc_misc.c seems
to have a bunch of not dissimilar functionality in it. I think a new
file would be overkill.

Ian.