Skip to contentSkip to conversation

remove linux/hardirq.h from asm-generic/local.h

RFC In review Russell King 6 participants 8 messages Dec 14, 2008 – Dec 17, 2008

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

RFC 1/1 remove linux/hardirq.h from asm-generic/local.h

While looking at reducing the amount of architecture namespace pollution in the generic kernel, I found that asm/irq.h is included in the vast majority of compilations on ARM (around 650 files.)

Since asm/irq.h includes a sub-architecture include file on ARM, this causes a negative impact on the ccache's ability to re-use the build results from other sub-architectures, so we have a desire to reduce the dependencies on asm/irq.h.

It turns out that a major cause of this is the needless include of linux/hardirq.h into asm-generic/local.h. The patch below removes this include, resulting in some 250 to 300 files (around half) of the kernel then omitting asm/irq.h.

My test builds still succeed, provided two ARM files are fixed (arch/arm/kernel/traps.c and arch/arm/mm/fault.c) - so there may be negative impacts for this on other architectures.

Note that x86 does not include asm/irq.h nor linux/hardirq.h in its asm/local.h, so this patch can be viewed as bringing the generic version into line with the x86 version.

include/asm-generic/local.h +0 -1
index 33d7d04..43c0b81 100644
@@ -2,7 +2,6 @@
 #define _ASM_GENERIC_LOCAL_H
 
 #include <linux/percpu.h>
-#include <linux/hardirq.h>
 #include <asm/atomic.h>
 #include <asm/types.h>
 
Signature · 3 lines
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
#1 lore raw
Quoted 14 lines · On Sun, 14 Dec 2008 13:39:41 +0000 Russell King <[email protected]>…

While looking at reducing the amount of architecture namespace pollution in the generic kernel, I found that asm/irq.h is included in the vast majority of compilations on ARM (around 650 files.)

Since asm/irq.h includes a sub-architecture include file on ARM, this causes a negative impact on the ccache's ability to re-use the build results from other sub-architectures, so we have a desire to reduce the dependencies on asm/irq.h.

It turns out that a major cause of this is the needless include of linux/hardirq.h into asm-generic/local.h. The patch below removes this include, resulting in some 250 to 300 files (around half) of the kernel then omitting asm/irq.h.

Quoted 7 lines

My test builds still succeed, provided two ARM files are fixed (arch/arm/kernel/traps.c and arch/arm/mm/fault.c) - so there may be negative impacts for this on other architectures.

Note that x86 does not include asm/irq.h nor linux/hardirq.h in its asm/local.h, so this patch can be viewed as bringing the generic version into line with the x86 version.

Sure. Includes are easy to add and hard to remove. I'll queue it up and see if there's fallout.

btw,

Quoted 2 lines

From: Russell King <[email protected]>

that will result in the two rmk's getting separate akpm spam, different Author from Signer-offer, etc. Adding an explicit From: line would improve things.

#2 lore raw
Quoted 20 lines · Andrew Morton
Quoted 18 lines · On Sun, 14 Dec 2008 13:39:41 +0000 Russell King <[email protected]>…

While looking at reducing the amount of architecture namespace pollution in the generic kernel, I found that asm/irq.h is included in the vast majority of compilations on ARM (around 650 files.)

Since asm/irq.h includes a sub-architecture include file on ARM, this causes a negative impact on the ccache's ability to re-use the build results from other sub-architectures, so we have a desire to reduce the dependencies on asm/irq.h.

It turns out that a major cause of this is the needless include of linux/hardirq.h into asm-generic/local.h. The patch below removes this include, resulting in some 250 to 300 files (around half) of the kernel then omitting asm/irq.h.

My test builds still succeed, provided two ARM files are fixed (arch/arm/kernel/traps.c and arch/arm/mm/fault.c) - so there may be negative impacts for this on other architectures.

Quoted 6 lines
Quoted 3 lines

Note that x86 does not include asm/irq.h nor linux/hardirq.h in its asm/local.h, so this patch can be viewed as bringing the generic version into line with the x86 version.

Sure. Includes are easy to add and hard to remove. I'll queue it up and see if there's fallout.

Thanks, I've committed to my git tree the addition of linux/hardirq.h to those two files I mentioned above. I guess at some point you'll pick those up to prevent build errors on ARM?

Quoted 6 lines
Quoted 2 lines

From: Russell King <[email protected]>

that will result in the two rmk's getting separate akpm spam, different Author from Signer-offer, etc. Adding an explicit From: line would improve things.

