Re: [PATCH 4/5] Centralise NO_IRQ definition

[David Woodhouse]

On Tue, 2005-11-22 at 11:21 -0800, Linus Torvalds wrote:
> Of _course_ "irq0" is a valid irq. On PC's, it's usually the timer 
> interrupt.
> 
> It's the "dev->irq" _cookie_ zero that means it is does not have an irq.
> 
> If you have a physical "irq 0" that is bound to a device, it needs a 
> cookie, and that cookie can't be 0, because that means the device has no 
> interrupt.
> 
> How hard is that to understand? Why do people mix these up?

Mostly I'd suggest that people mix them up because you've only just made
up this 'cookie' nonsense, and the number we store in dev->irq has
always been just the irq number -- at least on all but SPARC, which was
always 'special'. That's precisely _why_ we have a mix of 'int' and
'long' and other types in which we store it, as you've said. It's never
been considered a 'cookie'.

But turning it into a cookie makes enough sense, I suppose, as long as
we stop confusing it with irq 'numbers' -- and that includes banning
anyone from printing it with '%d'.

I'm inclined to agree with David's suggestion of making it a pointer.
Then it can point to a structure which is part a proper _tree_ of
interrupts which actually resembles reality. And SPARC can stop being a
special (and probably saner) case. And all the mess which platforms have
with assigning interrupt 'number' ranges for various PICs can go away.
And hotplug interrupt controllers (it happens, on CardBus or with
hotplug PCI) can work sanely. But Matthew still can't have his pony.

Yes, you still need a mapping at _setup_ time from stuff like isapnp and
OpenFirmware interrupt numbers to the appropriate 'cookie', but that's
not so hard.

-- 
dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/