Re: irq.h changes in 2.3.14

Jes Sorensen (Jes.Sorensen@cern.ch)
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/