If they're sent as the same email, it doesn't matter.

Signature · 3 lines
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
#3 lore raw

Hi Russell,

Quoted 4 lines · On Sun, 14 Dec 2008 19:51:16 +0000 Russell King <[email protected]>…

Thanks, I've committed to my git tree the addition of linux/hardirq.h to those two files I mentioned above. I guess at some point you'll pick those up to prevent build errors on ARM?

Andrew will (presumably) get these through linux-next (which he bases the mm trees on).

Signature · 3 lines
Cheers,
Stephen Rothwell                    [email protected]
http://www.canb.auug.org.au/~sfr/
#4 lore raw
In reply to Andrew Morton
Quoted 8 lines · Andrew Morton
Quoted 3 lines · On Sun, 14 Dec 2008 13:39:41 +0000 Russell King <[email protected]>…

Note that x86 does not include asm/irq.h nor linux/hardirq.h in its asm/local.h, so this patch can be viewed as bringing the generic version into line with the x86 version.

Sure. Includes are easy to add and hard to remove. I'll queue it up and see if there's fallout.

Here is some (but not everything):

arch/avr32/kernel/traps.c:63: error: implicit declaration of function 'in_interrupt' arch/avr32/kernel/traps.c:113: error: implicit declaration of function 'nmi_enter' arch/avr32/kernel/traps.c:124: error: implicit declaration of function 'nmi_disable' arch/avr32/kernel/traps.c:127: error: implicit declaration of function 'nmi_exit' arch/sh/kernel/traps_32.c:104: error: implicit declaration of function 'in_interrupt' arch/sparc64/kernel/sysfs.c:201: error: 'cpuinfo_sparc' undeclared (first use in this function) arch/sparc64/kernel/mdesc.c:576: error: expected ')' before '*' token

arch/avr32/kernel/traps.c +1 -0
index 0d98737..d547c8d 100644
@@ -7,6 +7,7 @@
  */
 
 #include <linux/bug.h>
+#include <linux/hardirq.h>
 #include <linux/init.h>
 #include <linux/kallsyms.h>
 #include <linux/kdebug.h>
arch/sh/kernel/traps_32.c +1 -0
index 1e5c74e..7a2dc95 100644
@@ -13,6 +13,7 @@
  */
 #include <linux/kernel.h>
 #include <linux/ptrace.h>
+#include <linux/hardirq.h>
 #include <linux/init.h>
 #include <linux/spinlock.h>
 #include <linux/module.h>
arch/sparc64/kernel/mdesc.c +1 -0
index dde52bc..3c539a6 100644
@@ -11,6 +11,7 @@
 #include <linux/mm.h>
 #include <linux/miscdevice.h>
 
+#include <asm/cpudata.h>
 #include <asm/hypervisor.h>
 #include <asm/mdesc.h>
 #include <asm/prom.h>
arch/sparc64/kernel/sysfs.c +1 -0
index 84e5ce1..d28f496 100644
@@ -8,6 +8,7 @@
 #include <linux/percpu.h>
 #include <linux/init.h>
 
+#include <asm/cpudata.h>
 #include <asm/hypervisor.h>
 #include <asm/spitfire.h>
 
#5 lore raw
Quoted 62 lines · On Tue, 16 Dec 2008 21:47:04 +0300 Alexey Dobriyan <[email protected]> wrote:
Quoted 8 lines · Andrew Morton
Quoted 3 lines · On Sun, 14 Dec 2008 13:39:41 +0000 Russell King <[email protected]>…

Note that x86 does not include asm/irq.h nor linux/hardirq.h in its asm/local.h, so this patch can be viewed as bringing the generic version into line with the x86 version.

Sure. Includes are easy to add and hard to remove. I'll queue it up and see if there's fallout.

Here is some (but not everything):

arch/avr32/kernel/traps.c:63: error: implicit declaration of function 'in_interrupt' arch/avr32/kernel/traps.c:113: error: implicit declaration of function 'nmi_enter' arch/avr32/kernel/traps.c:124: error: implicit declaration of function 'nmi_disable' arch/avr32/kernel/traps.c:127: error: implicit declaration of function 'nmi_exit' arch/sh/kernel/traps_32.c:104: error: implicit declaration of function 'in_interrupt' arch/sparc64/kernel/sysfs.c:201: error: 'cpuinfo_sparc' undeclared (first use in this function) arch/sparc64/kernel/mdesc.c:576: error: expected ')' before '*' token

