Messages in this thread | | | Subject | Re: irq.h changes in 2.3.14 | From | Jes Sorensen <> | Date | 20 Aug 1999 16:17:13 +0200 |
| |
>>>>> "Linus" == Linus Torvalds <torvalds@transmeta.com> writes:
Linus> On Thu, 19 Aug 1999, Jes Sorensen wrote: >> I see that it expects asm/hw_irq.h to be the architecture dependant >> stuff, but even the things that made it into include/linux/irq.h >> are way to architecture specific.
Linus> There's absolutely nothing architecture-specific in Linus> <linux/irq.h>.
Linus> It may be _different_ than existing architectures, but I'll try Linus> to make sure that future ports use the same correct irq Linus> handling, and I'll see if I can port some of the existing stuff Linus> (notably alpha) to use the new generic handling. It's actually Linus> very flexible - it pretty much has to be in order to handle the Linus> different kinds of interrupt controllers that exist on PC-like Linus> machines.
I thought a bit more about the set_bit() on a spin lock issues and I think it is problematic to rely on it as it is now in irq.h.
First thing is that some architectures count their bits backwards relative to their byte order, ie. the PPC does this for instance, however this can of course be fiddled by using an appropriate lock value. The other case is for architectures that do not have decent atomic instructions like the PARISC which only has an atomic load-and-store-zero (according to what the Linux/PARISC people tell me) for them it might make sense to swap the lock values so 0 means locked and 1 means open - a test_bit(0, &global_irq_lock) will not work in this case.
Jes
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |