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
Date: Fri, 13 Nov 2020 09:06:40 +0100 [thread overview]
Message-ID: <20201113080640.GY2628@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <patch-5.thread-1e2854.git-1e285422e508.your-ad-here.call-01605220128-ext-6070@work.hours>
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>
next prev parent reply other threads:[~2020-11-13 8:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-12 23:03 [PATCH v5 0/5] objtool and cross compilation Vasily Gorbik
2020-11-12 23:03 ` [PATCH v5 1/5] x86/tools: Use tools headers for instruction decoder selftests Vasily Gorbik
2020-11-12 23:03 ` [PATCH v5 2/5] x86/insn: Support big endian cross-compiles Vasily Gorbik
2020-11-12 23:03 ` [PATCH v5 3/5] objtool: Fix reloc generation on big endian cross compiles Vasily Gorbik
2020-11-12 23:03 ` [PATCH v5 4/5] objtool: Fix x86 orc " Vasily Gorbik
2020-11-12 23:03 ` [PATCH v5 5/5] objtool: Rework header include paths Vasily Gorbik
2020-11-13 8:06 ` Peter Zijlstra [this message]
2020-11-13 16:09 ` [PATCH] x86/insn: Fix vector instructions decoding on big endian Vasily Gorbik
2020-11-13 17:30 ` Josh Poimboeuf
2020-11-24 13:33 ` Vasily Gorbik
2020-11-25 16:27 ` Masami Hiramatsu
2020-11-14 12:53 ` [PATCH] scripts/sorttable: Fix ORC unwind table sorting " Vasily Gorbik
2020-11-24 13:34 ` Vasily Gorbik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201113080640.GY2628@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=alexandre.chartre@oracle.com \
--cc=bp@alien8.de \
--cc=gor@linux.ibm.com \
--cc=hpa@zytor.com \
--cc=jpoimboe@redhat.com \
--cc=jthierry@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox