[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fd28654f-e0c8-e8a1-80f7-8451596fcadc@citrix.com>
Date: Mon, 4 Sep 2017 11:35:16 +0100
From: Andrew Cooper <andrew.cooper3@...rix.com>
To: Jan Beulich <JBeulich@...e.com>,
Nicolas Iooss <nicolas.iooss_linux@....org>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Juergen Gross <jgross@...e.com>
CC: <xen-devel@...ts.xenproject.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/1] x86/xen: fix section of
xen_init_time_ops() in header
On 04/09/17 11:15, Jan Beulich wrote:
>>>> On 04.09.17 at 10:17, <jgross@...e.com> wrote:
>> On 03/09/17 10:38, Nicolas Iooss wrote:
>>> Commit d162809f85b4 ("xen/x86: Do not call xen_init_time_ops() until
>>> shared_info is initialized") moved xen_init_time_ops() from __init to
>>> __ref without updating xen-ops.h accordingly. Fix this.
>>>
>>> Fixes: d162809f85b4 ("xen/x86: Do not call xen_init_time_ops() until
>>> shared_info is initialized")
>>> Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@....org>
>>> ---
>>> arch/x86/xen/xen-ops.h | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
>>> index 0d5004477db6..b2a5d48a2c2a 100644
>>> --- a/arch/x86/xen/xen-ops.h
>>> +++ b/arch/x86/xen/xen-ops.h
>>> @@ -69,7 +69,7 @@ void xen_setup_runstate_info(int cpu);
>>> void xen_teardown_timer(int cpu);
>>> u64 xen_clocksource_read(void);
>>> void xen_setup_cpu_clockevents(void);
>>> -void __init xen_init_time_ops(void);
>>> +void __ref xen_init_time_ops(void);
>>> void __init xen_hvm_init_time_ops(void);
>> When correcting this could you please modify the prototypes to comply to
>> the intended form as noted in include/linux/init.h (the __ref or __init
>> annotations should be just before the ending semicolon)?
> Why would these annotations be kept on the declarations anyway?
> Attributes affecting code/data placement generally belong on the
> definitions only.
Because:
a) That’s what the coding style says, and
b) So various static analysis can be done (e.g. sparse) on an individual
translation unit basis.
Your objection to having annotations on declarations is why I've never
got around to adding sparse to the hypervisor build.
~Andrew
Powered by blists - more mailing lists