[Xen-devel] Re: [PATCH][pvops_dom0][2/4] Introduce the external control operation interface for domain0 ACPI parser

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

On 07/20/09 20:02, Yu, Ke wrote:
>> From: Jeremy Fitzhardinge [mailto:jeremy@xxxxxxxx]
>> Sent: Tuesday, July 21, 2009 4:32 AM
>> To: Yu, Ke
>> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Tian, Kevin
>> Subject: Re: [PATCH][pvops_dom0][2/4] Introduce the external control
>> operation interface for domain0 ACPI parser
>>
>> On 07/18/09 23:46, Yu, Ke wrote:
>>     
>>> diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
>>> index abbe2bb..49ccb84 100644
>>> --- a/drivers/acpi/processor_idle.c
>>> +++ b/drivers/acpi/processor_idle.c
>>> @@ -425,6 +425,12 @@ static int
>>>       
>> acpi_processor_get_power_info_cst(struct acpi_processor *pr)
>>     
>>>                 cx.power = obj->integer.value;
>>>
>>> +#ifdef CONFIG_PROCESSOR_EXTERNAL_CONTROL
>>> +               /* cache control methods to notify external logic */
>>> +               if (processor_pm_external())
>>> +                       memcpy(&cx.reg, reg, sizeof(*reg));
>>> +#endif /* CONFIG_PROCESSOR_EXTERNAL_CONTROL */
>>>
>>>       
>> This #ifdef should be unnecessary.
>>     
>
> This "#ifdef" is the counterpart of the following patch. The cx.reg 
> definition is embraced by CONFIG_PROCESSOR_EXTERNAL_CONTROL, so the code 
> manipulating on the cx.reg also need "#ifdef 
> CONFIG_PROCESSOR_EXTERNAL_CONTROL"
>   

I see.  In that case it might be better to wrap the memcpy up with an
inline function which can be defined either way, to keep the #ifdef out
of the code itself.

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel