On Mon, Oct 04, 2010 at 09:54:19AM +1100, Benjamin Herrenschmidt wrote: > On Sun, 2010-10-03 at 09:53 -0700, Eric W. Biederman wrote: > > Thomas Gleixner <tglx@xxxxxxxxxxxxx> writes: > > > > >> That would make things much cleaner and in fact move one large step > > >> toward being able to make powerpc virq scheme generic, which seems to be > > >> a good idea from what I've heard :-) > > > > > > Yep. > > > > I'm not certain about making the ppc virq scheme generic. Maybe it is > > just my distorted impression but I have the understanding that ppc irq > > numbers mean nothing and are totally unstable whereas on x86 irq numbers > > in general are stable (across kernel upgrades and changes in device > > probe order) and the irq number has a useful hardware meaning. Which > > means you don't have to go through several layers of translation tables > > to figure out which hardware pin you are talking about. [...] > > The main deal I'd say is that in embedded land (and to some extent I > suspect that's going to happen more with x86), you quickly end up with > multiple interrupt domains, via cascaded controllers of all kinds etc... [...] > - Appart from the risk of breaking crap that parses /proc/interrupts, > adding the HW irq information there would be trivial and solve your > problem. > > So overall, I don't see a problem at all. And it makes handling of > arbitrary combinations of interrupt domains (cascaded PICs) very very > easy indeed. Right, the stability of irq numbers is more of a user-interface problem than a technical deficiency with virq, and a solvable one at that. If fact, I'd go as far as saying that having irq numbers mean nothing is a *virtue* of the approach because it forces developers to look at the real irq controller attachment rather than some hwirq==linux-irq assumption. As mentioned in my other reply, I'd be perfectly happy to stop exposing linux irq numbers to userspace entirely, but I realize that would break /proc/interrupts users. However, I do completely agree that exposing the hwirq information is very much required. g. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html