运输管理流程:名词解释--内核分页

进程能看得到的分页只有属于它自己的，所以当编写用户程序时，不用考虑分页的存在。 但是当你编写内核模块时，你就会访问由系统自动管理的内核所在的分页。 当一块内存缓冲区中的内容要在当前运行中的进程和内核之间传递时， 内核的函数就接收指向在进程分页中的该内存缓冲区的指针。宏put_user和 get_user允许你进行这样的访问内存的操作。

现在我们有两种从内核模块获得输出的方法：我们可以注册一个设备驱动并用 mknod生成一个设备文件，或者我们可以建立一个 /proc文件。这样内核就可以告诉我们重要的信息。 剩下的唯一问题是我们没法反馈信息。第一种方法是向/proc文件系统写入信息。

由于 /proc 文件系统是为内核输出其运行信息而设计的，它并未向内核输入信息提供了任何准备。 结构体struct proc_dir_entry并没有指向输入函数的指针，而是指向了一个输出函数。 作为替代办法，向/proc 写入信息，我们可以使用标准的文件系统提供的机制。

在Linux中有一种标准的注册文件系统的方法。既然每种文件系统都必须有处理文件 索引节点inode和文件本身的函数[1], 那么就一定有种结构体去存放这些函数的指针。这就是结构体struct inode_operations， 它其中又包含一个指向结构体struct file_operations的指针。在 /proc 文件系统中， 当我们需要注册一个新文件时，我们被允许选择哪一个struct inode_operations 结构体。这就是我们将使用的机制，用包含结构体 struct inode_operations指针的结构体struct file_operations 来指向我们的module_input和module_output函数。

需要注意的是“读”和“写”的含义在内核中是反过来的。“读”意味着输出，而“写”意味着输入。 这是从用户的角度来看待问题的。如果一个进程只能从内核的“输出”获得输入， 而内核也是从进程的输出中得到“输入”的。

在这儿另一件有趣的事就是module_permission函数了。该函数在每个进程想要对 /proc文件系统内的文件操作时被调用，它来决定是否操作被允许。 目前它只是对操作和操作所属用户的UID进行判断，但它可以也把其它的东西包括进来， 像还有哪些别的进程在对该文件进行操作，当前的时间，或是我们最后接收到的输入。

加入宏put_user和get_user的原因是 Linux的内存是使用分页机制的（在Intel架构下是如此，但其它架构下有可能不同）。 这就意味着指针自身并不是指向一个确实的物理内存地址，而知是分页中的一个地址， 而且你必须知道哪些分页将来是可用的。其中内核本身占用一个分页，其它的每个进程都有自己的分页。