一、系统调用实验：

1.知识准备：

（1）系统调用的三层皮：xyz()（API）、system_call(所有系统调用的入口) 、 sys_xyz()(中断服务程序)

（2）API是程序员在用户空间下可以直接使用的函数接口，它提供了一套封装例程，将系统调用在用户空间包装后供用户编程使用。涉及到与内核空间进行交互的API会封装系统调用，而不涉及与内核进行交互的API不会封装系统调用。

（3）系统调用是用户进入内核的接口，并非内核函数。用户程序通过某个系统调用进入内核后，会接着去执行这个系统调用对应的内核函数。这个内核函数 sys_xyz() 称为系统调用的服务例程。

（4）系统调用号将 xyz() 与 sys_xyz() 关联起，系统调用号由 eax 寄存器传递。

2.系统调用的两种实现方法：

  本实验我选择的是系统调用号为 38 的 sys_rename()，功能实现设计为将hello.c 文件重新命名 newhello.c

（1）库函数API实现：

运行结果如下：

（2）嵌入汇编代码实现：

运行结果如下：

3.实验分析：

（1）库函数API实现：

在 /include/linux/syscalls.h 中找到 sys_rename 函数原型：

asmlinkage long sys_rename(const char __user *oldname,const char __user *newname);

可以看出需要传递两个参数，一个是旧文件名，一个是新文件名。由于是指针类型，所以此时的文件名也代表该文件，也就是说，先找到叫 oldname 的文件，然后把其名改为 newname。rename() 是 glibc 对sys_rename 的封装，用户在用户态调用 rename(),将 oldname和newname 参数传入，系统会产生中断陷入内核态执行sys_rename。当重命名成功时，函数返回0。

（2）嵌入汇编代码实现：

asm volatile("movl %2,%%ecx\n\t"         //newname存入ecx

             "movl %1,%%ebx\n\t"         //oldname存入ebx

             "movl $0x26,%%eax\n\t"      //系统调用号存入eax

             "int $0x80"                 //执行系统调用

             :"=a"(ret)

             :"b"(oldname),"c"(newname)

                        );

  把系统调用号38(16进制是0x26)存入 eax，将 oldname 存入 ebx，将 newname 存入 ecx，通过执行 int $0x80 来执行系统调用，使应用程序陷入内核态，system_call 根据传入的系统调用号在系统调用列表中查找对应的内核函数，根据 ebx 和 ecx 中保存的参数调用内核函数 sys_rename，执行完后将执行结果存放到 eax 中,最后返回 eax 中的值。

4.问题及解决：

（1）起初不太会写汇编，老师给的例子没有参数，将 ebx 清零，而 sys_rename 有两个参数，该往哪里放呢？通过搜索我知道了参数按顺序赋值给ebx、ecx、edx、esi、edi、ebp，如果超过6个则通过指针变量指向另一片堆栈区，如果无参数传入则赋值为0。于是，oldname 是第一个参数传给 ebx，newname 是第二个参数传给 ecx。

（2）在学习C语言嵌入汇编时，我看到了“m”代表内存变量，于是我想可不可以把“=a”变成“=m”，结果如下：

可看出 hello.c 确实变成了 newhello.c，但却显示没有修改成功，即 ret 不等于0。既然确实执行了 sys_rename，返回值0就应该保存在 eax中，返回采用的是“=m”，是不是返回值0并没有在内存中？于是我将代码改为：

也就是把 eax 中的值0放入内存，但编译后又出错了：

这个问题困扰了我很久，我看了很多简单的嵌入汇编代码，发现在输出的上一行才会出现不加 \n\t 的情况，其他语句最后都有\n\t，搜索后我知道语句之间需使用"\n"或"\n\r"或"\n\t"分开，我猜测不加\n\t说明已经执行结束，再在其后补充一条代码肯定会出错，所以将代码改为:

执行成功：

此外，movl允许寄存器到寄存器，立即数到寄存器等，但是不允许内存到内存的操作。因此操作数不能同时使用"m"作为限定字符。

（3）API方法实现系统调用实现非常便捷，只需知道函数原型即可，有很好的移植性。但是，如果 glibc 没有封装某个内核提供的系统调用时，就没办法通过此方法来调用内核函数。我想，如果内核增加了一个新的系统调用，没来得及为其编写API，那我该如何进行系统调用呢？

参考Linux 下系统调用的三种方法，可以利用 glibc 提供的syscall 函数直接调用。函数原型为long int syscall (long int sysno, ...)sysno 是系统调用号，在 sys/syscall.h 中有所有可能的系统调用号的宏定义。代码改为（SYS_rename换成38也正确）：

执行成功：

（4）如果本身就存在 newhello.c，我认为肯定会报错，重命名不成功。实践后发现并不是这样：

可以看出修改成功，且只有一个 newhello.c，那这个 newhello.c 到底是 hello.c的重命名，还是以前的 newhello.c 呢？我在 hello.c 中写入 hello.c，在 newhello.c 中写入 newhello.c，发现执行完 rename 后的 newhello.c 中内容是 hello.c，即是 hello.c的重命名：

所以，如果newname指定的文件存在，则会被删除。

5.小结：

  如果用户态要涉及内核态的操作，就需要通过系统调用来实现，可以屏蔽平台相关操作，降低了软件开发难度，增强了系统安全性，使程序具有更好的移植性。系统调用过程为：应用程序在用户态调用 API 函数，系统调用号和参数保存到 eax，ebx 等寄存器中，通过 0x80 中断向量触发中断陷入内核态，中断服务程序根据系统调用号调用并执行对应的内核函数，执行完毕后将结果存放的 eax 中并返回给程序，程序返回用户态。

二、课本笔记：

  处理器的速度跟外围硬件设备的速度往往不在一个数量级，所以提供中断机制，让硬件需要的时候再向内核发出信号，使得处理器和外部设备可以协同工作。硬件发出的中断是为了通知内核有新的东西等待处理，内核响应中断时会执行中断处理程序，运行于中断上下文。

  中断处理可切为上半部和下半部。重要、紧迫而又与硬件相关的工作必须放在上半部，下半部的实现主要是通过软中断、tasklet、工作队列来实现。上半部的功能是响应中断。上半部完全屏蔽中断，如果它没有执行完，其他中断就不能及时地处理，只能等到这个中断处理程序执行完毕以后。下半部是可中断的，如果其它设备产生了中断，这个下半部可以暂时中断，等到那个设备的上半部运行完了，再运行自己的下半部。request_irq() 注册中断处理程序，free_irq() 释放中断处理程序。上半部将下半部排到它们所负责的设备中断的处理队列中去，不再做其他处理，而下半部几乎完成了中断处理程序所有的事情。

  软中断一般是“可延迟函数”的总称，可延迟函数上可以执行四种操作：初始化、激活、执行、屏蔽。软中断产生后并不是马上执行，必须要等待内核的调度才能执行。软中断不能被自己打断，只能被中断打断（上半部）。软中断可以并发运行在多个CPU上（即使同一类型的也可以）。软中断必须设计为可重入的函数（允许多个CPU同时操作），因此也需要使用自旋锁来保护其数据结构。

  tasklet建立在软中断上。某一段tasklet代码在某个时刻只能在一个CPU上运行，不同的tasklet代码在同一时刻可以在多个CPU上并发地执行。用DECLARE_TASKLET(name,func, data)和DECLARE_TASKLET_DISABLED(name,func, data)静态地创建一个tasklet_struct结构。当该tasklet被调度以后，给定的函数func（处理程序）会被执行，它的参数由data给出，此外还可动态地创建tasklet。tasklet不能睡眠，但可以响应中断。

  软中断不能睡眠、不能阻塞。由于中断上下文出于内核态，没有进程切换，所以如果软中断一旦睡眠或者阻塞，将无法退出这种状态，导致内核会整个僵死，因此要使用工作队列。工作队列可以在进程上下文中执行，工作队列允许被重新调度甚至是睡眠。推后执行的任务叫做工作（work），数据结构为work_struct，这些工作以队列结构组织成工作队列（workqueue），数据结构为workqueue_struct，而工作线程就是负责执行工作队列中的工作。当一个工作者线程被唤醒时，它会执行它的链表上的所有工作。工作被执行完毕，它就将相应的work_struct对象从链表上移去。当链表上不再有对象的时候，它就会继续休眠。

思考：中断上下文为什么不能睡眠？

  睡眠是为了进程调度存在的。进程有进程号，但是中断没有。中断处理程序一旦睡眠，不仅没有其他的东西会获得处理器而且无法调度，所以中断处理程序永远不会被唤醒，系统就会瘫痪。