如何在Linux内核里增加一个系统调用？

一、Linux0.11下添加系统调用：\x0d\x0a\x0d\x0a我在bochs2.2.1中对linux0.11内核添加了一个新的系统调用，步骤如下： \x0d\x0a1./usr/src/linux/include/unistd.h中添加：#define __NR_mytest 87 \x0d\x0a然后在下面声明函数原型：int mytest()\x0d\x0a2./usr/src/linux/include/linux/sys.h中添加:extern int sys_mytest()\x0d\x0a然后在sys_call_table中最后加上sys_mytest； \x0d\x0a3.在/usr/src/linux/kernel/sys.c中添加函数实现如下： \x0d\x0aint sys_mytest(){ \x0d\x0aprintk("This is a test!")\x0d\x0areturn 123\x0d\x0a} \x0d\x0a4.在/usr/src/linux/kernel/system_call.s中对系统调用号加1（原来是86改成了87） \x0d\x0a5.然后到/usr/src/linux目录下编译内核make cleanmake Image \x0d\x0a6. cp /usr/src/linux/include/unistd.h /usr/include/unistd.h \x0d\x0a7. reset bochs \x0d\x0a8. 在/usr/root中生成test.c文件如下： \x0d\x0a#define __LIBRARY__ \x0d\x0a#include \x0d\x0a_syscall0(int,mytest) \x0d\x0aint main(){ \x0d\x0aint a\x0d\x0aa = mytest()\x0d\x0aprintf("%d", a)\x0d\x0areturn 0\x0d\x0a} \x0d\x0a9.然后gcc test.c编译之后运行a.out，前面所有步骤都通过，但是每次调用都是返回-1，然后我查过errno为1（表示 *** 作不允许），就不知道为什么了？ \x0d\x0a系统知道的高手们能够告知一下，不胜感激！这个问题困扰我很久了！ \x0d\x0a\x0d\x0a二、新Linux内核添加系统调用\x0d\x0a\x0d\x0a如何在Linux系统中添加新的系统调用\x0d\x0a系统调用是应用程序和 *** 作系统内核之间的功能接口。其主要目的是使得用户可以使用 *** 作系统提供的有关设备管理、输入/输入系统、文件系统和进程控制、通信以及存储管理等方面的功能，而不必了解系统程序的内部结构和有关硬件细节，从而起到减轻用户负担和保护系统以及提高资源利用率的作用。\x0d\x0a\x0d\x0aLinux *** 作系统作为自由软件的代表，它优良的性能使得它的应用日益广泛，不仅得到专业人士的肯定，而且商业化的应用也是如火如荼。在Linux中，大部分的系统调用包含在Linux的libc库中，通过标准的C函数调用方法可以调用这些系统调用。那么，对Linux的发烧友来说，如何在Linux中增加新的系统调用呢？ \x0d\x0a1 Linux系统调用机制\x0d\x0a\x0d\x0a在Linux系统中，系统调用是作为一种异常类型实现的。它将执行相应的机器代码指令来产生异常信号。产生中断或异常的重要效果是系统自动将用户态切换为核心态来对它进行处理。这就是说，执行系统调用异常指令时，自动地将系统切换为核心态，并安排异常处理程序的执行。Linux用来实现系统调用异常的实际指令是：\x0d\x0a\x0d\x0aInt $0x80\x0d\x0a\x0d\x0a这一指令使用中断/异常向量号128（即16进制的80）将控制权转移给内核。为达到在使用系统调用时不必用机器指令编程，在标准的C语言库中为每一系统调用提供了一段短的子程序，完成机器代码的编程工作。事实上，机器代码段非常简短。它所要做的工作只是将送给系统调用的参数加载到CPU寄存器中，接着执行int $0x80指令。然后运行系统调用，系统调用的返回值将送入CPU的一个寄存器中，标准的库子程序取得这一返回值，并将它送回用户程序。\x0d\x0a\x0d\x0a为使系统调用的执行成为一项简单的任务，Linux提供了一组预处理宏指令。它们可以用在程序中。这些宏指令取一定的参数，然后扩展为调用指定的系统调用的函数。\x0d\x0a\x0d\x0a这些宏指令具有类似下面的名称格式：\x0d\x0a\x0d\x0a_syscallN（parameters）\x0d\x0a\x0d\x0a其中N是系统调用所需的参数数目，而parameters则用一组参数代替。这些参数使宏指令完成适合于特定的系统调用的扩展。例如，为了建立调用setuid（）系统调用的函数，应该使用：\x0d\x0a\x0d\x0a_syscall1（ int， setuid， uid_t， uid ）\x0d\x0a\x0d\x0asyscallN（ ）宏指令的第1个参数int说明产生的函数的返回值的类型是整型，第2个参数setuid说明产生的函数的名称。后面是系统调用所需要的每个参数。这一宏指令后面还有两个参数uid_t和uid分别用来指定参数的类型和名称。\x0d\x0a\x0d\x0a另外，用作系统调用的参数的数据类型有一个限制，它们的容量不能超过四个字节。这是因为执行int $0x80指令进行系统调用时，所有的参数值都存在32位的CPU寄存器中。使用CPU寄存器传递参数带来的另一个限制是可以传送给系统调用的参数的数目。这个限制是最多可以传递5个参数。所以Linux一共定义了6个不同的_syscallN（）宏指令，从_syscall0（）、_syscall1（）直到_syscall5（）。\x0d\x0a\x0d\x0a一旦_syscallN（）宏指令用特定系统调用的相应参数进行了扩展，得到的结果是一个与系统调用同名的函数，它可以在用户程序中执行这一系统调用。\x0d\x0a2 添加新的系统调用 \x0d\x0a如果用户在Linux中添加新的系统调用，应该遵循几个步骤才能添加成功，下面几个步骤详细说明了添加系统调用的相关内容。\x0d\x0a\x0d\x0a（1） 添加源代码\x0d\x0a\x0d\x0a第一个任务是编写加到内核中的源程序，即将要加到一个内核文件中去的一个函数，该函数的名称应该是新的系统调用名称前面加上sys_标志。假设新加的系统调用为mycall(int number)，在/usr/src/linux/kernel/sys.c文件中添加源代码，如下所示：\x0d\x0aasmlinkage int sys_mycall(int number) \x0d\x0a{ \x0d\x0areturn number\x0d\x0a}\x0d\x0a作为一个最简单的例子，我们新加的系统调用仅仅返回一个整型值。\x0d\x0a\x0d\x0a（2） 连接新的系统调用\x0d\x0a\x0d\x0a添加新的系统调用后，下一个任务是使Linux内核的其余部分知道该程序的存在。为了从已有的内核程序中增加到新的函数的连接，需要编辑两个文件。\x0d\x0a\x0d\x0a在我们所用的Linux内核版本（RedHat 6.0，内核为2.2.5-15）中，第一个要修改的文件是：\x0d\x0a\x0d\x0a/usr/src/linux/include/asm-i386/unistd.h\x0d\x0a\x0d\x0a该文件中包含了系统调用清单，用来给每个系统调用分配一个唯一的号码。文件中每一行的格式如下：\x0d\x0a\x0d\x0a#define __NR_name NNN\x0d\x0a\x0d\x0a其中，name用系统调用名称代替，而NNN则是该系统调用对应的号码。应该将新的系统调用名称加到清单的最后，并给它分配号码序列中下一个可用的系统调用号。我们的系统调用如下：\x0d\x0a\x0d\x0a#define __NR_mycall 191\x0d\x0a\x0d\x0a系统调用号为191，之所以系统调用号是191，是因为Linux-2.2内核自身的系统调用号码已经用到190。\x0d\x0a\x0d\x0a第二个要修改的文件是：\x0d\x0a\x0d\x0a/usr/src/linux/arch/i386/kernel/entry.S\x0d\x0a\x0d\x0a该文件中有类似如下的清单：\x0d\x0a.long SYMBOL_NAME（）\x0d\x0a\x0d\x0a该清单用来对sys_call_table[]数组进行初始化。该数组包含指向内核中每个系统调用的指针。这样就在数组中增加了新的内核函数的指针。我们在清单最后添加一行：\x0d\x0a.long SYMBOL_NAME(sys_mycall)\x0d\x0a\x0d\x0a（3） 重建新的Linux内核\x0d\x0a\x0d\x0a为使新的系统调用生效，需要重建Linux的内核。这需要以超级用户身份登录。\x0d\x0a#pwd \x0d\x0a/usr/src/linux \x0d\x0a#\x0d\x0a\x0d\x0a超级用户在当前工作目录（/usr/src/linux）下，才可以重建内核。\x0d\x0a\x0d\x0a#make config \x0d\x0a#make dep \x0d\x0a#make clearn \x0d\x0a#make bzImage\x0d\x0a\x0d\x0a编译完毕后，系统生成一可用于安装的、压缩的内核映象文件：\x0d\x0a\x0d\x0a/usr/src/linux/arch/i386/boot/bzImage \x0d\x0a（4） 用新的内核启动系统 \x0d\x0a要使用新的系统调用，需要用重建的新内核重新引导系统。为此，需要修改/etc/lilo.conf文件，在我们的系统中，该文件内容如下：\x0d\x0a\x0d\x0aboot=/dev/hda \x0d\x0amap=/boot/map \x0d\x0ainstall=/boot/boot.b \x0d\x0aprompt \x0d\x0atimeout=50 \x0d\x0a\x0d\x0aimage=/boot/vmlinuz-2.2.5-15 \x0d\x0alabel=linux \x0d\x0aroot=/dev/hdb1 \x0d\x0a　 read-only \x0d\x0a\x0d\x0aother=/dev/hda1 \x0d\x0alabel=dos \x0d\x0atable=/dev/had\x0d\x0a\x0d\x0a首先编辑该文件，添加新的引导内核：\x0d\x0aimage=/boot/bzImage-new \x0d\x0alabel=linux-new \x0d\x0aroot=/dev/hdb1 \x0d\x0aread-only\x0d\x0a\x0d\x0a添加完毕，该文件内容如下所示：\x0d\x0aboot=/dev/hda \x0d\x0amap=/boot/map \x0d\x0ainstall=/boot/boot.b \x0d\x0aprompt \x0d\x0atimeout=50 \x0d\x0a\x0d\x0aimage=/boot/bzImage-new \x0d\x0alabel=linux-new \x0d\x0aroot=/dev/hdb1 \x0d\x0aread-only \x0d\x0a\x0d\x0aimage=/boot/vmlinuz-2.2.5-15 \x0d\x0alabel=linux \x0d\x0aroot=/dev/hdb1 \x0d\x0aread-only \x0d\x0a\x0d\x0aother=/dev/hda1 \x0d\x0alabel=dos \x0d\x0atable=/dev/hda\x0d\x0a\x0d\x0a这样，新的内核映象bzImage-new成为缺省的引导内核。为了使用新的lilo.conf配置文件，还应执行下面的命令：\x0d\x0a#cp /usr/src/linux/arch/i386/boot/zImage /boot/bzImage-new\x0d\x0a\x0d\x0a其次配置lilo:\x0d\x0a\x0d\x0a# /sbin/lilo\x0d\x0a\x0d\x0a现在，当重新引导系统时，在boot:提示符后面有三种选择：linux-new 、linux、dos，新内核成为缺省的引导内核。\x0d\x0a至此，新的Linux内核已经建立，新添加的系统调用已成为 *** 作系统的一部分，重新启动Linux，用户就可以在应用程序中使用该系统调用了。\x0d\x0a\x0d\x0a（5）使用新的系统调用\x0d\x0a\x0d\x0a在应用程序中使用新添加的系统调用mycall。同样为实验目的，我们写了一个简单的例子xtdy.c。\x0d\x0a\x0d\x0a/* xtdy.c */ \x0d\x0a#include \x0d\x0a_syscall1(int,mycall,int,ret) \x0d\x0amain() \x0d\x0a{ \x0d\x0aprintf("%d \n",mycall(100))\x0d\x0a}\x0d\x0a编译该程序：\x0d\x0a# cc -o xtdy xtdy.c\x0d\x0a执行：\x0d\x0a# xtdy\x0d\x0a结果：\x0d\x0a# 100\x0d\x0a注意，由于使用了系统调用，编译和执行程序时，用户都应该是超级用户身份。

Linux内核中的RCU机制

RCU的设计思想比较明确，通过新老指针替换的方式来实现免锁方式的共享保护。但是具体到代码的层面，理解起来多少还是会有些困难。下面我准备了关于Linux内核中的RCU机制的文章，提供给大家参考!

RCU读取侧进入临界区的标志是调用rcu_read_lock，这个函数的代码是：

static inline void rcu_read_lock(void)

{

__rcu_read_lock()

__acquire(RCU)

rcu_read_acquire()

}

该实现里面貌似有三个函数调用，但实质性的工作由第一个函数__rcu_read_lock()来完成，__rcu_read_lock()通过调用 preempt_disable()关闭内核可抢占性。但是中断是允许的，假设读取者正处于rcu临界区中且刚读取了一个共享数据区的指针p(但是还没有访问p中的数据成员)，发生了一个中断，而该中断处理例程ISR恰好需要修改p所指向的数据区，按照RCU的设计原则，ISR会新分配一个同样大小的数据区new_p，再把老数据区p中的数据拷贝到新数据区，接着是在new_p的基础上做数据修改的工作(因为是在new_p空间中修改，所以不存在对p的并发访问，因此说RCU是一种免锁机制，原因就在这里)，ISR在把数据更新的工作完成后，将new_p赋值给p(p=new_p),最后它会再注册一个回调函数用以在适当的时候释放老指针p。因此，只要对老指针p上的所有引用都结束了，释放p就不会有问题。当中断处理例程做完这些工作返回后，被中断的进程将依然访问到p空间上的数据，也就是老数据，这样的结果是RCU机制所允许的。RCU规则对读取者与写入者之间因指针切换所造成的短暂的资源视图不一致问题是允许的。

接下来关于RCU一个有趣的问题是：何时才能释放老指针。我见过很多书中对此的'回答是：当系统中所有处理器上都发生了一次进程切换。这种程式化的回答常常让刚接触RCU机制的读者感到一头雾水，为什么非要等所有处理器上都发生一次进程切换才可以调用回调函数释放老指针呢?这其实是RCU的设计规则决定的： 所有对老指针的引用只可能发生在rcu_read_lock与rcu_read_unlock所包括的临界区中，而在这个临界区中不可能发生进程切换，而一旦出了该临界区就不应该再有任何形式的对老指针p的引用。很明显，这个规则要求读取者在临界区中不能发生进程切换，因为一旦有进程切换，释放老指针的回调函数就有可能被调用，从而导致老指针被释放掉，当被切换掉的进程被重新调度运行时它就有可能引用到一个被释放掉的内存空间。

现在我们看到为什么rcu_read_lock只需要关闭内核可抢占性就可以了，因为它使得即便在临界区中发生了中断，当前进程也不可能被切换除去。 内核开发者，确切地说，RCU的设计者所能做的只能到这个程度。接下来就是使用者的责任了，如果在rcu的临界区中调用了一个函数，该函数可能睡眠，那么RCU的设计规则就遭到了破坏，系统将进入一种不稳定的状态。

