Re: [Xen-devel] [PATCH v4 04/14] argo: init, destroy and soft-reset, with enable command line opt

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Tue, Jan 15, 2019 at 05:42:16AM -0700, Jan Beulich wrote:
> >>> On 15.01.19 at 13:29, <roger.pau@xxxxxxxxxx> wrote:
> > On Tue, Jan 15, 2019 at 01:27:36AM -0800, Christopher Clark wrote:
> >>  long
> >>  do_argo_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg1,
> >>             XEN_GUEST_HANDLE_PARAM(void) arg2, unsigned long arg3,
> >>             unsigned long arg4)
> >>  {
> >> -    return -ENOSYS;
> >> +    long rc = -EFAULT;
> >> +
> >> +    argo_dprintk("->do_argo_op(%u,%p,%p,%lu,0x%lx)\n", cmd,
> >> +                 (void *)arg1.p, (void *)arg2.p, arg3, arg4);
> >> +
> >> +    if ( unlikely(!opt_argo_enabled) )
> >> +        return -EOPNOTSUPP;
> > 
> > I think this should return -ENOSYS, an hypervisor built with
> > CONFIG_ARGO but without argo enabled on the command line shouldn't
> > behave differently than an hypervisor build without CONFIG_ARGO.
> 
> We've been there before, and there appears to be disagreement.
> I support the use of -EOPNOTSUPP here.

I withdraw my comment then.

> >> --- a/xen/include/xen/sched.h
> >> +++ b/xen/include/xen/sched.h
> >> @@ -490,6 +490,11 @@ struct domain
> >>          unsigned int guest_request_enabled       : 1;
> >>          unsigned int guest_request_sync          : 1;
> >>      } monitor;
> >> +
> >> +#ifdef CONFIG_ARGO
> >> +    /* Argo interdomain communication support */
> >> +    struct argo_domain *argo;
> > 
> > I'm likely missing something, but argo_domain is declared in argo.c,
> > don't you need a forward declaration here for this to build?
> 
> That would be needed in C++ (iirc), but not in C, where such
> forward declarations are needed solely when the type is used
> as a function parameter, as otherwise that parameter's type
> ends up having scope local to the declared function.

Oh, OK, sorry for the noise.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel