我一开始没注意这个问题，只是通过陷阱门觉得很绕弯子，为何不在3级用户代码里直接调用write_char，今天自己写程序想用call调用代码段，才发现了大问题。我写了个类似于write_char的过程，代码如下：

dividing_line:push %gspushl %ebxpushl %ecxmovl $10,%ecx/*输出10个空格'  '*/movl $SCRN_SEL,%ebxmovw %bx,%gs
1:  movl scr_loc,%ebxshl $1,%ebxmovb $32,%gs:(%ebx)/*' '空格ASCII码*/shr $1,%ebxincl %ebxcmpl $2000,%ebxjb   2fmovl $0,%ebx
2:  movl %ebx,scr_locloop 1bpopl %ecxpopl %ebxpop %gsret

其功能为在屏幕上输出10个空格而已。简直和write_char几乎一样，只不过我指定了要输出的字符，不是通过ax获取罢了。还有一个不同就是我要通过call来调用dividing_line，而不是像write_char一样被陷阱门调用。

结果程序挂了，没法运行。

后来分析了下，原因很简单。我在task1里面直接调用write_char也是不行。这两者原因是相同的，那就是这两行代码：

movl $SCRN_SEL,%ebx
movw %bx,%gs

在源代码中SCRN_SEL= 0x18是GDT中显示数据段的selector，甭管他是什么数据段，反正他是数据段就对了，这个数据段描述符DPL=0，属于高特权级，但是我们现在用特权级3级的代码去调用这个过程，那么这个处理过程此时就算作3级程序的一员，即他的特权级也是3级，CPL=3，尽管SCRN_SEL= 0x18中的RPL=0，但是CPL不够级别，这种加载SCRN_SEL= 0x18的请求必将被处理器驳回。处理器在加载selector进段寄存器时会将当前运作程序的CPL、selector的RPL、被指向描述符的DPL做综合比较，除非CPL和RPL在数值上都小于DPL，也就是特权级较高。否则，这种加载selector的行为都将被处理器拦截并产生保护异常。

回到我的程序，所以只要这个加载0x18 这个selector的行为存在，这个过程的调用就必然失败，因为0x18 这个selector所指向的数据段描述符DPL超高。于是乎，在3级程序里直接调用write_char也好，dividing_line也好，都会失败，无权访问此数据段，有意图也不行。

这就是为什么要通过陷阱门去调用write_char，处理器规定通过陷阱门只能向高特权级代码段转移，不得转入低特权级代码段，意思就是我从3级用户代码转入内核0级代码这是天经地义的。但是注意，3级代码的确可以通过陷阱门转入0级代码，但前提是陷阱门的门描述符DPL=3才行。不然用户程序根本没权限去访问陷阱门。好了，我们假设陷阱门描述符DPL=3，陷阱门描述符里面的目标代码selector指向一段内核0级代码。

这样当3级程序去加载陷阱门描述符，完全可行，因为CPL=3,我们再用RPL=3的selector去访问陷阱门，陷阱门DPL=3，这样完全可以访问陷阱门。然后陷阱门里面的目标selector部分指向0级代码，这没有关系，通过陷阱门我们完全可以转过去，处理器就要我们这样做！这才是应该的过程。低级程序访问低级陷阱门，低级陷阱门里有高特权级的代码段selector，这样可以通过陷阱门转入高特权级的内核代码当中去。这为一些系统调用提供了方便。

最后有一点，我们把这两行导致问题的代码去掉，能不能正常调用呢？答案是肯定的，既然把这两行去了，那么这个处理过程的功能就废了，好不如写个简单点的，比如：

example:pushl %eaxmovl $0x250,%eaxpop %eaxret

这个够简单，在3级用户代码里call example就可以调用了，没有输出提示所以我们可以通过bochs调试来确认，结果就是调用成功，执行过程成功进入此example代码。这就是个普通近调用，没啥特殊的。关于陷阱门特权级我们就说到这里。

说完了。