[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1218903209.3940.14.camel@localhost.localdomain>
Date: Sat, 16 Aug 2008 11:13:29 -0500
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Yinghai Lu <yhlu.kernel@...il.com>,
"H. Peter Anvin" <hpa@...or.com>,
Jesse Barnes <jbarnes@...tuousgeek.org>,
Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
Andrew Vasquez <andrew.vasquez@...gic.com>
Subject: Re: [PATCH] pci: change msi-x vector to 32bit
On Sat, 2008-08-16 at 16:39 +0100, Alan Cox wrote:
> > Where exactly is this code in the kernel? Most arches assume the irq is
> > an index to a compact table bounded by NR_IRQS, so something like this
> > would violate that assumption.
>
> Yes, which is no bad thing for some platforms. There are some driver
> assumptions like that but those have also been stomped.
I'm not saying we couldn't do this, or even that we shouldn't; I'm just
asking why would we want to?
All arches currently seem to have show_interrupts() which loop over
0..NR_IRQS where the interrupt is printed as %d. In this encoded scheme
they would show up with rather nastily large numbers that have no
visible meaning unless we switch to hex for displaying them.
What I'm really saying is that irq as the interrupt number is really the
*user's* handle for the interrupt not the machine's, so it needs to be
something the user is comfortable with. We could overcome this
objection by encoding the number to something meaningful for the
user ... I'm just asking if there's any benefit to doing this?
James
--
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