[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080730010044.06e7442b@lxorguk.ukuu.org.uk>
Date: Wed, 30 Jul 2008 01:00:44 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: ebiederm@...ssion.com (Eric W. Biederman)
Cc: "Yinghai Lu" <yhlu.kernel@...il.com>,
"Mike Travis" <travis@....com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
"Dhaval Giani" <dhaval@...ux.vnet.ibm.com>,
"Thomas Gleixner" <tglx@...utronix.de>,
"Ingo Molnar" <mingo@...e.hu>, lkml <linux-kernel@...r.kernel.org>,
"Jack Steiner" <steiner@....com>, "Alan Mayer" <ajm@....com>,
"Cliff Wickman" <cpw@....com>
Subject: Re: kernel BUG at arch/x86/kernel/io_apic_64.c:357!
On Tue, 29 Jul 2008 16:12:50 -0700
ebiederm@...ssion.com (Eric W. Biederman) wrote:
> "Yinghai Lu" <yhlu.kernel@...il.com> 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
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists