David Brownell wrote: > The other is that Linux needs real support for threaded > interrupts. Almost every I2C (or SPI) device that raises > an IRQ needs its IRQ handler to run in a thread, and most > of them have the same type of workqueue-based hack to > get such a thread. (Some others have bugs instead...) Since when is having an IRQ handler scheduling a workqueue job a hack? In kernels whose IRQ handlers don't sleep, we don't pretend that they could; instead we defer sleeping work to a context which can sleep. Or from another angle: If a driver requires a kernel with sleeping IRQ handlers, why submit it for inclusion into a kernel which does not provide nonatomic context to IRQ handlers? -- Stefan Richter -=====-==--= --=- ===-- http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
