From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Ingo Molnar <mingo@kernel.org>, Peter Zijlstra <peterz@infradead.org>
Cc: He Ying <heying24@huawei.com>,
frederic@kernel.org, paulmck@kernel.org, clg@kaod.org,
qais.yousef@arm.com, johnny.chenyi@huawei.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] smp: kernel/panic.c - silence warnings
Date: Thu, 18 Mar 2021 07:04:30 +0100 [thread overview]
Message-ID: <55ca1d7c-3920-8ea0-e1de-1bf04088db2c@csgroup.eu> (raw)
In-Reply-To: <20210317200922.GC3830960@gmail.com>
Le 17/03/2021 à 21:09, Ingo Molnar a écrit :
>
> * Peter Zijlstra <peterz@infradead.org> wrote:
>
>> Now, the C people figured that distinction was useless and allowed
>> sloppiness. But I still think there's merrit to that. And as
>> mentioned earlier, it is consistent with variable declarations.
>
> Fully agreed, and my other point was that it's also consistent with
> the other existing externs were used *in the same header file*
> already.
>
> I.e. there's nothing more sloppy than mixing different styles within
> the same header. Checkpatch needs to be fixed or ignored here.
>
As pointed by He there are already many prototypes not flagged 'extern' in that header. Blaming the
file shows that most remaining 'extern' are from the old days.
So adding new function prototypes with the 'extern' keywork wouldn't make the file less sloppy but
would be a step backwards.
I think there is a will to make all those unneccessary 'extern' flags disappear on the long term. To
achieve that there are two ways: Either smoothly do it on every function prototype modified or added
or at a point in time big-bang convert the entire file. The later hinders blamability of the file.
Maybe one day we'll convert all remaining 'extern' away once they have become the minority. To
achieve that we really need to not add new ones.
Christophe
next prev parent reply other threads:[~2021-03-18 6:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-16 8:41 He Ying
2021-03-17 9:49 ` Ingo Molnar
2021-03-17 11:00 ` Christophe Leroy
2021-03-17 12:23 ` Peter Zijlstra
2021-03-17 17:17 ` Christophe Leroy
2021-03-17 17:37 ` Peter Zijlstra
2021-03-17 20:09 ` Ingo Molnar
2021-03-18 2:56 ` heying (H)
2021-03-18 6:11 ` Christophe Leroy
2021-03-18 6:04 ` Christophe Leroy [this message]
2021-03-18 5:53 ` Christophe Leroy
2021-03-19 1:39 ` heying (H)
2021-03-19 6:58 ` Christophe Leroy
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=55ca1d7c-3920-8ea0-e1de-1bf04088db2c@csgroup.eu \
--to=christophe.leroy@csgroup.eu \
--cc=clg@kaod.org \
--cc=frederic@kernel.org \
--cc=heying24@huawei.com \
--cc=johnny.chenyi@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=qais.yousef@arm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome