|
[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 |