​ 在Linux中为了更好的保护内核空间 ，将程序的运行空间分为用户态和内核态。他们分别运行在不同的级别上，二者在逻辑上独立，物理上不独立。所以一般情况下应用程序是不可以直接使用内核函数或者访问内核数据，如果想用，那就必须使用**系统调用。**所以在Linux中系统调用是用户态访问内核态的唯一方式。

​ 系统调用就是用在程序中调用操作系统所提供的一些子功能，指操作系统提供给用户程序的一组“特殊”接口，用户程序可以通过这组“特殊”接口来获得操作系统内核提供的特殊服务。（即通过系统调用可以从用户态切换到内核态。）

​ 系统调用是用户进程进入内核的接口层，它本身并非内核函数，但它是由内核函数实现，进入内核后，不同的系统调用会找到各自对应的内核函数，这些内核函数被称为系统调用的“服务例程”。比如系统调用read实际调用了服务例程为sys_read(),或者说系统调用read是服务例程sys_read()的“封装例程”。

​ 具体步骤也就是：用户进程——>系统调用——>内核——>处理完返回用户态

系统调用是通过 软中断 的方式向内核提出请求，已获得内核服务和函数的接口。

​ API，是程序员在用户空间下可以直接使用的函数接口。是一些预定义的函数（函数定义），比如常用的read()、write()、malloc()、free()函数等，这些函数都具有一定功能，说明了如何获得一个给定的服务，跟内核没有必然的联系。提供应用程序与开发人员基于某软件或硬件的以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。

区别：API是函数的定义，规定了这个函数的功能，跟内核无直接关系。而系统调用是通过中断向内核发请求，实现内核提供的某些服务。

联系：程序员调用的是API（API函数），然后通过与系统调用共同完成函数的功能。因此，API是一个提供给应用程序的接口，一组函数，是与程序员进行直接交互的。系统调用则不与程序员进行交互的，它是根据API函数，通过一个软中断机制向内核提交请求，以获取内核服务的接口。而系统调用则不与程序员进行交互的，它是根据API函数，通过一个软中断机制向内核提交请求，以获取内核服务的接口。

有时候，某些API所提供的功能会涉及到与内核空间进行交互。那么，这类API内部会封装系统调用。而不涉及与内核进行交互的API则不会封装系统调用。也就是说，API和系统调用并没有严格的一一对应关系，一个API可能恰好只对应一个系统调用，比如read()系统调用和read API；一个API也可能由多个系统调用实现；有时候，一个API的功能可能并不需要内核提供的服务，那么此时这个API也就不需要任何的系统调用，比如abs()。另外，一个系统调用可能还被多个API内部调用。

这里说明一下：

我们一般把封装系统调用的API叫做系统调用；

把没有封装系统调用的API叫做API。

​ 对于程序员来说，系统调用和API都是一组函数，并无什么两样，二者关注的都是函数名、参数类型及返回值的含义；但是事实上，系统调用的实现是在内核完成的，API则是在函数库中实现的。

​ 例如: 在内核中实现了write系统调用。

​ 在库函数中通过宏定义的方式实现write 的API。可以在unistd.h中看到write到系统调用的转换。

最后基本是这个过程：

API——>封装例程——>系统调用——>系统调用处理程序——>服务例程——>处理完后返回用户态

系统命令>

​ 系统命令相对与API又高出一层，其实是一组可执行程序，它的内部引用了API来实现其相应的功能。在linux中普通用户可用的命令和管理可用的命令分别被存放于/bin和/sbin目录下。

内核函数>

​ 内核函数和用户空间中函数并无两样，只不过内核函数是在内核中实现。虽然系统调用是用户进程进入内核的唯一途径，但是系统调用函数内部并不真正实现其功能，而是通过对内核函数的封装。也就是说，用户程序通过某个系统调用进入内核后，会接着去执行这个系统调用对应的内核函数。这个内核函数也称为系统调用的服务例程。