如何调用Linux内核函数

注意看这个文件

sysdeps/unix/sysv/linux/syscalls.list

里面记录着系统调用的名字和一些属性，具体我也没有研究过，不懂。

再看select的实现，很让人惊讶，一旦使用，结果就是“报错“。

int

__select (nfds, readfds, writefds, exceptfds, timeout)

int nfds

fd_set *readfds

fd_set *writefds

fd_set *exceptfds

struct timeval *timeout

{

__set_errno (ENOSYS)

return -1

}

libc_hidden_def (__select)

stub_warning (select)

weak_alias (__select, select)

这是因为glibc并没有实现系统调用，而是调用系统调用，

更进一步，连调用系统调用都没有一个个实现，而是使用了通用的办法，

理由很简单，所有的系统调用在linux内核头文件里都能找到，

所有的系统调用参数类型就那么几种，参数个数也是有限的，

因此没有必要针对所有的系统调用一一封装，

于是就有了这个list文件，自动生成调用系统调用的函数，

如果生成失败，也就是你看到的“报错”。

符号是有强弱的，当自动生成成功的时候，“报错”的弱符号就被忽略了。

当你在glibc中找到一个系统调用的封装源码，是以下原因，

1. 编译的目标系统不支持这个系统调用，所以自己用另一种方式实现了。

2. 这个系统调用无法使用通用的自动生成方式生成，用特化的方式覆盖。

3. 针对这个系统调用做了特别的优化。

4. 其它可能的原因。

具体可以留意

SYSCALL, PSEUDO, DO_CALL, INLINE_CALL 等名字

这两个文件是重点所在

sysdeps/unix/i386/sysdep.h

sysdeps/unix/i386/sysdep.S

要搞清楚具体的自动生成过程，恐怕得研究glibc自身的编译过程了

看系统调用，还有库函数，以前一直不明白，总是以为 系统调用跟库函数是一样的，但是今天才知道是不一样的。

库函数也就是我们通常所说的应用编程接口API，它其实就是一个函数定义，比如常见read()、write()等函数说明了如何获得一个给定的服务，但是系统调用是通过软中断向内核发出一个明确的请求，再者系统调用是在内核完成的，而用户态的函数是在函数库完成的。

系统调用发生在内核空间，因此如果在用户空间的一般应用程序中使用系统调用来进行文件 *** 作，会有用户空间到内核空间切换的开销。事实上，即使在用户空间使用库函数来对文件进行 *** 作，因为文件总是存在于存储介质上，因此不管是读写 *** 作，都是对硬件（存储器）的 *** 作，都必然会引起系统调用。也就是说，库函数对文件的 *** 作实际上是通过系统调用来实现的。例如C库函数fwrite()就是通过write()系统调用来实现的。

这样的话，使用库函数也有系统调用的开销，为什么不直接使用系统调用呢？这是因为，读写文件通常是大量的数据（这种大量是相对于底层驱动的系统调用所实现的数据 *** 作单位而言），这时，使用库函数就可以大大减少系统调用的次数。这一结果又缘于缓冲区技术。在用户空间和内核空间，对文件 *** 作都使用了缓冲区，例如用fwrite写文件，都是先将内容写到用户空间缓冲区，当用户空间缓冲区满或者写 *** 作结束时，才将用户缓冲区的内容写到内核缓冲区，同样的道理，当内核缓冲区满或写结束时才将内核缓冲区内容写到文件对应的硬件媒介。

系统调用与系统命令：系统命令相对API更高一层，每个系统命令都是一个可执行程序，比如常用的系统命令ls、hostname等，比如strace ls就会发现他们调用了诸如open(),brk(),fstat(),ioctl()等系统调用。

系统调用是用户进程进入内核的接口层，它本身并非内核函数，但他是由内核函数实现的，进入系统内核后，不同的系统调用会找到各自对应的内核函数，这写内核函数被称为系统调用的“服务例程”。也可以说系统调用是服务例程的封装例程。

---