> it's a compatibility hack only. Threaded handlers are a different type > of flow, but often the fasteoi handler is not changed to the threaded > handler so i changed it to be a threaded handler too. > > threaded handlers need a mask() + an ack(), because that's the correct > model to map them to kernel threads - threaded handlers can be delayed > for a long time if something higher-prio is preempting them.
I've re-read the old thread and I disagree with you there. I think the right approach was proposed initially by Daniel Walker. If my understanding of "threaded handlers" is correct, that is delaying the delivery of the interrupt to a thread while restoring the ability to process further interrupts of the same or lower priority immediately. There is no such thing as an explicit "ack" on fasteoi controllers. The ack is implicit with the reading of the vector (either via a special cycle on the bus or via reading the intack register for example on mpic). So by doing a mask followed by an eoi, you essentially mask the interrupt preventing further delivery of that interrupt and lower the CPU priority in the PIC thus allowing processing of further interrupts. Are there other fasteoi controllers than the ones I have on powerpc anyway ? There is one thing I disagree with in the initial patch from Daniel however, it's the fact that he can't deal with fasteoi handlers that have no mask/unmask. I have such a controller, on Cell, though currently I do have an empty mask and unmask for it, I've been thinking about removing them (and fixing callers to test for NULL). This is the Cell's top level controller and it is edge only (at this level, on Cell, all interrupts are messages). Thus it can perfectly well cope with soft-masking (delayed disable if you prefer) and that is compatible with using a fasteoi handler. There should be no reason why that wouldn't work for -rt as well. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/