Re: [PATCH 4/5] Centralise NO_IRQ definition

[Linus Torvalds]

On Tue, 22 Nov 2005, Alan Cox wrote:
>
> On Maw, 2005-11-22 at 11:13 +0000, David Woodhouse wrote:
> > Yes, there are drivers which are currently broken and assume irq 0 is
> > 'no irq'. They are broken. Let's just fix them and not continue the
> > brain-damage.
> 
> 0 in the Linux kernel has always meant 'no IRQ' and it makes it natural
> to express in C (and on some cpus more efficient too).

Ahh, a voice of sanity!

> What if my hardware has an IRQ -1 ;)

And "-1" isn't actually a valid value in the first place.

The struct pci_device definition is:

	unsigned int irq;

and anybody who uses -1 is just a total idiot and nincompoop. It's going 
to be a major pain in the ass (others use "int irq", others use "unsigned 
long irq").

Using (~0u) would be more correct, but still insane.

The fact is, 0 _is_ "no interrupt". Always has been. And anybody who says 
that "-1" is "correct" is just totally wrong. Making it -1 would be 
guaranteed to generate tons of breakage, and most people won't ever even 
notice, because in most cases the irq _is_ actually there, and you never 
hit the path. Which just makes the breakage EVEN WORSE.

So David Woodhouse, you're just wrong. But hey, you seem to (sadly) not be 
alone.

In short: NO_IRQ _is_ 0. Always has been. It's the only sane value. And 
btw, there is no need for that #define at all, exactly because the way you 
test for "is this no irq" is by doing "!dev->irq".

Anybody who does anything else is a bug waiting to happen.

		Linus

-
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/