Linux系统调用、新增系统调用方法【转】
转自：http://blog.chinaunix.net/uid-25374603-id-3401045.html
说明：
系统调用是内核和应用程序间的接口，应用程序要访问硬件设备和其他操作系统资源，可以通过系统调用来完成。
在linux中，系统调用是用户空间访问内核的一种手段，除异常和中断外，他们是进入内核的合法入口。系统调用的数量很少，在i386上只有大概300个左右。
应用程序员通过C库中的应用程序接口(API)而不是直接通过系统调用来编程。
C库中的函数可以不调用系统调用，也可以只是简单封装一个系统调用，还可以通过调用多个系统调用来实现一个功能。
linux>本身提供的一组宏来对系统调用直接进行访问。man 2 syscall。
从程序员的角度来看，系统调用无关紧要，他们只需要跟API打交道就可以了；
从内核的角度来看，内核只跟系统调用打交道，库函数及应用程序怎么使用系统调用不是内核所关心的。
linux内核中所有的系统调用函数都用sys_开头。
函数定义中的asmlinkage宏，用于通知编译器，使用局部堆栈来传递参数；
函数定义中的FASTCALL宏，用于通知编译器，使用寄存器来传递参数。
如果上面两个宏都没有，则使用默认传参规则，前4个参数通过R0~R3寄存器传递，其余更多的参数通过栈传递。
调用链：APP --> LIB --> kernel (syscall) --> module --> hardware
因为系统调用要从用户空间进入内核空间，所以不可能通过简单的函数调用完成，必须通过一些处理器支持的特殊机制(所谓的软中断)。
在x86上，这一特殊机制就是汇编指令int $0x80， 而在arm上，就是汇编指令SWI。
这条指令被封装到C库中的函数里，当程序执行到这一条指令后，cpu会进入一个特殊的异常模式(或软中断模式)，并将程序指针跳转到特点的位置(如arm为中断向量表的0x8处)。
内核中实现了很多的系统调用，这些系统调用的地址被按顺序放在一个系统调用表中，这个表是一个名为sys_call_table的数组，共有NR_syscalls个表项。
通过这个表，就可以调用到内核定义的所有sys_函数。
调用汇编指令int $0x80 或SWI 时，要同时传递一个系统调用号，这个系统调用号将作为索引，从sys_call_table中选择对应的系统调用。
int80将系统调用号保存在eax寄存器中，而SWI将其直接集成在指令中(如SWI 0x124)。
过程：swi 系统调用号 --> 系统调用表 --> 系统调用
内核中处理系统调用的函数定义在arch/x86/kernel/entry.s中的system_call，而arm系统在arch/arm/kernel/entry-common.s中的vector_swi。
x86系统的系统调用表定义在arch/x86/kernel/syscall_table.s(或直接定义在entry.s)中，而arm定义在arch/arm/kernel/calls.s中。
x86系统调用号定义在arch/x86/include/asm/unistd.h中，arm系统调用号定义在arch/arm/include/asm/unistd.h中。
系统调用必须仔细检查传入参数的有效性，尤其是用户提供的指针，必须确保：
*指针指向的内存区域属于用户空间，进程不能哄骗内核去读内核空间的数据。
*指针指向的内存区域属于进程的地址空间，不能哄骗内核去读其他进程的数据。
*进程不能绕过内存访问权限。
内核在执行系统调用的时候处于进程上下文，可以休眠，也可以被抢占，所以必须保证系统调用是可重入的。
跟踪linux内核中arm架构的sys_getpid()系统调用
系统调用号在文件arch/arm/include/asm/unistd.h中，如下：
说明：可见sys_getpid()的系统调用号是20，此调用号其实就是系统调用表(数组)的下标。所以系统调用表中sys_getpid()肯定在第20项。
特别注意：系统调用号17之类，此系统调用已经弃用，但为了兼容性及不至于日后混乱，所以调用号不能重用，只能空着(跳过).
系统调用表在文件arch/arm/kernel/calls.s，如下：
说明：可见sys_getpid()在系统调用表中第20项，和其系统调用号一致。
特别注意：系统调用号17对应的表项，对于已经弃用的系统调用，linux系统统一赋予sys_ni_syscall()系统调用。
系统调用的声明在文件 include/linux/syscalls.h，如下：
系统调用的实现在文件kernel/timer.c，如下：
说明：源代码中不能直接找到sys_getpid()的实现代码，因为64为系统的BUG，所以源代码中的系统调用sys_ABC，都用SYSCALL_DEFINEx(ABC)封装了一层，以解决BUG。
SYSCALL_DEFINE在文件include/linux/syscalls.h，如下：
手工添加一个自己实现的系统调用：
首先，模仿原来代码，在文件arch/arm/include/asm/unistd.h添加一个系统调用号，如下：
特别说明：自己新加的系统调用号只能在原来最大值得基础上加1，所以我的系统调用号是361，对应系统调用是sys_mysyscall()
然后，模仿原来代码，在文件arch/arm/kernel/calls.S添加一个系统调用表项，如下：
最后：编写系统调用的实现代码，此代码必须能保证编译进内核，如下：
因为我们知道文件init/main.c一定编译进内核，所以我们的实现代码在此文件中添加。
特别注意：系统调用必须返回long型值。
要使用此系统调用，必须重新编译内核，并且开发板必须使用新内核，如下：
程序：测试系统调用的实现效果
创建目录/nfsroot/kern/2012-04-16/02/。
创建文件/nfsroot/kern/2012-04-16/02/test.c，内容如下：
创建文件/nfsroot/kern/2012-04-16/02/Makefile，内容如下：
在主机端编译程序，过程如下：
在开发板端运行测试程序，过程如下：
说明：可见getpid的两种结果一直，我们自己的系统调用361也正确运行。
特别说明：
系统调用号是linux内核维护人员确定的，自己添加的系统调用，其他人开发的应用程序不会使用到，因为只有自己知道有这个系统调用。
这种系统调用需要直接修改内核源代码，而且必须编译进内核才能使用，而且系统调用号是自己设定的，所以一般不会这样手动添加系统调用。
若自己sys_open，sys_read等系统调用，可以通过模块来实现，从而实现系统调用的复用。
