linux-kernel - Re: [PATCH v5 5/5] objtool: Rework header include paths

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]

Date:   Fri, 13 Nov 2020 09:06:40 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Vasily Gorbik <gor@...ux.ibm.com>
Cc:     Josh Poimboeuf <jpoimboe@...hat.com>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
        Miroslav Benes <mbenes@...e.cz>,
        Alexandre Chartre <alexandre.chartre@...cle.com>,
        Julien Thierry <jthierry@...hat.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 5/5] objtool: Rework header include paths

On Fri, Nov 13, 2020 at 12:03:32AM +0100, Vasily Gorbik wrote:
> Currently objtool headers are being included either by their base name
> or included via ../ from a parent directory. In case of a base name usage:
> 
>  #include "warn.h"
>  #include "arch_elf.h"
> 
> it does not make it apparent from which directory the file comes from.
> To make it slightly better, and actually to avoid name clashes some arch
> specific files have "arch_" suffix. And files from an arch folder have
> to revert to including via ../ e.g:
>  #include "../../elf.h"
> 
> With additional architectures support and the code base growth there is
> a need for clearer headers naming scheme for multiple reasons:
> 1. to make it instantly obvious where these files come from (objtool
>    itself / objtool arch|generic folders / some other external files),
> 2. to avoid name clashes of objtool arch specific headers, potential
>    obtool arch generic headers and the system header files (there is
>    /usr/include/elf.h already),
> 3. to avoid ../ includes and improve code readability.
> 4. to give a warm fuzzy feeling to developers who are mostly kernel
>    developers and are accustomed to linux kernel headers arranging
>    scheme.
> 
> Doesn't this make it instantly obvious where are these files come from?
> 
>  #include <objtool/warn.h>
>  #include <arch/elf.h>
> 
> And doesn't it look nicer to avoid ugly ../ includes? Which also
> guarantees this is elf.h from the objtool and not /usr/include/elf.h.
> 
>  #include <objtool/elf.h>
> 
> This patch defines and implements new objtool headers arranging
> scheme. Which is:
> - all generic headers go to include/objtool (similar to include/linux)
> - all arch headers go to arch/$(SRCARCH)/include/arch (to get arch
>   prefix). This is similar to linux arch specific "asm/*" headers but we
>   are not abusing "asm" name and calling it what it is. This also helps
>   to prevent name clashes (arch is not used in system headers or kernel
>   exports).
> 
> To bring objtool to this state the following things are done:
> 1. current top level tools/objtool/ headers are moved into
>    include/objtool/ subdirectory,
> 2. arch specific headers, currently only arch/x86/include/ are moved into
>    arch/x86/include/arch/ and were stripped of "arch_" suffix,
> 3. new -I$(srctree)/tools/objtool/include include path to make
>    includes like <objtool/warn.h> possible,
> 4. rewriting file includes,
> 5. make git not to ignore include/objtool/ subdirectory.
> 
> Signed-off-by: Vasily Gorbik <gor@...ux.ibm.com>

Nice!

For the whole series:

Acked-by: Peter Zijlstra (Intel) <peterz@...radead.org>