linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Masahiro Yamada <masahiroy@kernel.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Arvind Sankar <nivedita@alum.mit.edu>,
	Andrew Morton <akpm@linux-foundation.org>,
	Brendan Higgins <brendanhiggins@google.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Changbin Du <changbin.du@intel.com>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] kconfig: unify cc-option and as-option
Date: Wed, 5 May 2021 05:46:54 +0900	[thread overview]
Message-ID: <CAK7LNASRSOBy_bqUvMqk-m8WVaHPfwM8xEbiTGtcB2B2-3GBhQ@mail.gmail.com> (raw)
In-Reply-To: <70868660127bd13dcc47e94108483ff15827378c.camel@sipsolutions.net>

On Wed, May 5, 2021 at 5:17 AM Johannes Berg <johannes@sipsolutions.net> wrote:
>
> Hi,
>
> So... I realized it's been a while:
>
> On Sun, 2020-06-14 at 23:43 +0900, Masahiro Yamada wrote:
> > cc-option and as-option are almost the same; both pass the flag to
> > $(CC). The main difference is the cc-option stops before the assemble
> > stage (-S option) whereas as-option stops after it (-c option).
> >
>
> But, I had noticed for a while now that M= build for an out-of-tree
> driver were causing some trouble. Not really completely "out-of-tree"
> but rather backported (https://backports.wiki.kernel.org/).
>
> And then I finally narrowed it down to this commit, specifically this:
>
> >  # Return y if the compiler supports <flag>, n otherwise
> > -cc-option = $(success,$(CC) -Werror $(CLANG_FLAGS) $(1) -S -x c /dev/null -o /dev/null)
> > +cc-option = $(success,mkdir .tmp_$$$$; trap "rm -rf .tmp_$$$$" EXIT; $(CC) -Werror $(CLANG_FLAGS) $(1) -c -x c /dev/null -o .tmp_$$$$/tmp.o)
>
> What happens is that we're doing
>
>  make -C /path/to/kernel M=/path/to/driver
>
> But /path/to/kernel may be the installed distro kernel headers, and thus
> not be writable to the user doing the driver compile. Obviously, the
> user may need to 'sudo' anyway to install the result, but if just test-
> compiling, or even as better practice to not run everything as root,
> this ".tmp_$$" dir cannot be created.
>
> IOW, this broke compiler option detection when KBUILD_EXTMOD=/M= is
> used. It seems this is still supported (documented in kbuild docs), so
> I'm kind of hoping it could be fixed? But OTOH, I really don't know how,
> perhaps just using "mktemp -d" here instead of the hardcoded temp dir?
>
> Thanks,
> johannes
>


 - This commit touches scripts/Kconfig.include.
 - External module builds (M= builds) never invoke Kconfig

Putting these two together, your claim is really odd.
If external module builds invoke Kconfig,
your kernel is already broken.

If you claim this is an issue,
please describe how to reproduce it in *upstream* kernel.
I do not know (or care about) your backport kernel.


--
Best Regards
Masahiro Yamada

  reply	other threads:[~2021-05-04 20:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-14 14:43 [PATCH 1/2] kbuild: improve cc-option to clean up all temporary files Masahiro Yamada
2020-06-14 14:43 ` [PATCH 2/2] kconfig: unify cc-option and as-option Masahiro Yamada
2020-06-15 10:00   ` Will Deacon
2021-05-04 20:17   ` Johannes Berg
2021-05-04 20:46     ` Masahiro Yamada [this message]
2021-05-04 20:52       ` Johannes Berg
2021-05-04 21:05         ` Masahiro Yamada
2021-05-04 21:08           ` Johannes Berg

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=CAK7LNASRSOBy_bqUvMqk-m8WVaHPfwM8xEbiTGtcB2B2-3GBhQ@mail.gmail.com \
    --to=masahiroy@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=brendanhiggins@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=changbin.du@intel.com \
    --cc=johannes@sipsolutions.net \
    --cc=krzk@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab+huawei@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=nivedita@alum.mit.edu \
    --cc=rdunlap@infradead.org \
    --cc=will@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;
as well as URLs for NNTP newsgroup(s).