Hi Thomas, Thomas De Schampheleire wrote:
The first thread proposes looking at resume() in swtch.s. Is it correct that *all* context switches pass through these functions, either process->process, process->idle, and idle->process (albeit through _resume_from_idle()) ?
That's right.
What about interrupts?
We don't generally context switch to handle interrupts (and therefore won't go through resume()). The arriving interrupt will "pin" the currently executing thread, and then "unpin" the thread when finished. The exception to this would be if the interrupt is at or below the LOCK_LEVEL pil, in which case it is permitted to use adaptive locks. An interrupt that blocks trying to acquire an adaptive lock will become a "real" (high priority) thread that is scheduled along with other threads on the system. At that point, I believe the blocking interrupt thread goes through the resume_from_intr() path in swtch(), and then when it's runnable again we would resume to it via resume().
Looking through the code of resume, I have noticed the following interesting registers: %g7: current thread pointer %i0: new thread pointer (correct?) %i2: old proc pointer %i3: new proc pointer A strategy I had in mind then, was to have two places where the simulator would read these registers and extract the following fields: (referring to the line numbers in http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/sun4/ml/swtch.s) 1. somewhere before line 175, read the contents of %g7 (thread_reg) to extract the current lwp id (field t_tid in thread.h) 2. somewhere after line 193, read the contents of %i0 to extract the lwp of the resuming thread, and read %i2 and %i3 to get the pid and process name from the current and resuming process. Do you think this strategy is correct? Do you have any other suggestions?
Sounds ok to me. :) Thanks, -Eric _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
