linux-kernel - Re: [PATCH] kernel/entry: Remove unneeded header "common.h"

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] [day] [month] [year] [list]

Message-ID: <87plf4npaj.ffs@tglx>
Date: Mon, 16 Jun 2025 09:01:08 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Khalid Ali <khaliidcaliy@...il.com>
Cc: khaliidcaliy@...il.com, linux-kernel@...r.kernel.org, luto@...nel.org,
 peterz@...radead.org
Subject: Re: [PATCH] kernel/entry: Remove unneeded header "common.h"

On Sat, Jun 14 2025 at 19:47, Khalid Ali wrote:
>> The reason why common.h exists is that syscall_user_dispatch() is a
>> internal function, which is on purpose not exposed globally. There is no
>> reason to expose it globally, so it stays where it is.
>> Still there is no strong reason "common.h" could exist, there is no doc
>> explicitly mentions that. 
>
> Why can't we just put the prototype into the source since currently it is the
> only place used is common.c, so we should put it on top of the source. Again don't

No. You need the prototype (aka. declaration) for both the usage site
_and_ the definition.

Do I really have to explain the basic C rules?

> see strong reason why entire header exist for single function, even on
> future if more local definations come we should put on top of the
> source, if there is one single source file using it. This makes
> consistent across the entire kernel codebase which mostly do what i
> mentioned.
>
> The only exception for local headers is if the source file using it is
> too large and using many structures, enums and prototypes, in that
> case it is acceptable.

So you define what's acceptable and not?

> However the decision of creation of that local header with no
> exception makes the header pointless.
>
> I didn't find any kernel doc that describes the decision, so we should
> make it consistent with other subsystems if there is no specific
> reason for that this makes the source file more organized.

I explained it to you already why this header exists and there is a
strong emphasis in some subsystems to not expose functions globaly so
that the internals of the subsystem are encapsulated. That's the only
way you can do that in C and it makes a lot of sense.

This _is_ consistent with the rest of the code and you can argue until
you're blue, this header with the declaration of that function stays.

Thanks,

        tglx