To be a better coder
分类: LINUX
2017-03-01 16:54:52
原文地址:Linux系统调用、新增系统调用方法 作者:1119401255
说明:
系统调用是内核和应用程序间的接口,应用程序要访问硬件设备和其他操作系统资源,可以通过系统调用来完成。
在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等系统调用,可以通过模块来实现,从而实现系统调用的复用。