系统调用是如何实现的？
这张图画了挺久的，主要是想让大家可以从全局角度，看下linux内核中系统调用的实现。
在讲具体的细节之前，我们先根据上图，从整体上看一下系统调用的实现。
系统调用的实现基础，其实就是两条汇编指令，分别是syscall和sysret。
syscall使执行逻辑从用户态切换到内核态，在进入到内核态之后，cpu会从 MSR_LSTAR 寄存器中，获取处理系统调用内核代码的起始地址，即上面的 entry_SYSCALL_64。
在执行 entry_SYSCALL_64 函数时，内核代码会根据约定，先从rax寄存器中获取想要执行的系统调用的编号，然后根据该编号从sys_call_table数组中找到对应的系统调用函数。
接着，从 rdi, rsi, rdx, r10, r8, r9 寄存器中获取该系统调用函数所需的参数，然后调用该函数，把这些参数传入其中。
在系统调用函数执行完毕之后，执行结果会被放到rax寄存器中。
最后，执行sysret汇编指令，从内核态切换回用户态，用户程序继续执行。
如果用户程序需要该系统调用的返回结果，则从rax中获取。
总体流程就是这样，相对来说，还是比较简单的，主要就是先去理解syscall和sysret这两条汇编指令，在理解这两条汇编指令的基础上，再去看内核源码，就会容易很多。
有关syscall和sysret指令的详细介绍，请参考Intel 64 and IA-32 Architectures Software Developer’s Manual。
有了上面对系统调用的整理理解，我们接下来看下其具体的实现细节。
以write系统调用为例，其对应的内核源码为：
在内核中，所有的系统调用函数都是通过 SYSCALL_DEFINE 等宏定义的，比如上面的write函数，使用的是 SYSCALL_DEFINE3。
将该宏展开后，我们可以得到如下的函数定义：
由上可见，SYSCALL_DEFINE3宏展开后为三个函数，其中只有__x64_sys_write是外部可访问的，其它两个都有被static修饰，不能被外部访问，所以注册到上文中提到的sys_call_table数组里的函数，应该就是这个函数。
那该函数是怎么注册到这个数组的呢？
我们先不说答案，先来看下sys_call_table数组的定义：
由上可见，该数组各元素的默认值都是 __x64_sys_ni_syscall：
该函数也非常简单，就是直接返回错误码-ENOSYS，表示系统调用非法。
sys_call_table数组定义的地方好像只设置了默认值，并没有设置真正的系统调用函数。
我们再看看其他地方，看是否有代码会注册真正的系统调用函数到sys_call_table数组里。
可惜，并没有。
这就奇怪了，那各系统调用函数到底是在哪里注册的呢？
我们再回头仔细看下sys_call_table数组的定义，它在设置完默认值之后，后面还include了一个名为asm/syscalls_64.h的头文件，这个位置include头文件还是比较奇怪的，我们看下它里面是什么内容。
但是，这个文件居然不存在。
那我们只能初步怀疑这个头文件是编译时生成的，带着这个疑问，我们去搜索相关内容，确实发现了一些线索：
这个文件确实是编译时生成的，上面的makefile中使用了syscalltbl.sh脚本和syscall_64.tbl模板文件来生成这个syscalls_64.h头文件。
我们来看下syscall_64.tbl模板文件的内容：
这里确实定义了write系统调用，且标明了它的编号是1。
我们再来看下生成的syscalls_64.h头文件：
这里面定义了很多好像宏调用一样的东西。
__SYSCALL_COMMON，这个不就是sys_call_table数组定义那里define的那个宏嘛。
再去上面看下__SYSCALL_COMMON这个宏定义，它的作用是将sym表示的函数赋值到sys_call_table数组的nr下标处。
所以对于__SYSCALL_COMMON(1, sys_write)来说，它就是注册__x64_sys_write函数到sys_call_table数组下标为1的槽位处。
而这个__x64_sys_write函数，正是我们上面猜测的，SYSCALL_DEFINE3定义的write系统调用，展开之后的一个外部可访问的函数。
这样就豁然开朗了，原来真正的系统调用函数的注册，是通过先定义__SYSCALL_COMMON宏，再include那个根据syscall_64.tbl模板生成的syscalls_64.h头文件来完成的，非常巧妙。
系统调用函数注册到sys_call_table数组的过程，到这里已经非常清楚了。
下面我们继续来看下哪里在使用这个数组：
do_syscall_64在使用，方式是先通过nr在sys_call_table数组中找到对应的系统调用函数，然后再调用该函数，将regs传入其中。
这个流程和我们上面预估的一样，且传入的regs参数类型，和我们上面注册的系统调用函数所需的类型也一样。
那也就是说，regs参数的字段里，是带着各系统调用函数所需的参数的，SYSCALL_DEFINE等宏展开出来的一系列函数，会从这些字段中提取出真正的参数，然后对其进行类型转换，最后这些参数被传入到最终的系统调用函数中。
对于上面的write系统调用宏展开后的那些函数，__x64_sys_write会先从regs中提取出di, si, dx字段作为真正参数，然后__se_sys_write会将这些参数转成正确的类型，最后__do_sys_write函数被调用，转换后的这些参数被传入其中。
在系统调用函数执行完毕后，其结果会被赋值到了regs的ax字段里。
由上可见，系统调用函数的参数及返回值的传递，都是通过regs来完成的。
但文章开始的时候不是说，系统调用的参数及返回值的传递，是通过寄存器来完成的吗，这里怎么是通过struct pt_regs的字段呢？
先别急，先来看下struct pt_regs的定义：
你有没有发现，这里面的字段名都是寄存器的名字。
那是不是说，在执行系统调用的代码里，有逻辑把各寄存器里的值放到了这个结构体的对应字段里，在结束系统调用时，这些字段里的值又被赋值到各个对应的寄存器里呢？
离真相越来越近。
我们继续看使用了do_syscall_64的地方：
上图中的entry_SYSCALL_64方法，就是系统调用流程中最重要的一个方法了，为了便于理解，我对该方法做了很多修改，并添加了很多注释。
这里需要注意的是100行到121行这段逻辑，它将各寄存器的值压入到栈中，以此来构建struct pt_regs对象。
这就能构建出一个struct pt_regs对象了？
是的。
我们回上面看下struct pt_regs的定义，看其字段名字及顺序是不是和这里的压栈顺序正好相反。
我们再想下，当我们要构建一个struct pt_regs对象时，我们要为其在内存中分配一块空间，然后用一个地址来指向这段空间，这个地址就是该struct pt_regs对象的指针，这里需要注意的是，这个指针里存放的地址，是这段内存空间的最小地址。
再看上面的压栈过程，每一次压栈操作我们都可以认为是在分配内存空间并赋值，当r15被最终压入到栈中后，整个内存空间分配完毕，且数据也初始化完毕，此时，rsp指向的栈顶地址，就是这段内存空间的最小地址，因为压栈过程中，栈顶的地址是一直在变小的。
综上可知，在压栈完毕后，rsp里的地址就是一个struct pt_regs对象的地址，即该对象的指针。
在构建完struct pt_regs对象后，123行将rax中存放的系统调用编号赋值到了rdx里，124行将rsp里存放的struct pt_regs对象的地址，即该对象的指针，赋值到了rsi中，接着后面执行了call指令，来调用do_syscall_64方法。
调用do_syscall_64方法之前，对rdi和rsi的赋值，是为了遵守c calling convention，因为在该calling convention中约定，在调用c方法时，第一个参数要放到rdi里，第二个参数要放到rsi里。
我们再去上面看下do_syscall_64方法的定义，参数类型及顺序是不是和我们这里说的是完全一样的。
在调用完do_syscall_64方法后，系统调用的整个流程基本上就快结束了，上图中的129行到133行做的都是一些寄存器恢复的工作，比如从栈中弹出对应的值到rax，rip，rsp等等。
这里需要注意的是，栈中rax的值是在上面do_syscall_64方法里设置的，其存放的是系统调用的最终结果。
另外，在栈中弹出的rip和rsp的值，分别是用户态程序的后续指令地址及其堆栈地址。
最后执行sysret，从内核态切换回用户态，继续执行syscall后面逻辑。
到这里，完整的系统调用处理流程就已经差不多说完了，不过这里还差一小步，就是syscall指令在进入到内核态之后，是如何找到entry_SYSCALL_64方法的：
它其实是注册到了MSR_LSTAR寄存器里了，syscall指令在进入到内核态之后，会直接从这个寄存器里拿系统调用处理函数的地址，并开始执行。
系统调用内核态的逻辑处理就是这些。
下面我们用一个例子来演示下用户态部分：
编译并执行：
我们用syscall来执行write系统调用，写的字符串为Hi ，syscall执行完毕后，我们直接使用ret指令将write的返回结果当作程序的退出码返回。
所以在上图中，输出了Hi，且程序的退出码是3。
如果对上面的汇编不太理解，可以把它想像成下面这个样子：
在这里，我们使用的是glibc中的write方法来执行该系统调用，其实该方法就是对syscall指令做的一层封装，本质上使用的还是我们上面的汇编代码。
这个例子到这里就结束了。
有没有觉得不太尽兴？
我们分析了这么多的代码，最终就用了这么个小例子就结束了，不行，我们要再做点什么。
要不我们来自己写个系统调用？
说干就干。
我们先在write系统调用下面定义一个我们自己的系统调用：
该方法很简单，就是将参数加10，然后返回。
再把这个系统调用在syscall_64.tbl里注册一下，编号为442：
编译内核，等待执行。
我们再把上面写的那个hi程序改下并编译好：
然后在虚拟机中启动新编译的linux内核，并执行上面的程序：
看结果，正好就是20。
搞定，收工。
原文标题：精致全景图 | 系统调用是如何实现的
文章出处：【微信公众号：Linuxer】欢迎添加关注！文章转载请注明出处。
责任编辑：haq
-
寄存器
+关注
关注
31文章
5336浏览量
120224 -
系统调用
+关注
关注
0文章
28浏览量
8324
原文标题：精致全景图 | 系统调用是如何实现的
文章出处：【微信号：LinuxDev，微信公众号：Linux阅码场】欢迎添加关注！文章转载请注明出处。
发布评论请先 登录
相关推荐
AIGC系统中多个模型的切换调用方案探索
HarmonyOS NEXT应用元服务开发Intents Kit（意图框架服务）技能调用方案概述
记一次JSF异步调用引起的接口可用率降低
如何手搓一个自定义的RPC 远程过程调用框架
人员定位系统的主要作用是什么？还有什么常用功能？
pi调节器的作用是什么
控制器的主要作用是指什么
ADS调用spectre网表仿真异常—薛定谔的NetlistInclude
verilog如何调用其他module
电源驱动ic的作用是什么 电源IC驱动电路设计图
工商网监
评论