Messages in this thread | | | Date | Wed, 23 Nov 2005 02:45:42 +0100 | From | Pavel Machek <> | Subject | Re: [PATCH 4/5] Centralise NO_IRQ definition |
| |
Hi!
> > 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. > > yeah, i wanted to suggest this originally, but got distracted by the x86 > quirk that 'IRQ#0' is often the i8253 timer interrupt. > > is there any architecture where irq 0 is a legitimate setting that could > occur in drivers, and which would make NO_IRQ define of 0 non-practical? > If not (which i think is the case) then we should indeed standardize on > 0. (in one way or another) It's not like any real driver will ever have > IRQ#0 even on a PC: the timer IRQ is 'known' to be routed to 0, and we
Well, I still may want for example disk driver (with broken interrupt) to hook onto irq#0 (timer). Better than no interrupts at all....
Pavel -- Thanks, Sharp! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |