linux-kernel - Re: [PATCH v2] smp: kernel/panic.c

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <55ca1d7c-3920-8ea0-e1de-1bf04088db2c@csgroup.eu>
Date:   Thu, 18 Mar 2021 07:04:30 +0100
From:   Christophe Leroy <christophe.leroy@...roup.eu>
To:     Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     He Ying <heying24@...wei.com>, frederic@...nel.org,
        paulmck@...nel.org, clg@...d.org, qais.yousef@....com,
        johnny.chenyi@...wei.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] smp: kernel/panic.c - silence warnings

Le 17/03/2021 à 21:09, Ingo Molnar a écrit :
> 
> * Peter Zijlstra <peterz@...radead.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