From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751910AbdCDHbA (ORCPT <rfc822;w@1wt.eu>);
        Sat, 4 Mar 2017 02:31:00 -0500
Received: from mail-wm0-f65.google.com ([74.125.82.65]:34278 "EHLO
        mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751288AbdCDHa6 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Sat, 4 Mar 2017 02:30:58 -0500
Date: Sat, 4 Mar 2017 08:30:17 +0100
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
Message-ID: <20170304073017.GA1122@gmail.com>
References: <20170303013646.GA32094@gmail.com>
 <CA+55aFzbfBXy6UHpsGmLuL3ySaGZ8MViJtTHk6Qq-xvo_CcSzw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+55aFzbfBXy6UHpsGmLuL3ySaGZ8MViJtTHk6Qq-xvo_CcSzw@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* 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