LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Nadav Amit <namit@vmware.com>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
X86 ML <x86@kernel.org>, Michal Marek <michal.lkml@markovi.net>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>
Subject: Re: [PATCH v4 1/9] Makefile: Prepare for using macros for inline asm
Date: Wed, 13 Jun 2018 22:19:24 +0000 [thread overview]
Message-ID: <D9AF0864-EE2A-4C2E-A5A4-C002DEB95B2B@vmware.com> (raw)
In-Reply-To: <CAK7LNATmjTi4Odp5AfbVHCemn7S_tB9nKvgNOf5sp8BiVJma7Q@mail.gmail.com>
Thanks for your comment! I am certainly Makefile-challenged, so your help is
highly appreciated.
Please see my responses/questions inline.
at 10:43 AM, Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> 2018-06-12 20:50 GMT+09:00 Nadav Amit <namit@vmware.com>:
>> Using macros for inline assembly improves both readability and
>> compilation decisions that are distorted by big assembly blocks that use
>> alternative sections. Compile macros.S and use it to assemble all C
>> files. Currently, only x86 will use it.
>>
>> Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
>> Cc: Michal Marek <michal.lkml@markovi.net>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>> Cc: x86@kernel.org
>> Cc: linux-kbuild@vger.kernel.org
>>
>> Signed-off-by: Nadav Amit <namit@vmware.com>
>
>
> I have not fully understood this series yet.
>
> I do not have enough skill in x86 architecture,
> but just some comments from the build system point of view.
>
>
>
> I guess this will probably break the parallel building.
>
> Kbuild can build 'prepare' and 'scripts' simultaneously.
>
>
> I locally modified the following line:
>
>
> diff --git a/Makefile b/Makefile
> index 2dea909440..6ad484a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1030,7 +1030,7 @@ $(sort $(vmlinux-deps)): $(vmlinux-dirs) ;
> # Error messages still appears in the original language
>
> PHONY += $(vmlinux-dirs)
> -$(vmlinux-dirs): prepare scripts
> +$(vmlinux-dirs): scripts prepare
> $(Q)$(MAKE) $(build)=$@ need-builtin=1
>
> define filechk_kernel.release
>
>
>
> masahiro@grover:~/workspace/linux-kbuild$ make defconfig
> HOSTCC scripts/basic/fixdep
> HOSTCC scripts/kconfig/conf.o
> YACC scripts/kconfig/zconf.tab.c
> LEX scripts/kconfig/zconf.lex.c
> HOSTCC scripts/kconfig/zconf.tab.o
> HOSTLD scripts/kconfig/conf
> *** Default configuration is based on 'x86_64_defconfig'
> #
> # configuration written to .config
> #
> masahiro@grover:~/workspace/linux-kbuild$ make all
> scripts/kconfig/conf --syncconfig Kconfig
> WRAP arch/x86/include/generated/uapi/asm/bpf_perf_event.h
> WRAP arch/x86/include/generated/uapi/asm/poll.h
> WRAP arch/x86/include/generated/asm/dma-contiguous.h
> WRAP arch/x86/include/generated/asm/early_ioremap.h
> WRAP arch/x86/include/generated/asm/mcs_spinlock.h
> WRAP arch/x86/include/generated/asm/mm-arch-hooks.h
> CC scripts/mod/empty.o
> Assembler messages:
> Error: can't open arch/x86/kernel/macros.s for reading: No such file
> or directory
> make[2]: *** [scripts/Makefile.build:318: scripts/mod/empty.o] Error 1
> make[1]: *** [scripts/Makefile.build:558: scripts/mod] Error 2
> make: *** [Makefile:1050: scripts] Error 2
You are right. I tried to filter out the use of the switch (exported as
ASM_MACRO_FLAGS) for empty.o. Any suggestions on how to do it properly?
> Are you planning to support for all architectures, or x86-specific?
Not right now. But I think that other architectures will also prefer to
separate the inline assembly chunks in a similar manner, for better
compilation, easier readability, and better code maintainability.
Thanks again,
Nadav
next prev parent reply other threads:[~2018-06-13 22:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-12 11:50 [PATCH v4 0/9] x86: macrofying inline asm for better compilation Nadav Amit
2018-06-12 11:50 ` [PATCH v4 1/9] Makefile: Prepare for using macros for inline asm Nadav Amit
2018-06-13 17:43 ` Masahiro Yamada
2018-06-13 20:36 ` Sam Ravnborg
2018-06-17 0:47 ` Masahiro Yamada
2018-06-13 22:19 ` Nadav Amit [this message]
2018-06-17 0:40 ` Masahiro Yamada
2018-06-19 7:12 ` Nadav Amit
2018-06-12 11:50 ` [PATCH v4 2/9] x86: objtool: use asm macro for better compiler decisions Nadav Amit
2018-06-12 11:50 ` [PATCH v4 3/9] x86: refcount: prevent gcc distortions Nadav Amit
2018-06-12 11:50 ` [PATCH v4 4/9] x86: alternatives: macrofy locks for better inlining Nadav Amit
2018-06-12 11:50 ` [PATCH v4 5/9] x86: bug: prevent gcc distortions Nadav Amit
2018-06-12 11:50 ` [PATCH v4 6/9] x86: prevent inline distortion by paravirt ops Nadav Amit
2018-06-19 15:09 ` Juergen Gross
2018-06-12 11:50 ` [PATCH v4 7/9] x86: extable: use macros instead of inline assembly Nadav Amit
2018-06-12 11:50 ` [PATCH v4 8/9] x86: cpufeature: " Nadav Amit
2018-06-12 11:50 ` [PATCH v4 9/9] x86: jump-labels: " Nadav Amit
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=D9AF0864-EE2A-4C2E-A5A4-C002DEB95B2B@vmware.com \
--to=namit@vmware.com \
--cc=hpa@zytor.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.lkml@markovi.net \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yamada.masahiro@socionext.com \
--subject='Re: [PATCH v4 1/9] Makefile: Prepare for using macros for inline asm' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).