Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CAK7LNAQ0Q6CdXaD-dVGj_e3O3JYs_crpejWKpXHYQJYxyk-1VQ@mail.gmail.com>
 <CAHk-=wgoX0pVqNMMOcrhq=nuOfoZB_3qihyHB3y1S8qo=MDs6w@mail.gmail.com>
 <3b461878-a4a0-2f84-e177-9daf8fe285e7@kernel.org> <878s0c4vng.fsf@oldenburg.str.redhat.com>
 <20210904131911.GP1583@gate.crashing.org> <871r644bd2.fsf@oldenburg.str.redhat.com>
 <CAHk-=wi+XKYN+3u=_fm=ExqpEaHdER0XuKxVauHYVCPKpKR97Q@mail.gmail.com>
 <87a6kq2nze.fsf@oldenburg.str.redhat.com> <YTY7oYPJPYstU1+f@localhost.localdomain>
In-Reply-To: <YTY7oYPJPYstU1+f@localhost.localdomain>
From:   Masahiro Yamada <masahiroy@kernel.org>
Date:   Wed, 8 Sep 2021 12:09:41 +0900
Message-ID: <CAK7LNATRN15cBU6gSZLHBqegj6F-x8+B8GNYp12wRUx_5u-FbQ@mail.gmail.com>
Subject: Re: [GIT PULL v2] Kbuild updates for v5.15-rc1
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
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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