[lkml]   [2005]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 4/5] Centralise NO_IRQ definition

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

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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-11-18 23:46    [W:0.095 / U:1.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site