这再次说明，如果想使用一个东西，一定要搞清楚其内在的机制，象上面刚提到的那个例子，即便现在程序不出现问题，但是系统中留下的隐患如同一个定时炸d， 随时可能被引爆，尤其是过了很长时间问题才突然爆发出来。绝大多数情形下，找到问题所花费的时间可能要远远大于静下心来仔细搞懂RCU的原理要多得多。

RCU中的读取者相对rwlock的读取者而言，自由度更高。因为RCU的读取者在访问一个共享资源时，不需要考虑写入者的感受，这不同于rwlock的写入者，rwlock reader在读取共享资源时需要确保没有写入者在 *** 作该资源。两者之间的差异化源自RCU对共享资源在读取者与写入者之间进行了分离，而rwlock的 读取者和写入者则至始至终只使用共享资源的一份拷贝。这也意味着RCU中的写入者要承担更多的责任，而且对同一共享资源进行更新的多个写入者之间必须引入某种互斥机制，所以RCU属于一种"免锁机制"的说法仅限于读取者与写入者之间。所以我们看到：RCU机制应该用在有大量的读取 *** 作，而更新 *** 作相对较少的情形下。此时RCU可以大大提升系统系能，因为RCU的读取 *** 作相对其他一些有锁机制而言，在锁上的开销几乎没有。

实际使用中，共享的资源常常以链表的形式存在，内核为RCU模式下的链表 *** 作实现了几个接口函数，读取者和使用者应该使用这些内核函数，比如 list_add_tail_rcu, list_add_rcu，hlist_replace_rcu等等，具体的使用可以参考某些内核编程或者设备驱动程序方面的资料。

在释放老指针方面，Linux内核提供两种方法供使用者使用，一个是调用call_rcu,另一个是调用synchronize_rcu。前者是一种异步 方式，call_rcu会将释放老指针的回调函数放入一个结点中，然后将该结点加入到当前正在运行call_rcu的处理器的本地链表中，在时钟中断的 softirq部分(RCU_SOFTIRQ)， rcu软中断处理函数rcu_process_callbacks会检查当前处理器是否经历了一个休眠期(quiescent，此处涉及内核进程调度等方面的内容)，rcu的内核代码实现在确定系统中所有的处理器都经历过了一个休眠期之后(意味着所有处理器上都发生了一次进程切换，因此老指针此时可以被安全释放掉了)，将调用call_rcu提供的回调函数。

synchronize_rcu的实现则利用了等待队列，在它的实现过程中也会向call_rcu那样向当前处理器的本地链表中加入一个结点，与 call_rcu不同之处在于该结点中的回调函数是wakeme_after_rcu，然后synchronize_rcu将在一个等待队列中睡眠，直到系统中所有处理器都发生了一次进程切换，因而wakeme_after_rcu被rcu_process_callbacks所调用以唤醒睡眠的 synchronize_rcu，被唤醒之后，synchronize_rcu知道它现在可以释放老指针了。

所以我们看到，call_rcu返回后其注册的回调函数可能还没被调用，因而也就意味着老指针还未被释放，而synchronize_rcu返回后老指针肯定被释放了。所以，是调用call_rcu还是synchronize_rcu，要视特定需求与当前上下文而定，比如中断处理的上下文肯定不能使用 synchronize_rcu函数了。

---