Messages in this thread | | | Date | Sat, 24 May 2003 14:47:06 -0400 (EDT) | From | Zwane Mwaikambo <> | Subject | Re: [PATCH][2.5] provisional 32-way x445 patches |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |