Re: [PATCH, RAW] IRQ: Maintain irq number globally rather than passing to IRQ handlers

[Jeff Garzik <jeff@garzik.org>]

Linus Torvalds wrote:
> 
> On Fri, 6 Oct 2006, Jeff Garzik wrote:
>> Here is the raw, un-split-up first pass of the irq argument removal patch
>> (500K):	http://gtf.org/garzik/misc/patch.irq-remove
> 
> So I'm not at all as sure about this as about the "regs" stuff.
> 
> The "regs" value has always been controversial. It's pretty much always 
> existed (due to the keyboard hander and the magic debugging keysequences), 
> and anybody who looks at 0.01 will quickly realize that the keyboard 
> driver was one of the very first drivers (I think it's even written in 
> assembly at that point: originally _all_ of what was to become Linux was 
> pure asm, the whole "oh, cool, I could write this part in C" came later). 
> But it's been pretty much a special case since day #1, purely for that 
> "press a key to see where the h*ck we hung" case.

Chuckle :)

> In contrast, the irq argument itself is really no different from the 
> cookie we pass in on registration - it's just passing it back to the 
> driver that requested the thing. So unlike "regs", there's not really 
> anything strange about it, and there's nothing really "wrong" with having 
> it there.

It doesn't have the colorful history of pt_regs, but the 'irq' argument 
is dead weight.  I'd say the wrongness stems from its utter uselessness.

Out of ~1100 irq handlers, the irq parameter is used in ~50.  The vast 
majority of those 50 uses are debug printks, or abused as a "did I call 
myself?" internal driver flag.  The number of "real" uses is under 15, 
and those are all ancient ISA or platform drivers that pre-date my ~10 
year history with Linux.

So, I don't see any convincing argument to keep it.  And if we are going 
to kill it, given the pt_regs churn, this is probably the best 
opportunity we'll have in years.

Another weak-but-still-present argument in favor of killing it is that 
this change would IMO future-proof irq handlers, against more exotic irq 
handling methods that may come down the pipe.

	Jeff