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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 19/02/2016 19:36, Konrad Rzeszutek Wilk wrote:
>>>  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.

The important bit (for logically associating different bits of code) is
to have the main stem matching the hypercall op name.  Simply
"xsplice_op()" would be ok, and could naturally be extended to
arch_xsplice_op() if the need arises.

>>> +        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?

The purpose is for simplifying the in-hypervisor codepaths, rather than
performance.  (A side effect would be to reduce the size of the
alternatives table patching stac/clac instructions).

~Andrew

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