From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH 4/9] xen: sched: add .init_pdata hook to the
 scheduler interface
Date: Thu, 1 Oct 2015 10:32:45 +0100
Message-ID: <560CFDBD.4090005@citrix.com>
References: <20150929164726.17589.96920.stgit@Solace.station>
	<20150929165556.17589.62924.stgit@Solace.station>	<560CC2EC.6030801@suse.com>
	<1443681197.3276.163.camel@citrix.com> <560CE43F.3030809@suse.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=709ed21cb=Andrew.Cooper3@citrix.com>)
	id 1ZhaEN-0002lT-8j
	for xen-devel@lists.xenproject.org; Thu, 01 Oct 2015 09:32:51 +0000
In-Reply-To: <560CE43F.3030809@suse.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Juergen Gross <jgross@suse.com>, xen-devel@lists.xenproject.org, George Dunlap <george.dunlap@eu.citrix.com>
List-Id: xen-devel@lists.xenproject.org

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