Re: [PATCH 4/5] Centralise NO_IRQ definition

[Linus Torvalds]

On Mon, 21 Nov 2005, Matthew Wilcox wrote:
> > 
> > 	if (!dev->irq)
> > 		return;
> > 
> > (whatever, made up). And that having NO_IRQ be anything but 0 is thus 
> > fundamentally broken.
> 
> The idea was to give them something better to use instead of this.

Why?

The above is obvious even to a non-programmer. There _is_ no better thing 
from a clarity standpoint.

> The only relevant thing I found with google was
> http://www.microsoft.com/whdc/archive/pciirq.mspx

Look at, for example, any cardbus controller. The way to disable 
generation of the legacy interrupt? Write an irq value of 0 to the 
interrupt control register.

Or check out the irq routers in arch/i386/pci/irq.c. Every _single_ one of 
them does the same. Zero means disabled.

The point I'm trying to make is that there already _is_ a special bit 
pattern that means "no irq", and it's what

 - the kernel has used for the last 14 years
 - is the easiest and most logical one to test for
 - real hardware uses

so why not just use it?

Anybody who says that

	if (!dev->irq)
		return;

isn't logical is just on drugs. It's logical _and_ readable. More so than 
any alternative, especially as any alternative will always have the 
problem that some people will write the above _anyway_.

If you make NO_IRQ be something else than 0, for safety you should also 
make the irq thing be a structure so that the test against zero (which is 
special, as _defined_ by the C language) won't work.

At which point you might as well just do something like

	struct interrupt_descriptor {
		unsigned int nr:31;
		unsigned int valid:1;
	};

and then people can just say

	if (!dev->irq.valid)
		return;

instead, which is also readable, and where you simply cannot do the old 
"if (!dev->irq)" at all.

The fact is, 0 _is_ special. Not just for hardware, but because 0 has a 
magical meaning as "false" in the C language.

			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/