All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [GIT PULL] sched.h split-up
Date: Sat, 4 Mar 2017 08:30:17 +0100	[thread overview]
Message-ID: <20170304073017.GA1122@gmail.com> (raw)
In-Reply-To: <CA+55aFzbfBXy6UHpsGmLuL3ySaGZ8MViJtTHk6Qq-xvo_CcSzw@mail.gmail.com>


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> Anyway, I fixed the semantic merge error by just including thar
> <linux/sched/signal.h> file, but this is just not acceptable.
> 
> Having to have files know that if they use the wait-event functins
> (well, _some_ of them), they not only need to include <linux/wait.h>,
> they need to completely illogically also include
> <linux/sched/signal.h> is just not maintainable.

Absolutely and agreed, will fix this ASAP!

wait.h generates too large functions anyway, so uninlining parts of it will be an 
improvement anyway.

> And who knows what similar semantic cases I _won't_ notice, because
> they occur in code I don't build even with my allmodconfig builds?

I did a fair amount of allyes/allno/allmod plus randconfig testing on x86, and 
caught and fixed a number of cases, so that angle should be covered to a fair 
degree.

On non-x86 I did allyes/allno/allmod testing as well, but not randconfig testing - 
plus some of the architectures have a large amount of defconfigs which I couldn't 
all test through.

So I'd expect build breakages to be concentrated into newly upstreamed code (such 
as this one) - which risk I tried to reduce by re-testing them on the almost-last 
day of the merge window.

Thanks,

	Ingo

  reply	other threads:[~2017-03-04  7:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-03  1:36 [GIT PULL] sched.h split-up Ingo Molnar
2017-03-03 20:13 ` Linus Torvalds
2017-03-04  7:30   ` Ingo Molnar [this message]
2017-03-07 23:33   ` Linus Torvalds
2017-03-08  0:04     ` Linus Torvalds
2017-03-08 17:24       ` Ingo Molnar
2017-03-08  8:37     ` [RFC PATCH] sched/wait: Introduce new, more compact wait_event*() primitives Ingo Molnar
2017-03-08  9:17       ` [RFC PATCH] sched/wait: Add <linux/sched/signal.h> dependency for now Ingo Molnar
2017-03-08 10:11         ` [PATCH -v2] " Ingo Molnar
2017-03-08 11:55       ` [RFC PATCH] sched/wait: Introduce new, more compact wait_event*() primitives Ingo Molnar
2017-03-08 12:10       ` [RFC PATCH, -v2] " Ingo Molnar
2017-03-09 16:25         ` Peter Zijlstra
2017-03-08 16:37       ` [RFC PATCH] " Linus Torvalds
2017-03-08 17:16         ` Ingo Molnar

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=20170304073017.GA1122@gmail.com \
    --to=mingo@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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.