remove redundant irq_affinity definition

gcc4 complains about multiple definitions of irq_affinity--I think the one in arch/ia64/kernel/irq.c is the redundant one since the array is also defined in kernel/irq/manage.c.

Building with gcc4 generates a bunch of warnings too, saying that qualifiers on function return types are being ignored (in particular the ones from __ia64_get_io_port_base and the ones having to do with mmu_context_t being volatile). Should we use attribute(const) for get_io_port_base? What about for the mmu_context_t functions?

Jesse

===== arch/ia64/kernel/irq.c 1.55 vs edited =====

@@ -97,7 +97,6 @@
 cpumask_t __cacheline_aligned pending_irq_cpumask[NR_IRQS];
 static unsigned long pending_irq_redir[BITS_TO_LONGS(NR_IRQS)];
 
-static cpumask_t irq_affinity [NR_IRQS] = { [0 ... NR_IRQS-1] = CPU_MASK_ALL };
 static char irq_redir [NR_IRQS]; // = { [0 ... NR_IRQS-1] = 1 };
 
 void set_irq_affinity_info (unsigned int irq, int hwid, int redir)

Jesse> What about for the mmu_context_t functions?

I looked briefly into this one and concluded that we shouldn't put the "volatile" inside the mmu_context_t declaration. Having said that, we'll need to be very careful about this change to make sure we compensate with the necessary barriers were we access context-ids outside of spinlock-protected critical sections.

	--david

On Mon, Mar 14, 2005 at 11:28:01AM -0800, Jesse Barnes wrote:

Hi Jesse

I submitted one for this much earlier, We need to do a little bit more than removing the static to function properly for cpu hot remove and to handle /proc/irq writes correctly for iosapic. See post below.

Tony is probably waiting to push this, since it has a generic piece in this patch, so probably good to go through akpm.

Tony, how do you want to handle this.

http://marc.theaimsgroup.com/?l=linux-ia64&m0687145406182&w=2

Cheers,
Ashok Raj - Open Source Technology Center