原文：https://blog.csdn.net/iteye_8551/article/details/82269188 文章作者： 康华：计算机硕士，主要从事Linux操作系统内核、Linux技术标准、计算机安全、软件测试等领域的研究与开发工作。
摘要：在进行设备驱动程序，内核功能模块等系统级开发时，通常需要在内核和用户程序之间交换信息。Linux提供了多种方法可以用来完成这些任务。本文总结了各种常用的信息交换方法，并用简单的例子演示这些方法各自的特点及用法。其中有大家非常熟悉的方法，也有特殊条件下方可使用的手段。通过对比明确这些方法，可以加深我们对Linux内核的认识，更重要的是，可以让我们更熟练驾御linux内核级的应用开发技术。 内核空间(kernel-space) VS 用户空间(user-space) 作为一个Linux开发者，首先应该清楚内核空间和用户空间的区别。关于这个话题，已经有很多相关资料，我们在这里简单描述如下： 现代的计算机体系结构中存储管理通常都包含保护机制。提供保护的目的，是要避免系统中的一个任务访问属于另外的或属于操作系统的存储区域。如在IntelX86体系中，就提供了特权级这种保护机制，通过特权级别的区别来限制对存储区域的访问。 基于这种构架，Linux操作系统对自身进行了划分：一部分核心软件独立于普通应用程序，运行在较高的特权级别上，（Linux使用Intel体系的特权级3来运行内核。）它们驻留在被保护的内存空间上，拥有访问硬件设备的所有权限，Linux将此称为内核空间。 相对的，其它部分被作为应用程序在用户空间执行。它们只能看到允许它们使用的部分系统资源，并且不能使用某些特定的系统功能，不能直接访问硬件，不能直接访问内核空间，当然还有其他一些具体的使用限制。（Linux使用Intel体系的特权级0来运行用户程序。） 从安全角度讲将用户空间和内核空间置于这种非对称访问机制下是很有效的，它能抵御恶意用户的窥探，也能防止质量低劣的用户程序的侵害，从而使系统运行得更稳定可靠。但是，如果像这样完全不允许用户程序访问和使用内核空间的资源，那么我们的系统就无法提供任何有意义的功能了。为了方便用户程序使用在内核空间才能完全控制的资源，而又不违反上述的特权规定，从硬件体系结构本身到操作系统，都定义了标准的访问界面。（关于X86系统的细节，请查阅参考资料1）
一般的硬件体系机构都提供一种“门”机制。“门”的含义是指在发生了特定事件的时候低特权的应用程序可以通过这些“门”进入高特权的内核空间。对于IntelX86体系来说，Linux操作系统正是利用了“系统门”这个硬件界面（通过调用int $0x80机器指令)，构造了形形色色的系统调用作为软件界面，为应用程序从用户态陷入到内核态提供了通道。通过“系统调用”使用“系统门”并不需要特别的权限，但陷入到内核的具体位置却不是随意的，这个位置由“系统调用”来指定，有这样的限制才能保证内核安全无虞。我们可以形象地描述这种机制：作为一个游客，你可以买票要求进入野生动物园，但你必须老老实实的坐在观光车上，按照规定的路线观光游览。当然，不准下车，因为那样太危险，不是让你丢掉小命，就是让你吓坏了野生动物。 出于效率和代码大小的考虑，内核程序不能使用标准库函数（当然还有其它的顾虑，详细原因请查阅参考资料2）因此内核开发不如用户程序开发那么方便。而且由于目前（linux2.6还没正式发布）的内核是“非抢占”的，因此正在内核空间运行的进程是不会被其他进程取代的（除非该进程主动放弃CPU的控制，比如调用sleep(),schedule()等），所以无论是在进程上下文中（比如正在运行read系统调用），还是在中断上下文(正在中断服务程序中)，内核程序都不能长时间占用CPU，否则其它程序将无法执行，只能等待。 内核空间和用户空间的相互作用 现在，越来越多的应用程序需要编写内核级和用户级的程序来一起完成具体的任务，通常采用以下模式：首先，编写内核服务程序利用内核空间提供的权限和服务来接收、处理和缓存数据；然后编写用户程序来和先前完成的内核服务程序交互，具体来说，可以利用用户程序来配置内核服务程序的参数，提取内核服务程序提供的数据，当然，也可以向内核服务程序输入待处理数据。 比较典型的应用包括: Netfilter(内核服务程序：防火墙)VS Iptable（用户级程序：规则设置程序）；IPSEC(内核服务程序：VPN协议部分)VS IKE(用户级程序：vpn密钥协商处理)；当然还包括大量的设备驱动程序及相应的应用软件。这些应用都是由内核级和用户级程序通过相互交换信息来一起完成特定任务的。 信息交互方法 用户程序和内核的信息交换是双向的，也就是说既可以主动从用户空间向内核空间发送信息，也可以从内核空间向用户空间提交数据。当然，用户程序也可以主动地从内核提取数据。下面我们就针对内核和用户交互数据的方法做一总结、归纳。
信息交互按信息传输发起方可以分为用户向内核传送/提取数据和内核向用户空间提交请求两大类 先来说说： 由用户级程序主动发起的信息交互。 用户级程序主动发起的信息交互：
编写自己的系统调用 从前文可以看出，系统调用是用户级程序访问内核最基本的方法。目前linux大致提供了二百多个标准的系统调用（参见内核代码树中的include/ asm-i386/unistd.h和arch/i386/kernel/entry.S文件），并且允许我们添加自己的系统调用来实现和内核的信息交换。比如我们希望建立一个系统调用日志系统，将所有的系统调用动作记录下来，以便进行入侵检测。此时，我们可以编写一个内核服务程序。该程序负责收集所有的系统调用请求，并将这些调用信息记录到在内核中自建的缓冲里。我们无法在内核里实现复杂的入侵检测程序，因此必须将该缓冲里的记录提取到用户空间。最直截了当的方法是自己编写一个新系统调用实现这种提取缓冲数据的功能。当内核服务程序和新系统调用都实现后，我们就可以在用户空间里编写用户程序进行入侵检测任务了，入侵检测程序可以定时、轮训或在需要的时候调用新系统调用从内核提取数据，然后进行入侵检测了。
编写驱动程序 Linux/UNIX的一个特点就是把所有的东西都看作是文件(every thing is a file)。系统定义了简洁完善的驱动程序界面，客户程序可以用统一的方法透过这个界面和内核驱动程序交互。而大部分系统的使用者和开发者已经非常熟悉这种界面以及相应的开发流程了。 驱动程序运行于内核空间，用户空间的应用程序通过文件系统中/dev/目录下的一个文件来和它交互。这就是我们熟悉的那个文件操作流程：open() ―― read() ―― write() ―― ioctl() ―― close()。（需要注意的是也不是所有的内核驱动程序都是这个界面，网络驱动程序和各种协议栈的使用就不大一致，比如说套接口编程虽然也有open()close()等概念，但它的内核实现以及外部使用方式都和普通驱动程序有很大差异。）（关于这部分的编程细节，请查阅参考资料3、4）。 设备驱动程序在内核中要做的中断响应、设备管理、数据处理等等各种工作这篇文章不去关心，我们把注意力集中在它与用户级程序交互这一部分。操作系统为此定义了一种统一的交互界面，就是前面所说的open(), read(), write(), ioctl()和close()等等。每个驱动程序按照自己的需要做独立实现，把自己提供的功能和服务隐藏在这个统一界面下。客户级程序选择需要的驱动程序或服务（其实就是选择/dev/目录下的文件），按照上述界面和文件操作流程，就可以跟内核中的驱动交互了。其实用面向对象的概念会更容易解释，系统定义了一个抽象的界面（abstract interface），每个具体的驱动程序都是这个界面的实现（implementation）。 所以驱动程序也是用户空间和内核信息交互的重要方式之一。其实ioctl, read, write本质上讲也是通过系统调用去完成的，只是这些调用已被内核进行了标准封装，统一定义。因此用户不必向填加新系统调用那样必须修改内核代码，重新编译新内核，使用虚拟设备只需要通过模块方法将新的虚拟设备安装到内核中（insmod上）就能方便使用。（关于此方面设计细节请查阅参考资料5，编程细节请查阅参考资料6）。 在linux中，设备大致可分为：字符设备，块设备，和网络接口（字符设备包括那些必须以顺序方式，像字节流一样被访问的设备；如字符终端，串口等。块设备是指那些可以用随机方式，以整块数据为单位来访问的设备，如硬盘等；网络接口，就指通常网卡和协议栈等复杂的网络输入输出服务）。如果将我们的系统调用日志系统用字符型驱动程序的方式实现，也是一件轻松惬意地工作。我们可以将内核中收集和记录信息的那一部分编写成一个字符设备驱动程序。虽然没有实际对应的物理设备，但这并没什么问题：Linux的设备驱动程序本来就是一个软件抽象，它可以结合硬件提供服务，也完全可以作为纯软件提供服务（当然，内存的使用我们是无法避免的）。在驱动程序中，我们可以用open来启动服务，用read()返回处理好的记录，用ioctl()设置记录格式等，用close()停止服务，write()没有用到，那么我们可以不去实现它。然后在/dev/目录下建立一个设备文件对应我们新加入内核的系统调用日志系统驱动程序。
使用proc 文件系统 proc是Linux提供的一种特殊的文件系统，推出它的目的就是提供一种便捷的用户和内核间的交互方式。它以文件系统作为使用界面，使应用程序可以以文件操作的方式安全、方便的获取系统当前运行的状态和其它一些内核数据信息。 proc文件系统多用于监视、管理和调试系统，我们使用的很多管理工具如ps,top等，都是利用proc来读取内核信息的。除了读取内核信息，proc文件系统还提供了写入功能。所以我们也就可以利用它来向内核输入信息。比如，通过修改proc文件系统下的系统参数配置文件（/proc/sys），我们可以直接在运行时动态更改内核参数；再如，通过下面这条指令：echo 1 > /proc/sys/net/ip_v4/ip_forward开启内核中控制IP转发的开关，我们就可以让运行中的Linux系统启用路由功能。类似的，还有许多内核选项可以直接通过proc文件系统进行查询和调整。 除了系统已经提供的文件条目，proc还为我们留有接口，允许我们在内核中创建新的条目从而与用户程序共享信息数据。比如，我们可以为系统调用日志程序（不管是作为驱动程序也好，还是作为单纯的内核模块也好）在proc文件系统中创建新的文件条目，在此条目中显示系统调用的使用次数，每个单独系统调用的使用频率等等。我们也可以增加另外的条目，用于设置日志记录规则，比如说不记录open系统调用的使用情况等。关于proc文件系统得使用细节，（请查阅参考资料7）。
使用虚拟文件系统 有些内核开发者认为利用ioctl（）系统调用往往会使得系统调用意义不明确，而且难控制。而将信息放入到proc文件系统中会使信息组织混乱，因此也不赞成过多使用。他们建议实现一种孤立的虚拟文件系统来代替ioctl()和/proc，因为文件系统接口清楚，而且便于用户空间访问，同时利用虚拟文件系统使得利用脚本执行系统管理任务更家方便、有效。 我们举例来说如何通过虚拟文件系统修改内核信息。我们可以实现一个名为sagafs的虚拟文件系统，其中文件log对应内核存储的系统调用日志。我们可以通过文件访问特普遍方法获得日志信息：如 # cat /sagafs/log 使用虚拟文件系统――VFS实现信息交互使得系统管理更加方便、清晰。但有些编程者也许会说VFS 的API 接口复杂不容易掌握，不要担心2.5内核开始就提供了一种叫做libfs的例程序帮助不熟悉文件系统的用户封装了实现VFS的通用操作。有关利用VFS实现交互的方法看参考资料。
使用内存映像 Linux通过内存映像机制来提供用户程序对内存直接访问的能力。内存映像的意思是把内核中特定部分的内存空间映射到用户级程序的内存空间去。也就是说，用户空间和内核空间共享一块相同的内存。这样做的直观效果显而易见：内核在这块地址内存储变更的任何数据，用户可以立即发现和使用，根本无须数据拷贝。而在使用系统调用交互信息时，在整个操作过程中必须有一步数据拷贝的工作――或者是把内核数据拷贝到用户缓冲区，或只是把用户数据拷贝到内核缓冲区――这对于许多数据传输量大、时间要求高的应用，这无疑是致命的一击：许多应用根本就无法忍受数据拷贝所耗费的时间和资源。 我们曾经为一块高速采样设备开发过驱动程序，该设备要求在20兆采样率下以1KHz的重复频率进行16位实时采样，每毫秒需要采样、DMA和处理的数据量惊人，如果要使用数据拷贝的方法，根本无法达成要求。此时，内存映像成为唯一的选择：我们在内存中保留了一块空间，将其配置成环形队列供采样设备DMA输出数据。再把这块内存空间映射到在用户空间运行的数据处理程序上，于是，采样设备刚刚得到并传送到主机上的数据，马上就可以被用户空间的程序处理。 实际上，内存影射方式通常也正是应用在那些内核和用户空间需要快速大量交互数据的情况下，特别是那些对实时性要求较强的应用。X window系统的服务器的虚拟内存区域，就可以被看做是内存映像用法的一个典型例子：X服务器需要对视频内存进行大量的数据交换，相对于lseek/write来说，将图形显示内存直接影射到用户空间可以显著提高效能。 并不是任何类型的应用都适合mmap，比如像串口和鼠标这些基于流数据的字符设备，mmap就没有太大的用武之地。并且，这种共享内存的方式存在不好同步的问题。由于没有专门的同步机制可以让用户程序和内核程序共享，所以在读取和写入数据时要有非常谨慎的设计以保证不会产生干绕。 mmap完全是基于共享内存的观念了，也正因为此，它能提供额外的便利，但也特别难以控制。
由内核主动发起的信息交互 在内核发起的交互中，我们最关心和感兴趣的应该是内核如何向用户程序发消息，用户程序又是怎样接收这些消息的，具体问题通常集中在下面这几个方面：内核可否调用用户程序？是否可以通过向用户进程发信号来告知用户进程事件发生？ 与前面介绍的交互方法最大的不同在于这些方式是由内核采取主动，而不是等系统调用来被动的返回信息的。
从内核空间调用用户程序 即使在内核中，我们有时也需要执行一些在用户级才提供的操作：如打开某个文件以读取特定数据，执行某个用户程序从而完成某个功能。因为许多数据和功能在用户空间是现有的或者已经被实现了，那么没有必要耗费大量的资源去重复。此外，内核在设计时，为了拥有更好的弹性或者性能以支持未知但有可能发生的变化，本身就要求使用用户空间的资源来配合完成任务。比如内核中动态加载模块的部分需要调用kmod。但在编译kmod的时候不可能把所有的内核模块都订下来（要是这样的话动态加载模块就没有存在意义了），所以它不可能知道在它以后才出现的那些模块的位置和加载方法。因此，模块的动态加载就采用了如下策略：加载任务实际上由位于用户空间的modprobe程序帮助完成――最简单的情形是modprobe用内核传过来的模块名字作为参数调用insmod。用这种方法来加载所需要的模块。 内核中启动用户程序还是要通过execve这个系统调用原形，只是此时的调用发生在内核空间，而一般的系统调用则在用户空间进行。如果系统调用带参数，那将会碰到一个问题：因为在系统调用的具体实现代码中要检查参数合法性，该检查要求所有的参数必须位于用户空间――地址处于0x0000000――0xC0000000之间，所以如果我们从内核传递参数（地址大于0xC0000000）,那么检查就会拒绝我们的调用请求。为了解决这个问题，我们可以利用set_fs宏来修改检查策略，使得允许参数地址为内核地址。这样内核就可以直接使用该系统调用了。 例如：在kmod通过调用execve来执行modprobe的代码前需要有。 set_fs(KERNEL_DS): ...... set_fs(KERNEL_DS); /* Go, go, go... */ if (execve(program_path, argv, envp) 0) return -errno; 上述代码中program_path 为"/sbin/modprobe"， argv为{ modprobe_path, "-s", "-k", "--", (char*)module_name, NULL }， envp为{ "HOME=/", "TERM=linux", "PATH=/sbin:/usr/sbin:/bin:/usr/bin", NULL }从内核中打开文件同样使用带参数的open系统调用，所需的仍是要先调用set_fs宏。
利用brk系统调用来导出内核数据 内核和用户空间传递数据主要是用get_user(ptr)和put_user(datum,ptr)例程。所以在大部分需要传递数据的系统调用中都可以找到它们的身影。可是，如果我们不是通过用户程序发起的系统调用――也就是说，没有明确的提供用户空间内的缓冲区位置――的情况下，如何向用户空间传递内核数据呢？ 显然，我们不能再直接使用put_user()了，因为我们没有办法给它指定目的缓冲区。所以，我们要借用brk系统调用和当前进程空间：brk用于给进程设置堆空间的大小。每个进程拥有一个独立的堆空间，malloc等动态内存分配函数其实就是进程的堆空间中获取内存的。我们将利用brk在当前进程(current process)的堆空间上扩展一块新的临时缓冲区，再用put_user将内核数据导出到这个确定的用户空间去。 还记得刚才我们在内核中调用用户程序的过程吗？在那里，我们有一个跳过参数检查的操作，现在有了这种方法，可以另辟蹊径了：我们在当前进程的堆上扩展一块空间，把系统调用要用到的参数通过put_user()拷贝到新扩展得到的用户空间里，然后在调用execve的时候以这个新开辟空间地址作为参数，于是，参数检查的障碍不复存在了。 char * program_path = "/bin/ls" ; /* 找到当前堆顶的位置*/ mmm=current->mm->brk; /* 用brk在堆顶上原扩展出一块256字节的新缓冲区*/ ret = brk(*(void)(mmm+256)); /* 把execve需要用到的参数拷贝到新缓冲区上去*/ put_user((void*)2,program_path,strlen(program_path )+1); /* 成功执行/bin/ls程序！*/ execve((char*)(mmm+2)); /* 恢复现场*/ tmp = brk((void*)mmm);这种方法没有一般性（具体的说，这种方法有负面效应吗），只能作为一种技巧，但我们不难发现：如果你熟悉内核结构，就可以做到很多意想不到的事情！
使用信号 信号在内核里的用途主要集中在通知用户程序出现重大错误，强行杀死当前进程，这时内核通过发送SIGKILL信号通知进程终止，内核发送信号使用send_sign(pid,sig)例程，可以看到信号发送必须要事先知道进程序号（pid），所以要想从内核中通过发信号的方式异步通知用户进程执行某项任务，那么必须事先知道用户进程的进程号才可。而内核运行时搜索到特定进程的进程号是个费事的工作，可能要遍历整个进程控制块链表。所以用信号通知特定用户进程的方法很糟糕，一般在内核不会使用。内核中使用信号的情形只出现在通知当前进程（可以从current变量中方便获得pid）做某些通用操作，如终止操作等。因此对内核开发者该方法用处不大。类似情况还有消息操作。这里不罗嗦了。 总结 由用户级程序主动发起的信息交互，无论是采用标准的调用方式还是透过驱动程序界面，一般都要用到系统调用。而由内核主动发起信息交互的情况不多。也没有标准的界面，操作大不方便。所以一般情况下，尽可能用本文描述的前几种方法进行信息交互。毕竟，在设计的根源上，相对于客户级程序，内核就被定义为一个被动的服务提供者。因此，我们自己的开发也应该尽量遵循这种设计原则。
参考资料
周明德，保护方式下的80386及其编程，清华大学出版社，1993Robert Love, Linux Kernel Development，Sams Publishing，2003W.Richard Stevens, Advanced Programming in the UNIX Environment，Addision Wesley,1992W.Richard Stevens, UNIX Network Programming, Prentic Hall, 1998Maurice J. Bach, The Design of the UNIX Operating System, Prentic Hall, 1990Linux Device Driver, O’ReillyOri Pomerantz ,Linux Kernel Module Programming Guide, 1999