On Wed, Sep 12, 2012 at 10:44:20AM +0100, Alan Cox wrote:
Of course, if Alan is OK with this, I'm more than OK too. :-)
It may well be better.
(But the polling routines would need to clear all interrupts, not just rx/tx. For example, if the controller indicated some error, and nobody clears it, then we'll start reentering infinitely.)
For a lot of devices and platforms you'd probably mask them instead ?
If there is no way to clear them, yes, we obviously would want to mask them before using the port for NMI debugger. Then we'd need three callbacks:
- mask_all_irqs_but_rx() -- used before we want to start using the port for the NMI debugger; - clear_rx_irq() -- (optional) clears rx IRQ for controllers that need it; - restore_irqs() -- unmasks interrupts that were previously masked.
If we ever encounter a case when just clearing interrupts doesn't work, we can surely implement the above scheme... It's just so far I don't see any need to over-design this, but again, it's your call, I told my opinion on this, but I'll do whatever you guys like more. :-)
If you use a clear_irqs callback, you can drop characters if one arrives between the last character buffer read and calling clear_irqs.
Only if we call clear_irqs() after reading the characters, but we do it before. So if new characters are available, we will reenter NMI, which is OK.
Recursively or not... again you get platform specific magic in places we don't want.
I really really don't see how this is platform-specific. All we ask the serial driver is to quiesce its interrupt. Whether we can handle NMIs/IRQs recursively or not is not serial driver's worry, since its IRQ handler is not going to fire anyway. The polling routines already gave us the power to steal/inject the data, so now we're stealing the interrupt too.
How we use the callback is indeed platform-specific, but so is the whole KGDB, and that knowledge is hidden there.
For serial driver it's all pretty much clear: lower the interrupt, but don't turn off rx detection.
Thanks!
Anton.