[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091012082950.GA2270@elte.hu>
Date: Mon, 12 Oct 2009 10:29:50 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
Alexey Dobriyan <adobriyan@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.32-rc4
* Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> Alexey Dobriyan (2):
> headers: remove sched.h from interrupt.h
This commit broke the -rc4 build in numerous ways on x86:
drivers/pci/hotplug/cpqphp.h: In function ‘wait_for_ctrl_irq’:
drivers/pci/hotplug/cpqphp.h:730: error: implicit declaration of function ‘signal_pending’
drivers/char/rtc.c: In function 'rtc_interrupt':
drivers/char/rtc.c:271: error: 'TASK_INTERRUPTIBLE' undeclared (first use in this function)
drivers/char/rtc.c:271: error: (Each undeclared identifier is reported only once
(I'll send fixes for the build failures as followups to this mail.)
Beyond being buggy there's two workflow problems with the commit.
Firstly, the commit log concentrates on the m68k situation while in
reality more testing on x86 would have been much more important to the
end result. If we break m68k with a header cleanup it's far less of a
practical problem than if we break thousands of x86 boxes. I find this
kind of artificially inflated focus on cross-testing (without properly
weighting platforms) harmful.
Secondly, i'm wondering why the original mail to lkml:
Date: Wed, 7 Oct 2009 17:09:06 +0400
From: Alexey Dobriyan <adobriyan@...il.com>
To: torvalds@...ux-foundation.org
Subject: [PATCH] headers: remove sched.h from interrupt.h
Cc: linux-kernel@...r.kernel.org
Wasnt Cc:-ed to the affected maintainers? As a result the patch wasnt
tested by any maintainer tree before it was sent to Linus. The change is
good but obviously needs to be done more carefully, there are a _lot_ of
hidden header dependencies in the kernel, especially related to sched.h.
We are doing regular header cleanup patches in -tip and have the
infrastructure to test them properly as well, so this change could have
been done via either the scheduler tree and the interrupt tree. We also
cross-test to all other architectures.
Alexey, could you please Cc: affected maintainers in the future, so that
we can avoid such problems?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists