进程上下文和中断上下文是操作系统中很重要的两个概念，这两个概念在操作系统课程中不断被提及，是最经常接触、看上去很懂但又说不清楚到底怎么回事。造成这种局面的原因，可能是原来接触到的操作系统课程的教学总停留在一种浅层次的理论层面上，没有深入去研究。
处理器总处于以下状态中的一种：
１、内核态，运行于进程上下文，内核代表进程运行于内核空间；
２、内核态，运行于中断上下文，内核代表硬件运行于内核空间；
３、用户态，运行于用户空间。
用户空间的应用程序，通过系统调用，进入内核空间。这个时候用户空间的进程要传递很多变量、参数的值给内核，内核态运行的时候也要保存用户进程的一些寄存器值、变量等。所谓的“进程上下文”，可以看作是用户进程传递给内核的这些参数以及内核要保存的那一整套的变量和寄存器值和当时的环境等。
硬件通过触发信号，导致内核调用中断处理程序，进入内核空间。这个过程中，硬件的一些变量和参数也要传递给内核，内核通过这些参数进行中断处理。所谓的“中断上下文”，其实也可以看作就是硬件传递过来的这些参数和内核需要保存的一些其他环境（主要是当前被打断执行的进程环境）。
LINUX完全注释中的一段话：
当一个进程在执行时,CPU的所有寄存器中的值、进程的状态以及堆栈中的内容被称为该进程的上下文。当内核需要切换到另一个进程时，它需要保存当前进程的所有状态，即保存当前进程的上下文，以便在再次执行该进程时，能够必得到切换时的状态执行下去。在LINUX中，当前进程上下文均保存在进程的任务数据结构中。在发生中断时,内核就在被中断进程的上下文中，在内核态下执行中断服务例程。但同时会保留所有需要用到的资源，以便中继服务结束时能恢复被中断进程的执行。
Interrupt Context
-------------------------------------------
Whenexecuting an interrupt handler or bottom half, the kernel is ininterrupt context. Recall that process context is the mode ofoperation the kernel is in while it is executing on behalf of aprocess -- for example, executing a system call or running a kernelthread. In process context, the current macro points to theassociated task. Furthermore, because a process is coupled to thekernel in process context(因为进程是以进程上文的形式连接到内核中的), process contextcan sleep or otherwise invoke the scheduler.
Interruptcontext, on the otherhand, is notassociated with a process. The currentmacro is not relevant (although it points to the interruptedprocess). Without a backingprocess(由于没有进程的背景), interrupt context cannot sleep -- how would it everreschedule?(否则怎么再对它重新调度?) Therefore,you cannot call certain functions from interrupt context. If afunction sleeps, you cannot use it from your interrupt handler --this limits the functions that one can call from an interrupthandler.(这是对什么样的函数可以在中断处理程序中使用的限制)
Interruptcontext is time critical because the interrupt handler interruptsother code. Code should be quick and simple. Busy looping isdiscouraged. This is a very important point; always keep in mindthat your interrupt handler has interrupted other code (possiblyeven another interrupt handler on a different line!). Because ofthis asynchronous nature, it is imperative(必须) that all interrupthandlers be as quick and as simple as possible. As much aspossible, work should be pushed out from the interrupt handler andperformed in a bottom half, which runs at a more convenienttime.
Thesetup of an interrupt handler's stacks is a configuration option.Historically, interrupt handlers did not receive(拥有) their ownstacks. Instead, they would share the stack of the process thatthey interrupted[1]. The kernel stackis two pages in size; typically, that is 8KB on 32-bitarchitectures and 16KB on 64-bit architectures. Because in thissetup interrupt handlers share the stack, they must beexceptionally frugal(必须非常节省) with what data they allocate there. Ofcourse, the kernel stack is limited to begin with, so all kernelcode should be cautious.
[1] Aprocess is always running. When nothing else is schedulable, theidle task runs.
Earlyin the 2.6 kernel process, an optionwas added to reduce the stack size from two pages down to one,providing only a 4KB stack on 32-bit systems. This reduced memorypressure because every process on the system previously needed twopages of nonswappable kernelmemory. To copewith(应对) the reduced stack size, interrupt handlers were giventheir own stack, onestack per processor, one page in size.This stack is referred to as the interruptstack(这个栈就程为中断栈). Although the totalsize of the interrupt stack is half that of the original sharedstack, the average stack space available is greater becauseinterrupt handlers get the full page of memory tothemselves.
Yourinterrupt handler should not care what stack setup is in use orwhat the size of the kernel stack is. Always use an absoluteminimum amount of stack space.
Process Context
-------------------------------------------
One of themost important parts of a process is the executing program code.This code is read in from an executable file and executed withinthe program's address space. Normal program execution occurs inuser-space. When a program executes a system call or triggers anexception, it enters kernel-space. At this point, the kernel issaid to be "executing on behalf of the process" and is in processcontext. When in process context, the current macro is valid[7].Upon exiting the kernel, the process resumes execution inuser-space, unless a higher-priority process has become runnable inthe interim(过渡期), in which case the scheduler is invoked to selectthe higher priority process.
[7] Otherthan process context there is interrupt context, In interruptcontext, the system is not running on behalf of a process, but isexecuting an interrupt handler. There is no process tied tointerrupt handlers and consequently no process context.
System callsand exception handlers are well-defined interfaces into the kernel.A process can begin executing in kernel-space only through one ofthese interfaces -- all access to the kernel is through theseinterfaces.
-------------------------------------------
上下文context：上下文简单说来就是一个环境，相对于进程而言，就是进程执行时的环境。具体来说就是各个变量和数据，包括所有的寄存器变量、进程打开的文件、内存信息等。
一个进程的上下文可以分为三个部分:用户级上下文、寄存器上下文以及系统级上下文。
用户级上下文:正文、数据、用户堆栈以及共享存储区；
寄存器上下文:通用寄存器、程序寄存器(IP)、处理器状态寄存器(EFLAGS)、栈指针(ESP)；
系统级上下文:进程控制块task_struct、内存管理信息(mm_struct、vm_area_struct、pgd、pte)、内核栈。
当发生进程调度时，进行进程切换就是上下文切换(contextswitch).操作系统必须对上面提到的全部信息进行切换，新调度的进程才能运行。而系统调用进行的模式切换(modeswitch)。模式切换与进程切换比较起来，容易很多，而且节省时间，因为模式切换最主要的任务只是切换进程寄存器上下文的切换。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/zhiyu520/archive/2008/07/27/2719827.aspx
