[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201113080640.GY2628@hirez.programming.kicks-ass.net>
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>
Powered by blists - more mailing lists