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;
Message-ID: <0ff4860b4202a6ef3bb3b29912d083d471e1cc1d.camel@gnu.org>
Subject: Re: I disabled more compiler warnings..
From:   Paul Smith <psmith@gnu.org>
Reply-To: psmith@gnu.org
To:     Linus Torvalds <torvalds@linux-foundation.org>,
        David Laight <David.Laight@aculab.com>
Cc:     Arnd Bergmann <arnd@arndb.de>,
        Masahiro Yamada <yamada.masahiro@socionext.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Date:   Mon, 11 May 2020 13:58:52 -0400
In-Reply-To: <CAHk-=whLY8dXE6qMuPNE+Tjc6uXy+W2jACyWLxtRUH6GU2=PAA@mail.gmail.com>
References: <CAHk-=wjah-fkfzMdmCNN8v7uriJsGeYjHh18wkXDZa2sxuAXzA@mail.gmail.com>
         <8320f29ca61146fc985083621685ac95@AcuMS.aculab.com>
         <CAHk-=whLY8dXE6qMuPNE+Tjc6uXy+W2jACyWLxtRUH6GU2=PAA@mail.gmail.com>
Organization: GNU's Not UNIX!
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, 2020-05-11 at 10:41 -0700, Linus Torvalds wrote:
> On Mon, May 11, 2020 at 12:43 AM David Laight <
> David.Laight@aculab.com> wrote:
> > 
> > I've not looked inside gmake, but I fixed nmake so that it
> > properly used a single job token pipe for the entire (NetBSD)
> > build and then flushed and refilled it with 'abort' tokens
> > when any command failed.
> > That made the build stop almost immediately.
> 
> The GNU jobserver doesn't have anything like that, afaik.
> 
> I think it always writes a '+' character as a token, so I guess it
> could be extended to write something else for the "abort now"
> situation (presumably a '-' character).

That was exactly my plan.

> But at least for external jobserver clients (of which I am not aware
> of any, I think we only depend on the internal GNU make behavior),
> the documentation states that you should just write back the same
> token you read.

I wrote this text precisely because I intended to support using other
tokens to specify other situations, such as failure :).

As a note, the GCC project has a GSoC project approved for this summer,
for GCC and/or binutils to participate in the jobserver protocol when
they do multithreading in the compiler/linker.  I think they are
planning on creating a generic "jobserver library" but I'm not
mentoring (I don't have the bandwidth for GSoC mentoring).  I do hope
to stay abreast of their work and perhaps toss in suggestions however.

> Paul - the issue is that most of us build the kernel with a "make
> -j<bignum>" (in my case "-j32") and if an error happens during the
> make, it can take a _looong_ time for make to react. And if there are
> warnings in the build, they can hide the actual error fairly easily).

Yes, I believe I have an enhancement in Savannah about this.

> I can trivially see how to do it in the jobserver code itself (just
> see if the token we get was '-', and if it was, write it back for the
> next user and return error), but it's the downstream make code I'm
> entirely unfamiliar with.

That's necessary, but my thinking is that more could be done.  What I
was going to do was if we write back an error token then we would also
go into a loop trying to read all the tokens off the jobserver and
write back error tokens, until we read an error token, then we'd exit
(after writing it back obviously).

If you don't do that you'll have to go through an entire set of builds
after the failure before everyone notices the failure.  If every
instance of make does this then you can propogate the error to everyone
more quickly.

My current work on GNU make is fixing the atrocious mess it has with
signal handling: don't even look and if you do, remember I inherited
this code (yeah, yeah, a long time ago but still... :)).  Right now
it's not so hard (especially with large -j) to have make instances
hanging when ^C is used due to race conditions in the signal handling.

As with all single-threaded applications, though, the problem is the
difficulty (in a portable way) of handling both signals and wait*(2)
reliably...

Anyway, this shouldn't be too difficult.