Hi , > > > One question I have is in regards to irq_lock and irq_unlock. On the > surface it appears that this is a simple way to allow nested > save/restore of the interrupt state (CPSR reg on ARM) down through a > call stack chain. However these functions increment/decrement an > integer variable that is essentially kernel global (not thread > specific). What I am seeing on boot through strategic DPRINTF placement > is that as soon as the scheduler is unlocked in kernel main the two > kernel threads that have been started run and immediately call > sched_tsleep, which increments the irq_lock variable by two (two > threads). At this point other threads context switch in and the > irq_lock count goes up and down but never recovers back to zero to cause > the interrupt state to be restored.
I have been reading prex code for sometime to understand kernel internals. Your explanation seems correct to me. That being said, then cpu will never receive any interrupts (since nr_irq_locks is >0) till kernel switches to user mode since user mode cpsr should always have interrupts enabled. > > > > Also I see mixed use of irq_lock/irq_unlock and > interrupt_enable/interrupt_disable. An example is in sched_tsleep (uses > irq_lock/irq_unlock) compared to sched_unlock (uses > interrupt_enable/disable). Is this intentional? Could you explain when > each approach is appropriate? I'm having trouble following this detail > in the source code. > > Use irq_lock/irq_unlock when multiple functions in a call chain need to enable/disable interrupts else use interrupt_enable/interrupt_disable function. HTH, Pradeep ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ Prex-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/prex-devel
