On Fri, May 2, 2014 at 7:17 PM, Marc Zyngier <marc.zyngier@xxxxxxx> wrote: > On 2014-05-02 13:34, Mj Embd wrote: >> >> Adding Marc to comment >> Marc Please clarify the doubt >> >> >> >> On Fri, May 2, 2014 at 5:15 PM, Mj Embd <mj.embd@xxxxxxxxx> wrote: >>> >>> Hi, >>> >>> As per a lot of linux documentation some components work in process >>> context and some work in interrupt context. >>> >>> If we try to map these contexts to ARM processor modes then is it >>> safely to assume that >>> Process Context : CPSR.mode = SVC >>> Interrupt Context : CPSR.mode = IRQ >>> >>> If not how to define interrupt context properly. Confusing at times. > > > Well, none of this is completely true. > > Process context exists both in USR (process in user mode) and SVC (process > in kernel mode, executing a syscall for example). > > As for interrupts, the processor indeed starts executing the interrupt in > IRQ mode, but this is a useless complication as far as Linux is concerned, I didn't understood the term useless here, I hope it is not about the question itself. > and we quickly switch to SVC (see the definition of the vector_stub macro in > arch/arm/kernel/entry-armv.S). > So what is the mode of the processor when Linux is executing in the Academic / Bookish Term "Interrupt Context" There is a function called in_interrupt which tells if linux is in interrupt context. But How to define/quantify Interrupt Context as a whole Also, Some texts say there are two contexts Hard IRQ Context , Soft IRQ Context. HardIRQ = interrupts Disabled , (possibly CPSR.I=1, mode=IRQ) SoftIRQ = interrupts Enabled , (possibly CPSR.I=0, mode=IRQ) SoftIRQs when executed from Ksoftirqd daemon (possibly CPSR.I=0, mode=SVC) We have a client query on this. > Hope this helps. > > M. > -- > Fast, cheap, reliable. Pick two. -- -mj _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
