From: Nicolas Schier <nicolas@fjasle.eu>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
Nathan Chancellor <nathan@kernel.org>
Subject: Re: [PATCH 2/2] kbuild: add 'private' to target-specific variables
Date: Tue, 7 May 2024 13:15:55 +0200 [thread overview]
Message-ID: <ZjoNa434si-Hk0Cs@buildd.core.avm.de> (raw)
In-Reply-To: <20240427153253.2809911-2-masahiroy@kernel.org>
On Sun, Apr 28, 2024 at 12:32:53AM +0900, Masahiro Yamada wrote:
> Currently, Kbuild produces inconsistent results in some cases.
>
> You can do an interesting experiment using the --shuffle option, which
> is supported by GNU Make 4.4 or later.
>
> Set CONFIG_KVM_INTEL=y and CONFIG_KVM_AMD=m (or vice versa), and repeat
> incremental builds w/wo --shuffle=reverse.
>
> $ make
> [ snip ]
> CC arch/x86/kvm/kvm-asm-offsets.s
>
> $ make --shuffle=reverse
> [ snip ]
> CC [M] arch/x86/kvm/kvm-asm-offsets.s
>
> $ make
> [ snip ]
> CC arch/x86/kvm/kvm-asm-offsets.s
>
> arch/x86/kvm/kvm-asm-offsets.s is rebuilt every time w/wo the [M] marker.
>
> arch/x86/kvm/kvm-asm-offsets.s is built as built-in when it is built as
> a prerequisite of arch/x86/kvm/kvm-intel.o, which is built-in.
>
> arch/x86/kvm/kvm-asm-offsets.s is built as modular when it is built as
> a prerequisite of arch/x86/kvm/kvm-amd.o, which is a module.
>
> Another odd example is single target builds.
>
> When CONFIG_LKDTM=m, drivers/misc/lkdtm/rodata.o can be built as
> built-in or modular, depending on how it is built.
>
> $ make drivers/misc/lkdtm/lkdtm.o
> [ snip ]
> CC [M] drivers/misc/lkdtm/rodata.o
>
> $ make drivers/misc/lkdtm/rodata.o
> [ snip ]
> CC drivers/misc/lkdtm/rodata.o
>
> drivers/misc/lkdtm/rodata.o is built as modular when it is built as a
> prerequisite of another, but built as built-in when it is a final
> target.
>
> The same thing happens to drivers/memory/emif-asm-offsets.s when
> CONFIG_TI_EMIF_SRAM=m.
>
> $ make drivers/memory/ti-emif-sram.o
> [ snip ]
> CC [M] drivers/memory/emif-asm-offsets.s
>
> $ make drivers/memory/emif-asm-offsets.s
> [ snip ]
> CC drivers/memory/emif-asm-offsets.s
>
> This is because the part-of-module=y flag defined for the modules is
> inherited by its prerequisites.
>
> Target-specific variables are likely intended only for local use.
> This commit adds 'private' to them.
>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> ---
uh, thanks for fixing this! (And for the bug documentation, as always!)
I have just one question below.
>
> Makefile | 8 ++++----
> scripts/Makefile.build | 6 +++---
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 62557fabfee5..25dcc7ead330 100644
> --- a/Makefile
> +++ b/Makefile
[...]
> @@ -1500,7 +1500,7 @@ MRPROPER_FILES += include/config include/generated \
>
> # clean - Delete most, but leave enough to build external modules
> #
> -clean: rm-files := $(CLEAN_FILES)
> +clean: private rm-files := $(CLEAN_FILES)
Did you leave 'clean: rm-files := $(KBUILD_EXTMOD)/...' for oot kmods
the way it is (w/o 'private') by intention?
Even though I cannot think of a possible problem without the 'private',
I think it makes sense to change the line as well.
W/ or w/o the 'clean'-update for oot kmods:
Reviewed-by: Nicolas Schier <n.schier@avm.de>
Kind regards,
Nicolas
next prev parent reply other threads:[~2024-05-07 11:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-27 15:32 [PATCH 1/2] kbuild: remove redundant $(wildcard ) for rm-files Masahiro Yamada
2024-04-27 15:32 ` [PATCH 2/2] kbuild: add 'private' to target-specific variables Masahiro Yamada
2024-05-07 11:15 ` Nicolas Schier [this message]
2024-05-07 14:25 ` Masahiro Yamada
2024-05-07 9:43 ` [PATCH 1/2] kbuild: remove redundant $(wildcard ) for rm-files Nicolas Schier
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=ZjoNa434si-Hk0Cs@buildd.core.avm.de \
--to=nicolas@fjasle.eu \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=nathan@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.