[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/2] xen/arm: add support for vm_assist hypercall
On 20/05/16 16:34, Jan Beulich wrote: >>>> On 20.05.16 at 15:22, <JGross@xxxxxxxx> wrote: >> --- a/xen/common/domain.c >> +++ b/xen/common/domain.c >> @@ -1408,7 +1408,6 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, >> XEN_GUEST_HANDLE_PARAM(void) arg) >> return rc; >> } >> >> -#ifdef VM_ASSIST_VALID >> long vm_assist(struct domain *p, unsigned int cmd, unsigned int type, >> unsigned long valid) >> { >> @@ -1427,7 +1426,6 @@ long vm_assist(struct domain *p, unsigned int cmd, >> unsigned int type, >> >> return -ENOSYS; >> } >> -#endif >> >> struct pirq *pirq_get_info(struct domain *d, int pirq) >> { >> --- a/xen/common/kernel.c >> +++ b/xen/common/kernel.c >> @@ -441,12 +441,10 @@ DO(nmi_op)(unsigned int cmd, >> XEN_GUEST_HANDLE_PARAM(void) arg) >> return rc; >> } >> >> -#ifdef VM_ASSIST_VALID >> DO(vm_assist)(unsigned int cmd, unsigned int type) >> { >> return vm_assist(current->domain, cmd, type, VM_ASSIST_VALID); >> } >> -#endif > > Removing these #ifdef-s is neither necessary for this patch (at least > afaict) nor desirable (after all they had got added so that an arch > doesn't get this code compiled for no reason). Removing is not necessary, right. OTOH there is no arch left needing those #ifdef-s to be in place. Or do you think we should guard each single functionality in xen/common by such means? I don't think so. In this case keeping the #ifdef-s would be for historical reasons only. If you really want I can keep them or do the removal in a separate patch if you want to split functional addition and related cleanup. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |