linux内核情景分析{中断 系统调用 内存}
Linux的系统调用是通过中断来实现的，从用户态进入系统态。用户态和系统态有很清晰的区分，保证了安全。系统调用表是系统调用的跳转表。使用寄存器传递参数，而不是栈，因为用户态是无法访问系统栈的。地址错误是通过页面异常来处理的。
Linux内核并不支持真正意义上的线程，
LinuxThreads
是用与普通进程具有同样内核调度视图的轻量级进程来实现线程支持的。这些轻量级进程拥有独立的进程
id
，在进程调度、信号处理、
IO
等方面享有与普通进程一样的能力。由于异步信号是内核以进程为单位分发的，而
LinuxThreads
的每个线程对内核来说都是一个进程，且没有实现
"
线程组
"
，因此，某些语义不符合
POSIX
标准，比如没有实现向进程中所有线程发送信号，
README
对此作了说明。在
LinuxThreads
中，管理线程的栈和用户线程的栈是分离的，管理线程在进程堆中通过
malloc()
分配一个
THREAD_MANAGER_STACK_SIZE
字节的区域作为自己的运行栈。
"
一对一
"
模型的好处之一是线程的调度由核心完成了，而其他诸如线程取消、线程间的同步等工作，都是在核外线程库中完成的。管理线程与其他线程之间通过一对
"
管理管道（
manager_pipe[2]
）
"
来通讯。当核内既支持进程也支持线程时，就可以实现线程
-
进程的
"
多对多
"
模型，即一个进程的某个线程由核内调度，而同时它也可以作为用户级线程池的调度 者，选择合适的用户级线程在其空间中运行。这就是前面提到的
"
混合
"
线程模型，既可满足多处理机系统的需要，也可以最大限度的减小调度开销。绝大多数商业 操作系统（如
Digital Unix
、
Solaris
、
Irix
）都采用的这种能够完全实现
POSIX1003.1c
标准的线程模型。在核外实现的线程又可以分为
"
一对一
"
、
"
多对 一
"
两种模型，前者用一个核心进程（也许是轻量进程）对应一个线程，将线程调度等同于进程调度，交给核心完成，而后者则完全在核外实现多线程，调度也在用 户态完成。后者就是前面提到的单纯的用户级线程模型的实现方式，显然，这种核外的线程调度器实际上只需要完成线程运行栈的切换，调度开销非常小，但同时因 为核心信号（无论是同步的还是异步的）都是以进程为单位的，因而无法定位到线程，所以这种实现方式不能用于多处理器系统，而这个需求正变得越来越大，
相关文档：
<!--
@page { margin: 2cm }
P { margin-bottom: 0.21cm }
A:link { so-language: zxx }
-->
计算机桌面的“美”确实很抽象，不像女性的美，人们不易表达清楚。但是，
A
相对
B“
更美”的论断，却是比较容易说明白的。
& ......
1、特权级
Intel体系结构引入特权级是为了实现保护。所谓386保护模式就是在此基础上建立起来的。系统中每个段（CS、DS、SS）都有自己的特权级，系统中每个任务或程序也都有自己的特权。
2、操作模式
处理器加电或重启后，首先进入实模式，操作系统初始化部分负责从实模式到保护模式的切换。
3、段、段� ......
记得我们在上篇文章mem_init()分析中提到__free_page()函数吗？我们现在来完善它。它的调用过程是这样的：mem_init()->free_all_bootmem_node():我们知道这个函数是统计一共释放了多少空闲页。->free_all_bootmem_core()就是在这个函数里面先后多次调用__free_pages()函数。目的就是为了释放每个内存node里面� ......
在Linux，可以考虑用GTK(The GIMP Toolkit)来做GUI(Graphic User interface)开发，开发工具建议使用anjuta + glade(貌似eclipse+cdt也可以)。
建议：
一、先学习GTK+ 2.0本身，比如用vim+gcc+gdb+make+automake+autoconf...这样对基于GTK的图形开发过程就有了基本了解，以后用anjuata+glade自动生成代码的时候容易阅读和� ......
