我们不能使用if()来替代while()，因为可能有许多进程正等待数据。当write方法唤醒它们时，调度程序以不可预知的方式选择一个来运行，因此，在这段代码有机会执行的时候，缓冲区可能再次空出。现在，我们需要将数据从buf->data 复制到用户空间。copy_to_user()内核函数干了此事：
　　size = min(size， (size_t) (buf->end - buf->read_ptr));
　　if (copy_to_user(out， buf->read_ptr， size)) {
　　result = -EFAULT;
　　goto out;
　　}
　　如果用户空间指针错误，那么调用可能会失败；如果发生了此事，我们返回-EFAULT。记住，不要相信任何来自内核外的事物！
　　buf->read_ptr += size;
　　result = size;
　　out:
　　return result;
　　}
　　为了使数据在任意块可读，需要进行简单运算。该方法返回读入的字节数，或者一个错误代码。
　　写方法更简短。首先，我们检查缓冲区是否有足够的空间，然后我们使用copy_from_userspace()函数来获取数据。再然后read_ptr和结束指针会被重置，并且反转存储缓冲区内容：
　　buf->end = buf->data + size;
　　buf->read_ptr = buf->data;
　　if (buf->end > buf->data)
　　reverse_phrase(buf->data， buf->end - 1);
　　这里， reverse_phrase()干了所有吃力的工作。它依赖于reverse_word()函数，该函数相当简短并且标记为内联。这是另外一个常见的优化；但是，你不能过度使用。因为过多的内联会导致内核映像徒然增大。
　　后，我们需要唤醒read_queue中等待数据的进程，跟先前讲过的那样。wake_up_interruptible()是用来干此事的：
　　wake_up_interruptible(&buf->read_queue);
　　耶！你现在已经有了一个内核模块，它至少已经编译成功了。现在，是时候来测试了。
　　调试内核代码
　　或许，内核中常见的调试方法是打印。如果你愿意，你可以使用普通的printk() （假定使用KERN_DEBUG日志等级）。然而，那儿还有更好的办法。如果你正在写一个设备驱动，这个设备驱动有它自己的“struct device”，可以使用pr_debug()或者dev_dbg()：它们支持动态调试（dyndbg）特性，并可以根据需要启用或者禁用（请查阅Documentation/dynamic-debug-howto.txt）。对于单纯的开发消息，使用pr_devel()，除非设置了DEBUG，否则什么都不会做。要为我们的模块启用DEBUG，请添加以下行到Makefile中：
　　CFLAGS_reverse.o := -DDEBUG
　　完了之后，使用dmesg来查看pr_debug()或pr_devel()生成的调试信息。 或者，你可以直接发送调试信息到控制台。要想这么干，你可以设置console_loglevel内核变量为8或者更大的值（echo 8 /proc/sys/kernel/printk），或者在高日志等级，如KERN_ERR，来临时打印要查询的调试信息。很自然，在发布代码前，你应该移除这样的调试声明。
　　注意内核消息出现在控制台，不要在Xterm这样的终端模拟器窗口中去查看；这也是在内核开发时，建议你不在X环境下进行的原因。
　　惊喜，惊喜！
　　编译模块，然后加载进内核：
　　$ make
　　$ sudo insmod reverse.ko buffer_size=2048
　　$ lsmod
　　reverse 2419 0
　　$ ls -l /dev/reverse
　　crw-rw-rw- 1 root root 10， 58 Feb 22 15:53 /dev/reverse
　　一切似乎位。现在，要测试模块是否正常工作，我们将写一段小程序来翻转它的第一个命令行参数。main()（再三检查错误）可能看上去像这样：
　　int fd = open("/dev/reverse"， O_RDWR);
　　write(fd， argv[1]， strlen(argv[1]));
　　read(fd， argv[1]， strlen(argv[1]));
　　printf("Read: %s "， argv[1]);
　　像这样运行：
　　$ ./test 'A quick brown fox jumped over the lazy dog'
　　Read: dog lazy the over jumped fox brown quick A
　　它工作正常！玩得更逗一点：试试传递单个单词或者单个字母的短语，空的字符串或者是非英语字符串（如果你有这样的键盘布局设置），以及其它任何东西。
　　现在，让我们让事情变得更好玩一点。我们将创建两个进程，它们共享一个文件描述符（及其内核缓冲区）。其中一个会持续写入字符串到设备，而另一个将读取这些字符串。在下例中，我们使用了fork(2)系统调用，而pthreads也很好用。我也省略打开和关闭设备的代码，并在此检查代码错误（又来了）：
　　char *phrase = "A quick brown fox jumped over the lazy dog";
　　if (fork())
　　/* Parent is the writer */
　　while (1)
　　write(fd， phrase， len);
　　else
　　/* child is the reader */
　　while (1) {
　　read(fd， buf， len);
　　printf("Read: %s "， buf);
　　}
　　你希望这个程序会输出什么呢？下面是在我的笔记本上得到的东西：
　　Read: dog lazy the over jumped fox brown quick A
　　Read: A kcicq brown fox jumped over the lazy dog
　　Read: A kciuq nworb xor jumped fox brown quick A
　　Read: A kciuq nworb xor jumped fox brown quick A
　　...
　　这里发生了什么呢？像举行了一场比赛。我们认为read和write是原子操作，或者从头到尾一次执行一个指令。然而，内核确实无序并发的，随便重新调度了reverse_phrase()函数内部某个地方运行着的写入操作的内核部分。如果在写入操作结束前调度了read()操作呢？会产生数据不完整的状态。这样的bug非常难以找到。但是，怎样来处理这个问题呢？
　　基本上，我们需要确保在写方法返回前没有read方法能被执行。如果你曾经编写过一个多线程的应用程序，你可能见过同步原语（锁），如互斥锁或者信号。Linux也有这些，但有些细微的差别。内核代码可以运行进程上下文（用户空间代码的“代表”工作，像我们使用的方法）和终端上下文（例如，一个IRQ处理线程）。如果你已经在进程上下文中和并且你已经得到了所需的锁，你只需要简单地睡眠和重试直到成功为止。在中断上下文时你不能处于休眠状态，因此代码会在一个循环中运行直到锁可用。关联原语被称为自旋锁，但在我们的环境中，一个简单的互斥锁 —— 在特定时间内只有一个进程能“占有”的对象 —— 足够了。处于性能方面的考虑，现实的代码可能也会使用读-写信号。
　　锁总是保护某些数据（在我们的环境中，是一个“struct buffer”实例），而且也常常会把它们嵌入到它们所保护的结构体中。因此，我们添加一个互斥锁（‘struct mutex lock’）到“struct buffer”中。我们也必须用mutex_init()来初始化互斥锁；buffer_alloc是用来处理这件事的好地方。使用互斥锁的代码也必须包含linux/mutex.h。
　　互斥锁很像交通信号灯 —— 要是司机不看它和不听它的，它没什么用。因此，在对缓冲区做操作并在操作完成时释放它之前，我们需要更新reverse_read()和reverse_write()来获取互斥锁。让我们来看看read方法 —— write的工作原理相同：
　　static ssize_t reverse_read(struct file *file， char __user * out，
　　size_t size， loff_t * off)
　　{
　　struct buffer *buf = file->private_data;
　　ssize_t result;
　　if (mutex_lock_interruptible(&buf->lock)) {
　　result = -ERESTARTSYS;
　　goto out;
　　}
　　我们在函数一开始获取锁。mutex_lock_interruptible()要么得到互斥锁然后返回，要么让进程睡眠，直到有可用的互斥锁。像前面一样，_interruptible后缀意味着睡眠可以由信号来中断。
　　while (buf->read_ptr == buf->end) {
　　mutex_unlock(&buf->lock);
　　/* ... wait_event_interruptible() here ... */
　　if (mutex_lock_interruptible(&buf->lock)) {
　　result = -ERESTARTSYS;
　　goto out;
　　}
　　}
　　下面是我们的“等待数据”循环。当获取互斥锁时，或者发生称之为“死锁”的情境时，不应该让进程睡眠。因此，如果没有数据，我们释放互斥锁并调用wait_event_interruptible()。当它返回时，我们重新获取互斥锁并像往常一样继续：
　　if (copy_to_user(out， buf->read_ptr， size)) {
　　result = -EFAULT;
　　goto out_unlock;
　　}
　　...
　　out_unlock:
　　mutex_unlock(&buf->lock);
　　out:
　　return result;
　　后，当函数结束，或者在互斥锁被获取过程中发生错误时，互斥锁被解锁。重新编译模块（别忘了重新加载），然后再次进行测试。现在你应该没发现毁坏的数据了。
　　接下来是什么？
　　现在你已经尝试了一次内核黑客。我们刚刚为你揭开了这个话题的外衣，里面还有更多东西供你探索。我们的第一个模块有意识地写得简单一点，在从中学到的概念在更复杂的环境中也一样。并发、方法表、注册回调函数、使进程睡眠以及唤醒进程，这些都是内核黑客们耳熟能详的东西，而现在你已经看过了它们的运作。或许某天，你的内核代码也将被加入到主线Linux源代码树中 —— 如果真这样，请联系我们！