Re: Linux 2.6.32-rc4

[Ingo Molnar <mingo@elte.hu>]

* Linus Torvalds <torvalds@linux-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@gmail.com>
  To: torvalds@linux-foundation.org
  Subject: [PATCH] headers: remove sched.h from interrupt.h
  Cc: linux-kernel@vger.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