Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753391AbYHPQNq (ORCPT ); Sat, 16 Aug 2008 12:13:46 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752243AbYHPQNh (ORCPT ); Sat, 16 Aug 2008 12:13:37 -0400 Received: from accolon.hansenpartnership.com ([76.243.235.52]:41109 "EHLO accolon.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752193AbYHPQNh (ORCPT ); Sat, 16 Aug 2008 12:13:37 -0400 Subject: Re: [PATCH] pci: change msi-x vector to 32bit From: James Bottomley To: Alan Cox Cc: Yinghai Lu , "H. Peter Anvin" , Jesse Barnes , Ingo Molnar , Thomas Gleixner , "Eric W. Biederman" , Andrew Morton , linux-kernel@vger.kernel.org, Andrew Vasquez In-Reply-To: <20080816163945.74d487e9@lxorguk.ukuu.org.uk> References: <200808160326.m7G3QR1G012726@terminus.zytor.com> <86802c440808152342m772d5eabs59a9c93ffe4cf557@mail.gmail.com> <1218898238.3940.6.camel@localhost.localdomain> <20080816163945.74d487e9@lxorguk.ukuu.org.uk> Content-Type: text/plain Date: Sat, 16 Aug 2008 11:13:29 -0500 Message-Id: <1218903209.3940.14.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1332 Lines: 30 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/