Re: [GIT PULL v2] Kbuild updates for v5.15-rc1

From: Masahiro Yamada <masahiroy@kernel.org>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Florian Weimer <fweimer@redhat.com>,
	Linus Torvalds <torvalds@linuxfoundation.org>,
	Segher Boessenkool <segher@kernel.crashing.org>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	llvm@lists.linux.dev, linux-toolchains@vger.kernel.org
Subject: Re: [GIT PULL v2] Kbuild updates for v5.15-rc1
Date: Wed, 8 Sep 2021 12:09:41 +0900	[thread overview]
Message-ID: <CAK7LNATRN15cBU6gSZLHBqegj6F-x8+B8GNYp12wRUx_5u-FbQ@mail.gmail.com> (raw)
In-Reply-To: <YTY7oYPJPYstU1+f@localhost.localdomain>

On Tue, Sep 7, 2021 at 1:02 AM Alexey Dobriyan <adobriyan@gmail.com> wrote:
>
> On Mon, Sep 06, 2021 at 08:54:13AM +0200, Florian Weimer wrote:
> > * Linus Torvalds:
> >
> > > On Sat, Sep 4, 2021 at 8:19 AM Florian Weimer <fweimer@redhat.com> wrote:
> > >>
> > >> In any case, it would be nice to know what the real motivation is.
> > >
> > > I don't know about the original motivation, but the reason I like that
> > > patch after-the-fact is that I've actually been in situations where I
> > > test out self-built compilers without installing them.
> >
> > Does this really simplify matters?  Why wouldn't the gcc compiler driver
> > find cc1, but not be able to pass the right path options, so that the
> > include/ subdirectory can be located as well?
> >
> > > Then it's convenient to have a completely standalone kernel tree.
> >
> > The final patch in the series is here:
> >
> >   isystem: delete global -isystem compile option
> >   <https://lore.kernel.org/linux-kernel/YQhY40teUJcTc5H4@localhost.localdomain/>
> >
> > It's still not self-contained.
>
> What do you mean?
>
> Mainline has 1/3 and 2/3 now:
>
>         c0891ac15f0428ffa81b2e818d416bdf3cb74ab6 isystem: ship and use stdarg.h
>         39f75da7bcc829ddc4d40bb60d0e95520de7898b isystem: trim/fixup stdarg.h and other headers
>
> 3/3 is stuck in -next:
>
>         https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/log/?h=for-next
>
> I'm not sure why. If the patch is bad it should be dropped from -next
> as well. If it is good, it should be in mainline, otherwise more
> compile time failures will happen.

See

https://lore.kernel.org/all/20210906084947.4f65761d@canb.auug.org.au/

Your 3/3 correctly detected a new use of <stddef.h>
in the drm tree.

Stephen Rothwell pointed it out a long time ago,
and fixed it in linux-next.

But, the drm maintainers did not fix it in time.
I could not fix it either since the bad commit,
b97060a99b01b4, was not in my tree.

Now it is mainlined, so my plan is to
do  s/<stddef.h>/<linux/stddef.h>/
in my tree, then include your 3/3
in my second pull request in this MW.

--
Best Regards
Masahiro Yamada