arch/avr32/kernel/traps.c +1 -0
index 0d98737..d547c8d 100644
@@ -7,6 +7,7 @@
  */
 
 #include <linux/bug.h>
+#include <linux/hardirq.h>
 #include <linux/init.h>
 #include <linux/kallsyms.h>
 #include <linux/kdebug.h>
arch/sh/kernel/traps_32.c +1 -0
index 1e5c74e..7a2dc95 100644
@@ -13,6 +13,7 @@
  */
 #include <linux/kernel.h>
 #include <linux/ptrace.h>
+#include <linux/hardirq.h>
 #include <linux/init.h>
 #include <linux/spinlock.h>
 #include <linux/module.h>
arch/sparc64/kernel/mdesc.c +1 -0
index dde52bc..3c539a6 100644
@@ -11,6 +11,7 @@
 #include <linux/mm.h>
 #include <linux/miscdevice.h>
 
+#include <asm/cpudata.h>
 #include <asm/hypervisor.h>
 #include <asm/mdesc.h>
 #include <asm/prom.h>
arch/sparc64/kernel/sysfs.c +0 -0
index 84e5ce1..d28f496 100644

arch/sparc64/kernel/sysfs.c line 13

Quoted 6 lines
arch/sparc64/kernel/sysfs.c +1 -0
@@ -8,6 +8,7 @@
 #include <linux/percpu.h>
 #include <linux/init.h>
 
+#include <asm/cpudata.h>
 #include <asm/hypervisor.h>
 #include <asm/spitfire.h>

hm, the two sparc64 files have just magically disappeared from linux-next.

Oh well, I'll do sparc and sparc64 crossbuilds soon.

#6 lore raw
Quoted 17 lines
Quoted 17 lines

+++ b/arch/sparc64/kernel/mdesc.c

arch/sparc64/kernel/mdesc.c +1 -0
@@ -11,6 +11,7 @@
 #include <linux/mm.h>
 #include <linux/miscdevice.h>
 
+#include <asm/cpudata.h>
 #include <asm/hypervisor.h>
 #include <asm/mdesc.h>
 #include <asm/prom.h>
arch/sparc64/kernel/sysfs.c +0 -0
index 84e5ce1..d28f496 100644
@@ -8,6 +8,7 @@
 #include <linux/percpu.h>
 #include <linux/init.h>
 
Quoted 5 lines

arch/sparc64/kernel/sysfs.c line 13

Quoted 3 lines
arch/sparc64/kernel/sysfs.c +1 -0
+#include <asm/cpudata.h>
 #include <asm/hypervisor.h>
 #include <asm/spitfire.h>

hm, the two sparc64 files have just magically disappeared from linux-next.

s/magically/by hard work/ ;-)

We have unified sparc and sparc64 so all files lives in arch/sparc/* these days.
Feed the sparc64 bits to davem and he will take care. Or I can do it if you like.

Sam

#7 lore raw
In reply to Russell King
Quoted 9 lines · Russell King

While looking at reducing the amount of architecture namespace pollution in the generic kernel, I found that asm/irq.h is included in the vast majority of compilations on ARM (around 650 files.)

Since asm/irq.h includes a sub-architecture include file on ARM, this causes a negative impact on the ccache's ability to re-use the build results from other sub-architectures, so we have a desire to reduce the dependencies on asm/irq.h.

Quoted 8 lines

It turns out that a major cause of this is the needless include of linux/hardirq.h into asm-generic/local.h. The patch below removes this include, resulting in some 250 to 300 files (around half) of the kernel then omitting asm/irq.h.

My test builds still succeed, provided two ARM files are fixed (arch/arm/kernel/traps.c and arch/arm/mm/fault.c) - so there may be negative impacts for this on other architectures.

I gave it a try on m68k/atari_defconfig, but no ill effects.

Quoted 11 lines

Note that x86 does not include asm/irq.h nor linux/hardirq.h in its asm/local.h, so this patch can be viewed as bringing the generic version into line with the x86 version.

include/asm-generic/local.h +0 -0
index 33d7d04..43c0b81 100644

include/asm-generic/local.h line 6

Quoted 6 lines
include/asm-generic/local.h +0 -1
@@ -2,7 +2,6 @@
 #define _ASM_GENERIC_LOCAL_H
 
 #include <linux/percpu.h>
-#include <linux/hardirq.h>
 #include <asm/atomic.h>
 #include <asm/types.h>

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds