老胡说：我们不追捧热点，我们聚焦数字智慧 1.什么是系统调用系统调用，顾名思义，说的是操作系统提供给用户程序调用的一组“特殊”接口。用户程序可以通过这组“特殊”接口来获得操作系统内核提供的服务，比如用户可以通过文件系统相关的调用请求系统打开文件、关闭文件或读写文件，可以通过时钟相关的系统调用获得系统时间或设置定时器等。 从逻辑上来说，系统调用可被看成是一个内核与用户空间程序交互的接口——它好比一个中间人，把用户进程的请求传达给内核，待内核把请求处理完毕后再将处理结果送回给用户空间。 系统服务之所以需要通过系统调用来提供给用户空间的根本原因是为了对系统进行“保护”，因为我们知道Linux的运行空间分为内核空间与用户空间，它们各自运行在不同的级别中，逻辑上相互隔离。所以用户进程在通常情况下不允许访问内核数据，也无法使用内核函数，它们只能在用户空间操作用户数据，调用用户空间函数。比如我们熟悉的“hello world”程序（执行时）就是标准的用户空间进程，它使用的打印函数printf就属于用户空间函数，打印的字符“hello word”字符串也属于用户空间数据。 但是很多情况下，用户进程需要获得系统服务（调用系统程序），这时就必须利用系统提供给用户的“特殊接口”——系统调用了，它的特殊性主要在于规定了用户进程进入内核的具体位置；换句话说，用户访问内核的路径是事先规定好的，只能从规定位置进入内核，而不准许肆意跳入内核。有了这样的陷入内核的统一访问路径限制才能保证内核安全无虞。我们可以形象地描述这种机制：作为一个游客，你可以买票要求进入野生动物园，但你必须老老实实地坐在观光车上，按照规定的路线观光游览。当然，不准下车，因为那样太危险，不是让你丢掉小命，就是让你吓坏了野生动物。 2. Linux的系统调用对于现代操作系统，系统调用是一种内核与用户空间通讯的普遍手段，Linux系统也不例外。但是Linux系统的系统调用相比很多Unix和windows等系统具有一些独特之处，无处不体现出Linux的设计精髓——简洁和高效。 Linux系统调用很多地方继承了Unix的系统调用（但不是全部），但Linux相比传统Unix的系统调用做了很多扬弃，它省去了许多Unix系统冗余的系统调用，仅仅保留了最基本和最有用的系统调用，所以Linux全部系统调用只有400个左右（而有些操作系统系统调用多达1000个以上）。 这些系统调用按照功能逻辑大致可分为“进程控制”、“文件系统控制”、“系统控制”、“存储管理”、“网络管理”、“socket控制”、“用户管理”、“进程间通信”等几类，详细情况可参阅文章系统调用列表 如果你想详细看看系统调用的说明，可以使用man 2 syscalls 命令查看，或干脆到 <内核源码目录>/include/asm-i386/unistd.h源文件中找到它们的源本。 熟练了解和掌握上面这些系统调用是对系统程序员的必备要求，但对于一个开发内核的人员或内核开发者来[1]说，死记硬背下这些调用还远远不够。如果你仅仅知道存在的调用而不知道为什么它们会存在，或只知道如何使用调用而不知道这些调用在系统中的主要用途，那么你离驾驭系统还有不小距离。 要弥补这个鸿沟，第一，你必须明白系统调用在内核里的主要用途。虽然上面给出了数种分类，不过，总的概括来讲，系统调用在系统中的主要用途无非以下几类： l 控制硬件——系统调用往往作为硬件资源和用户空间的抽象接口，比如读写文件时用到的write/read调用。 l 设置系统状态或读取内核数据——因为系统调用是用户空间和内核的唯一通讯手段[2]，所以用户设置系统状态，比如开/关某项内核服务（设置某个内核变量），或读取内核数据都必须通过系统调用。比如getpgid、getpriority、setpriority、sethostname
理解上述道理对掌握系统调用的本质意义很大，希望网友们能从使用中多总结，多思考。 3.系统调用、用户编程接口（API）、系统命令和内核函数的关系系统调用并非直接和程序员或系统管理员打交道，它仅仅是一个通过软中断机制（我们后面讲述）向内核提交请求，获取内核服务的接口。而在实际使用中程序员调用的多是用户编程接口——API，而管理员使用的则多是系统命令。 用户编程接口其实是一个函数定义，说明了如何获得一个给定的服务，比如read()、malloc()、free（）、abs()等。它有可能和系统调用形式上一致，比如read()接口就和read系统调用对应，但这种对应并非一一对应，往往会出现几种不同的API内部用到同一个系统调用，比如malloc()、free（）内部利用brk( )系统调用来扩大或缩小进程的堆；或一个API利用了好几个系统调用组合完成服务。更有些API甚至不需要任何系统调用——因为它并不是必需要使用内核服务，如计算整数绝对值的abs（）接口。 另外要补充的是Linux的用户编程接口遵循了在Unix世界中最流行的应用编程界面标准——POSIX标准，这套标准定义了一系列API。在Linux中（Unix也如此），这些API主要是通过C库（libc）实现的，它除了定义的一些标准的C函数外，一个很重要的任务就是提供了一套封装例程（wrapper routine）将系统调用在用户空间包装后供用户编程使用。 不过封装并非必须的，如果你愿意直接调用，Linux内核也提供了一个syscall()函数来实现调用，我们看个例子来对比一下通过C库调用和直接调用的区别。 #include<syscall.h>#include<unistd.h>#include<stdio.h>#include<sys/types.h>intmain(void){long ID1, ID2;/*-----------------------------*//* 直接系统调用*//* SYS_getpid (func no. is 20) *//*-----------------------------*/ID1 = syscall(SYS_getpid);printf ("syscall(SYS_getpid)=%ld\n", ID1);/*-----------------------------*//* 使用"libc"封装的系统调用 *//* SYS_getpid (Func No. is 20) *//*-----------------------------*/ID2 = getpid();printf ("getpid()=%ld\n", ID2);return(0);}系统命令相对编程接口更高了一层，它是内部引用API的可执行程序，比如我们常用的系统命令ls、hostname等。Linux的系统命令格式遵循系统V的传统，多数放在/bin和/sbin下（相关内容可看看shell等章节）。 有兴趣的话，可以通过strace ls或strace hostname 命令查看一下它们用到的系统调用，你会发现诸如open、brk、fstat、ioctl 等系统调用被用在系统命令中。 下一个需要解释一下的问题是内核函数和系统调用的关系。大家不要把内核函数想像的过于复杂，其实它们和普通函数很像，只不过在内核实现，因此要满足一些内核编程的要求[3]。系统调用是一层用户进入内核的接口，它本身并非内核函数，进入内核后，不同的系统调用会找到对应到各自的内核函数——换个专业说法就叫：系统调用服务例程。实际上针对请求提供服务的是内核函数而非调用接口。 比如系统调用 getpid实际上就是调用内核函数sys_getpid。 asmlinkage longsys_getpid(void){return current->tpid;}Linux系统中存在许多内核函数，有些是内核文件中自己使用的，有些则是可以export出来供内核其他部分共同使用的，具体情况自己决定。 内核公开的内核函数——export出来的——可以使用命令ksyms 或 cat /proc/ksyms来查看。另外，网上还有一本归纳分类内核函数的书叫作《The Linux Kernel API Book》，有兴趣的读者可以去看看。 总而言之，从用户角度向内核看，依次是系统命令、编程接口、系统调用和内核函数。在讲述了系统调用实现后，我们会回过头来看看整个执行路径。 [1] 我们说的开发内核人员指开发系统内核，比如开发驱动模块机制、开发系统调用机制；而内核开发者则是指在内核基础之上进行的开发，比如驱动开发、系统调用开发、文件系统开发、网络通讯协议开发等。我们杂志所关注的问题主要在内核开发层次，即利用内核提供的机制进行开发。 [2] 对Linux而言，系统调用是用户程序访问内核的唯一手段，无论是/proc方式或设备文件方式归根到底都是利用系统调用完成的。 [3] 内核编程相比用户程序编程有一些特点，简单地讲，内核程序一般不能引用C库函数（除非你自己实现了，比如内核实现了不少C库种的String操作函数）；缺少内存保护措施；堆栈有限（因此调用嵌套不能过多）；而且由于调度关系，必须考虑内核执行路径的连续性，不能有长睡眠等行为。  ---------------------------------------------------------------------------------------------------------------------- 我们尊重原创，也注重分享，文章来源于微信公众号：老胡传道，建议关注公众号查看原文。如若侵权请联系qter@qter.org。 ---------------------------------------------------------------------------------------------------------------------- |
Copyright © 2001-2019 Comsenz Inc. Powered by Discuz! X3.4 ICP证: 冀ICP备10016221号-2
