On 2016-10-05 23:07:55 [-0700], Joel Fernandes wrote: > Just to clarify and use the right terminology, I'd like to understand > whether the "hard" in hard irq implies interrupt context? it usually does. > To further confuse the matter, with CONFIG_PREEMPT_RT_FULL, all IRQs > previously executing in interrupt context are now threaded. Then in not all but most. And also in !RT with the threadirqs command line argument. > this scenario, is it Ok to still call these irq handlers as hard irq > handlers or should they now be strictly called threaded interrupt > handlers now that the same handlers are forced to execute in a thread? If they are threaded, they are threaded. A threaded handler can be interrupted by an interrupt because it is invoked with interrupts enabled. A non-threaded handler can not be interrupted. > If the "hard" in hard irq means hardware interrupt, then it would make > sense to still call them hardirq handlers even though they're now > executing in process context? you call them interrupt handler. You can request *explicit* a threaded handler if your code needs to sleep (in order to reach hardware behind a slow bus like i2c). > So basically my questions are: > 1. Does hard in hard irq mean hardware interrupt or does it imply > interrupt context? I would drop that hard part. It is an interrupt handler. It then can be either threaded or not and it can be always threaded or sometimes. hard is used to distinguish this kind of interrupts from the soft-irqs. > 2. Can the terms "hard irq handler" still be used with CONFIG_PREEMPT_RT_FULL? not all interrupts are threaded. perf and timer are just two examples of interrupts which are never threaded. So some interrupts are handled with interrupts disabled and some with interrupts enabled. > Thanks a lot, > > Joel Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
