[lkml]   [2008]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: kernel BUG at arch/x86/kernel/io_apic_64.c:357!
Alan Cox <> writes:

> On Tue, 29 Jul 2008 16:12:50 -0700
> (Eric W. Biederman) wrote:
>> "Yinghai Lu" <> writes:
>> >> But this would be a show stopper for SGI being able to ship systems if the
>> >> distros do not want to waste this much memory and won't set NR_CPUS=4096.
>> >
>> > wonder if nr_irqs need to be probed dynamically too.
>> NR_IRQS simply needs to die.
> Agreed - it would also be nice to bite the bullet at the same time and
> stop using dev->irq as an integer in an increasingly fake and imaginary
> numberspace and instead make it an object with a description and other
> properties. That would make "no IRQ" NULL, let us display meaningful IRQ
> strings and the like as well as ensuring nobody tries to abuse NR_IRQ and
> hardcoded similar knowledge for arrays

Unfortunately that is extremely expensive and hard. Plus with NR_IRQs
going away the irq number space becomes sparse enough that the irq
numbers can become stable between boots, and as meaningful as they
have ever been. At least for userspace an irq number is part of the
ABI so we will need one for the forseeable future.

We really need to change architecture specific code/generic irq code
first, preserving the number based interface to the drivers. Then if
it looks useful change the drivers.

I would like nothing better then to change fields from "int irq" to
"struct irq_desc *irq" but unless we want to do a 2.7 we need a migration
path. So we can change drivers slowly. Which means providing both
interfaces in parallel for a while.

So it makes most sense to me to change everything beneath interfaces still
taking irq numbers (because that is where we get the performance and the
scalability improvements). Then push forward with driver level changes.


 \ /
  Last update: 2008-07-30 03:35    [W:0.066 / U:1.724 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site