mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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