用户级程序主动发起的信息交互:

从网上搜到点东西,贴上来看看有没有帮助.
用户级程序主动发起的信息交互:
A编写自己的系统调用
从前文可以看出，系统调用是用户级程序访问内核最基本的方法。目前linux大致提供了二百多个标准的系统调用（参见内核代码树中的include/ asm-i386/unistd.h和arch/i386/kernel/entry.S文件），并且允许我们添加自己的系统调用来实现和内核的信息交换。比如我们希望建立一个系统调用日志系统，将所有的系统调用动作记录下来，以便进行入侵检测。此时，我们可以编写一个内核服务程序。该程序负责收集所有的系统调用请求，并将这些调用信息记录到在内核中自建的缓冲里。我们无法在内核里实现复杂的入侵检测程序，因此必须将该缓冲里的记录提取到用户空间。最直截了当的方法是自己编写一个新系统调用实现这种提取缓冲数据的功能。当内核服务程序和新系统调用都实现后，我们就可以在用户空间里编写用户程序进行入侵检测任务了，入侵检测程序可以定时、轮训或在需要的时候调用新系统调用从内核提取数据，然后进行入侵检测了。

B编写驱动程序
Linux/UNIX的一个特点就是把所有的东西都看作是文件(every thing is a file)。系统定义了简洁完善的驱动程序界面，客户程序可以用统一的方法透过这个界面和内核驱动程序交互。而大部分系统的使用者和开发者已经非常熟悉这种界面以及相应的开发流程了。驱动程序运行于内核空间，用户空间的应用程序通过文件系统中/dev/目录下的一个文件来和它交互。这就是我们熟悉的那个文件操作流程：open() —— read() —— write() —— ioctl() —— close()。（需要注意的是也不是所有的内核驱动程序都是这个界面，网络驱动程序和各种协议栈的使用就不大一致，比如说套接口编程虽然也有open()close()等概念，但它的内核实现以及外部使用方式都和普通驱动程序有很大差异。）
设备驱动程序在内核中要做的中断响应、设备管理、数据处理等等各种工作这篇文章不去关心，我们把注意力集中在它与用户级程序交互这一部分。操作系统为此定义了一种统一的交互界面，就是前面所说的open(), read(), write(), ioctl()和close()等等。每个驱动程序按照自己的需要做独立实现，把自己提供的功能和服务隐藏在这个统一界面下。客户级程序选择需要的驱动程序或服务（其实就是选择/dev/目录下的文件），按照上述界面和文件操作流程，就可以跟内核中的驱动交互了。其实用面向对象的概念会更容易解释，系统定义了一个抽象的界面（abstract interface），每个具体的驱动程序都是这个界面的实现（implementation）。所以驱动程序也是用户空间和内核信息交互的重要方式之一。其实ioctl, read, write本质上讲也是通过系统调用去完成的，只是这些调用已被内核进行了标准封装，统一定义。因此用户不必向填加新系统调用那样必须修改内核代码，重新编译新内核，使用虚拟设备只需要通过模块方法将新的虚拟设备安装到内核中（insmod上）就能方便使用。
在/dev/目录下建立一个设备文件对应我们新加入内核的系统调用日志系统驱动程序。

C: 使用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系统调用的使用情况等。

D: 使用虚拟文件系统
有些内核开发者认为利用ioctl（）系统调用往往会似的系统调用意义不明确，而且难控制。而将信息放入到proc文件系统中会使信息组织混乱，因此也不赞成过多使用。他们建议实现一种孤立的虚拟文件系统来代替ioctl()和/proc，因为文件系统接口清楚，而且便于用户空间访问，同时利用虚拟文件系统使得利用脚本执行系统管理任务更家方便、有效。 

E: 使用内存映像
Linux通过内存映像机制来提供用户程序对内存直接访问的能力。内存映像的意思是把内核中特定部分的内存空间映射到用户级程序的内存空间去。也就是说，用户空间和内核空间共享一块相同的内存。这样做的直观效果显而易见：内核在这块地址内存储变更的任何数据，用户可以立即发现和使用，根本无须数据拷贝。而在使用系统调用交互信息时，在整个操作过程中必须有一步数据拷贝的工作——或者是把内核数据拷贝到用户缓冲区，或只是把用户数据拷贝到内核缓冲区——这对于许多数据传输量大、时间要求高的应用，这无疑是致命的一击：许多应用根本就无法忍受数据拷贝所耗费的时间和资源。
前面介绍的交互方法最大的不同在于这些方式是由内核采取主动，而不是等系统调用来被动的返回信息的。

A 从内核空间调用用户程序。
即使在内核中，我们有时也需要执行一些在用户级才提供的操作：如打开某个文件以读取特定数据，执行某个用户程序从而完成某个功能。因为许多数据和功能在用户空间是现有的或者已经被实现了，那么没有必要耗费大量的资源去重复。此外，内核在设计时，为了拥有更好的弹性或者性能以支持未知但有可能发生的变化，本身就要求使用用户空间的资源来配合完成任务。比如内核中动态加载模块的部分需要调用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", "ATH=/sbin:/usr/sbin:/bin:/usr/bin", NULL }。
从内核中打开文件同样使用带参数的open系统调用，所需的仍是要先调用set_fs宏。 

B 利用brk系统调用来导出内核数据
内核和用户空间传递数据主要是用get_user(ptr)和put_user(datum,ptr)例程。所以在大部分需要传递数据的系统调用中都可以找到它们的身影。可是，如果我们不是通过用户程序发起的系统调用——也就是说，没有明确的提供用户空间内的缓冲区位置——的情况下，如何向用户空间传递内核数据呢？显然，我们不能再直接使用put_user()了，因为我们没有办法给它指定目的缓冲区。所以，我们要借用brk系统调用和当前进程空间：brk用于给进程设置堆空间的大小。每个进程拥有一个独立的堆空间，malloc等动态内存分配函数其实就是进程的堆空间中获取内存的。我们将利用brk在当前进程(current process)的堆空间上扩展一块新的临时缓冲区，再用put_user将内核数据导出到这个确定的用户空间去。

C: 使用信号：
信号在内核里的用途主要集中在通知用户程序出现重大错误，强行杀死当前进程，这时内核通过发送SIGKILL信号通知进程终止，内核发送信号使用send_sign(pid,sig)例程，可以看到信号发送必须要事先知道进程序号（pid），所以要想从内核中通过发信号的方式异步通知用户进程执
行某项任务，那么必须事先知道用户进程的进程号才可。而内核运行时搜索到特定进程的进程号是个费事的工作，可能要遍历整个进程控制块链表。所以用信号通知特定用户进程的方法很糟糕，一般在内核不会使用。

（1）：
http://www.ibm.com/developerworks/cn/linux/l-kerns-usrs/
在 Linux 下用户空间与内核空间数据交换的方式，第 1 部分: 内核启动参数、模块参数与sysfs、sysctl、系统调用和netlink
（2）：
http://www.ibm.com/developerworks/cn/linux/l-kerns-usrs2/
在 Linux 下用户空间与内核空间数据交换的方式，第 2 部分: procfs、seq_file、debugfs和relayfs