Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 13 Nov 2020 09:06:40 +0100
From:   Peter Zijlstra <peterz@infradead.org>
To:     Vasily Gorbik <gor@linux.ibm.com>
Cc:     Josh Poimboeuf <jpoimboe@redhat.com>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
        Miroslav Benes <mbenes@suse.cz>,
        Alexandre Chartre <alexandre.chartre@oracle.com>,
        Julien Thierry <jthierry@redhat.com>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 5/5] objtool: Rework header include paths
Message-ID: <20201113080640.GY2628@hirez.programming.kicks-ass.net>
References: <cover.thread-1e2854.your-ad-here.call-01605220128-ext-6070@work.hours>
 <patch-5.thread-1e2854.git-1e285422e508.your-ad-here.call-01605220128-ext-6070@work.hours>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <patch-5.thread-1e2854.git-1e285422e508.your-ad-here.call-01605220128-ext-6070@work.hours>
Precedence: bulk

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@linux.ibm.com>

Nice!

For the whole series:

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