Re: [Xen-devel] [PATCH 4/9] xen: sched: add .init_pdata hook to the scheduler interface

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 01/10/15 08:43, Juergen Gross wrote:
> On 10/01/2015 08:33 AM, Dario Faggioli wrote:
>> On Thu, 2015-10-01 at 07:21 +0200, Juergen Gross wrote:
>>> On 09/29/2015 06:55 PM, Dario Faggioli wrote:
>>
>>>> --- a/xen/common/schedule.c
>>>> +++ b/xen/common/schedule.c
>>>> @@ -1407,6 +1407,9 @@ static int cpu_schedule_callback(
>>>>
>>>>        switch ( action )
>>>>        {
>>>> +    case CPU_STARTING:
>>>> +        SCHED_OP(&ops, init_pdata, cpu);
>>>> +        break;
>>>>        case CPU_UP_PREPARE:
>>>>            rc = cpu_schedule_up(cpu);
>>>>            break;
>>>> @@ -1484,6 +1487,7 @@ void __init scheduler_init(void)
>>>>        if ( ops.alloc_pdata &&
>>>>             !(this_cpu(schedule_data).sched_priv =
>>>> ops.alloc_pdata(&ops, 0)) )
>>>>            BUG();
>>>> +    SCHED_OP(&ops, init_pdata, 0);
>>>
>>> You can't call this without having it set in all schedulers.
>>>
>>> I guess using the init_pdata hook has to be introduced after or in
>>> patch 5.
>>>
>> But, if it is not set, it is NULL, in which case, SCHED_OP does the
>> trick for me, doesn't it?
>>
>> #define SCHED_OP(opsptr, fn,
>> ...)                                          \
>>           (( (opsptr)->fn != NULL ) ? (opsptr)->fn(opsptr,
>> ##__VA_ARGS__ )  \
>>            : (typeof((opsptr)->fn(opsptr, ##__VA_ARGS__)))0 )
>
> Aah, yes, of course.
>
> Sorry for the noise.

Another area ripe for cleanup is these macros.  As far as I can tell,
they serve no purpose other than to obscure the code, stop cscope/ctags
from following the calls, and give the preprocessor a headache.

A system like we use for the hvm_func pointers and the static inline
wrappers would be far clearer, and also make it obvious that it is safe
to call with a NULL function pointer.

~Andrew

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