From: Julien Grall <julien.grall@linaro.org>
To: Jan Beulich <JBeulich@suse.com>, Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel@lists.xenproject.org, stefano.stabellini@citrix.com,
tim@xen.org
Subject: Re: [PATCH 0/6] xen/arm: Move in/out code to/from init section
Date: Mon, 02 Feb 2015 12:52:31 +0000 [thread overview]
Message-ID: <54CF730F.4010909@linaro.org> (raw)
In-Reply-To: <54CF6A75020000780005BD8E@mail.emea.novell.com>
On 02/02/15 11:15, Jan Beulich wrote:
>>>> On 02.02.15 at 11:58, <Ian.Campbell@citrix.com> wrote:
>> On Fri, 2015-01-30 at 11:33 +0000, Julien Grall wrote:
>>> On 30/01/15 11:30, Ian Campbell wrote:
>>>> On Thu, 2015-01-29 at 18:32 +0000, Julien Grall wrote:
>>>>> Hello,
>>>>>
>>>>> Ping? Any more review for this version of this series?
>>>>
>>>> I was awaiting a version with the declarations in the right places as
>>>> pointed out by Andy (including his point about definition vs. prototype
>>>> I'm afraid, which is the style we use).
>>>
>>> I'm not convince about your last point. We have many places (if not all
>>> on ARM) where __init is used in the header.
>>
>> Those are mistakes, it seems.
>>
>>> Some of them was even added by you ;). So I would prefer if we keep
>>> them, it's more readable. FWIW Linux does it too.
>>
>> I personally don't particularly care where these things go, but other
>> hypervisor maintainers seem to and we should aim for the code base to be
>> consistent where possible.
>>
>> If we want to change this coding style then we should do that directly
>> and explicitly, not through the backdoor by just ignoring the policy.
>
> And I think we should strive to keep pointless redundancy down:
> There's no point in repeating attributes - either they belong on the
> declaration (when producer and consumers care), or they belong
> on the definition (when only the producer cares). Repeating them
> on the definition when the declaration already has them only results
> in needless churn when such an attribute later gets changed/
> removed, and having producer-relevant attributes on declarations
> means needless extra work by the compiler (however little that may
> be - it adds up).
I think we should allow the annotation in both place. When a developer
is looking for the prototype of the function, it will likely look at the
headers and not the implementation itself.
This may lead to call an init function in code running after the boot. I
don't think we can catch it easily during review.
Regards,
--
Julien Grall
next prev parent reply other threads:[~2015-02-02 12:53 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-16 16:20 [PATCH 0/6] xen/arm: Move in/out code to/from init section Julien Grall
2015-01-16 16:20 ` [PATCH 1/6] arm/setup: Add missing __init to add_boot_module Julien Grall
2015-01-16 16:28 ` Andrew Cooper
2015-01-16 16:33 ` Julien Grall
2015-01-16 16:20 ` [PATCH 2/6] xen/arm: domain_build: Move all DOM0 building code in init section Julien Grall
2015-01-16 16:20 ` [PATCH 3/6] xen/arm: kernel: Move kernel loading " Julien Grall
2015-01-16 17:33 ` Vitaly Kuznetsov
2015-01-16 17:49 ` Julien Grall
2015-01-19 10:31 ` Ian Campbell
2015-01-16 16:20 ` [PATCH 4/6] xen/arm: device: Move device_type " Julien Grall
2015-01-16 16:20 ` [PATCH 5/6] xen/arm: platforms: Move init_time and specific_mapping " Julien Grall
2015-01-16 16:20 ` [PATCH 6/6] xen/arm: SMP: Move out of the init section the code to bring up a CPU Julien Grall
2015-01-29 18:32 ` [PATCH 0/6] xen/arm: Move in/out code to/from init section Julien Grall
2015-01-30 11:30 ` Ian Campbell
2015-01-30 11:33 ` Julien Grall
2015-02-02 10:58 ` Ian Campbell
2015-02-02 11:15 ` Jan Beulich
2015-02-02 12:52 ` Julien Grall [this message]
2015-02-02 13:12 ` Jan Beulich
2015-02-02 13:34 ` Julien Grall
2015-02-02 12:48 ` Julien Grall
2015-02-02 13:03 ` Ian Campbell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54CF730F.4010909@linaro.org \
--to=julien.grall@linaro.org \
--cc=Ian.Campbell@citrix.com \
--cc=JBeulich@suse.com \
--cc=stefano.stabellini@citrix.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.