Re: [PATCH v3 01/23] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op (v10)

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

> >  long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
> >  {
> > @@ -460,6 +461,12 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
> >          ret = tmem_control(&op->u.tmem_op);
> >          break;
> >  
> > +    case XEN_SYSCTL_xsplice_op:
> > +        ret = xsplice_control(&op->u.xsplice);
> 
> Could we name this do_xsplice_op() to match prevailing subop style.

There are two instances of that: do_get_pm_info, do_pm_op.

Then variations of 'do' are: cpupool_do_sysctl, arch_do_physinfo, and
arch_do_sysctl.

And then ones enjoying 'op' in it:
sysctl_coverage_op

And then 'control' ones:
spinlock_profile_control, tmem_control, perfc_control, tb_control.

So we have 2 vs 3 vs 1 vs 4.

I would say that the name 'xsplice_control' is the prevailing style?

Unless you want me to take a union of them, perhaps:

 do_xsplice_control_op ?

<chuckles>

I will change it to what you prefer - do_xsplice_op.
> 
> > +        if ( ret != -ENOSYS )
> > +            copyback = 1;
> > +        break;
> > +
> 
> Not related to this patch.  I (and by this, I mean someone with time ;p)
> should do some cleanup and pass copyback by pointer to subops.  This
> allows for finer grain control of whether a copyback is needed.

Yes indeed. But then how often do you do sysctl hypercalls?