Re: [PATCH][2.5] provisional 32-way x445 patches

[Zwane Mwaikambo]

On Fri, 23 May 2003, James Cleverdon wrote:

> -int irq_vector[NR_IRQS] = { FIRST_DEVICE_VECTOR , 0 };
> +u8 irq_vector[NR_IRQ_VECTORS] = { FIRST_DEVICE_VECTOR , 0 };
>  
>  static int __init assign_irq_vector(int irq)
>  {
>  	static int current_vector = FIRST_DEVICE_VECTOR, offset = 0;
> +	BUG_ON(irq >= sizeof(irq_vector)/sizeof(*irq_vector));

Can't you just skip that one (-ENOSPC)? It would oops on 32way NUMAQ. Why 
don't we just fix this properly now, it looks like we might end up just 
piling workarounds ontop of kludges. The intel guys were kind enough to 
crank out a vector based irq handling patch and it's just what we need to 
purge NR_IRQS misuse.

>   */
>  
> -extern int irq_vector[NR_IRQS];
> -#define IO_APIC_VECTOR(irq)	irq_vector[irq]
> +/* The upper limit of irq_vector's size is 16 + sum(num_RTEs_in_IO_APICs).
> + * On 32-way x445s this is already 266 without any I/O expansion boxes.
> + * This should eventually be dynamically allocated.
> + */
> +#define NR_IRQ_VECTORS	(4 * NR_IRQS)
> +extern u8 irq_vector[NR_IRQ_VECTORS];
> +#define IO_APIC_VECTOR(irq)	(int)(irq_vector[irq])

This just makes the relationship between NR_IRQS and NR_IRQ_VECTORS even 
more confusing. If you have one IDT, NR_IRQ_VECTORS is ~190

	Zwane
-- 
function.linuxpower.ca