25870：除了将消息打印到控制台之外，printk还能够记录最近打印的长度为LOG_ BUF_LEN的字符组（LOG_BUF_LEN为16K，请参看25632行）。如果在控制台打开之前，内核就已经调用printk，则显然不能在控制台上正确打印消息，但是这些消息将被尽可能地存储到log_buf中（25656行）。当控制台打开以后，缓存在log_buf中的数据就可以转储并在控制台上打印出来，请参看25988行。
log_buf是一个循环缓冲器，log_start和log_size变量（25657行和25646行）分别记录当前缓冲器的开始位置和长度。本行中的按位与（AND）操作实际上是快速求模（％）运算，它的正确性依赖于LOG_BUF_LEN的值是2的幂。
25872：保存变量跟踪记录循环日志的值。显然，日志大小会不断增长，直至达到LOG_BUF_LEN的值为止。此后，log_size将保持不变，而插入新字符将导致log_start的增长。
25878：请注意logged_chars（25658行）记录从机器启动之后由 printk写入的所有字符的长度，它在每次循环中都会被更新，而不是在循环结束后才改变一次。基于同样的道理，log_start和log_size的处理方式也是一样。这实际上是一种优化的时机，本书将在结束对函数的介绍之后再对它进行详细讨论。
25879：消息被分为若干行，这当然要使用新行标志符来进行分割。一旦内核检测到新行标志符，就写入一个完整行，从而内循环的执行也可以提前终止。
25884：在这里我们先不考虑内部循环是否会提前退出，从msg到p的字符序列是专门提供给控制台使用的（这种字符序列我称之为行，但是不要忘了，这里的行可能并不意味着新行终止，因为buf也许还没有终止）。如果该行的日志等级高于系统控制台定义的日志等级，而且当前又有控制台可供打印，那么就能够正确打印该行。（记住，printk可能在所有控制台打开之前就已经被调用过了。）
如果在该消息块中没有发现日志等级序列，并且在前面的printk调用中也没有对msg_level赋值，那么本行中的msg_level就是-1。由于console_loglevel总不小于1（除非root通过sysctl接口锁定），于是总是可以打印这些行。
25886：本行应该能够被打印。printk通过遍历打开的控制台驱动链表告知每一个控制台驱动去打印当前行设备驱动在本书的讨论范围之外，因此，控制台驱动代码则并不包含在内）。
25888：请注意这里消息文本的开头使用的是msg而不是p，这样就在没有日志等级序列的情况下写入消息了。然而，日志等级序列已经被存储到log_buf缓冲器中了。这样就使后来能够访问log_buf以获取消息日志等级的代码（请参看25998行），不会再产生显示混乱信息序列的现象。
25892：如果内层for循环发现一新行，那么buf中的剩余字符（如果有的话）将被认为是新的消息，因此msg_level会被重置。但是无论怎样，外层循环都会持续到buf清空为止。
25895：释放在25845行获取的控制台锁（console lock）。
25896：唤醒等待被写入控制台日志的所有进程。注意即使没有文本被实际写入任何控制台，这个过程也仍然会发生。这样处理是正确的，因为无论是否要往控制台中写入文本，等待进程实际上都是在等待从log_buf中读出信息。在 25748行，进程被转入休眠状态以等待log_buf的活动。在休眠、唤醒和等待队列中所使用的机制将在下一节中进行讨论。
25897：返回日志中写入的字符长度。
如果对于每个字符的处理工作都能减少一点，那么从25869行开始的for循环就执行得更快一点。当循环存在时，我们可以通过只在循环退出时将logged_chars更新一次来稍微提高运行速度。然而我们还可以通过其他努力来提高速度。由于我们可以预知消息的长度，因此log_size和log_start可以到最后再增长。让我们来实验一下这样能否提高速度，下面是一段经过理想优化的代码：
请注意循环通常只需要执行一次，只有在log_buf末尾写入信息需要折行时才会多次执行。因而log_size和log_buf只需要更新一次（或者当写入需要换行时是两次）。
这时速度的确提高了，但是有两个原因使我们并不能这样做。首先，内核可能有自己特有的memcpy函数，我们必须确保对memcpy的调用不会再次进入对printk的调用（有一部分内核移植版定义了自己特有的速度较快的memcpy函数版本，因此所有的移植都要在这一点上保持一致）。如果memecpy调用printk来报告失败，那么就有可能触发无限循环。
然而在这一点上也并不是真的无药可救。使用这种解决方案的最大问题在于该内核循环的形式中也要留意新行标志符，因此使用memcpy将整个消息拷贝到log_buf中是不正确的：如果此处存在新行，我们将无法对其进行处理。
我们可以试验一个一箭双雕的办法。下面这种替代的尝试虽然可能比前面那种初步解决方法速度要慢，但是它保持了内核版本的语意：
（请注意gcc的优化器十分灵敏，它足以能检测到循环内部的表达式log_buf+LOG_BUF_LEN并没有改变，因此在上面的循环中试图手工加速计算是没有任何效果的。）
不幸的是，这种方法并不能比现在的内核版本在速度上快许多，而且那样会使得代码晦涩难懂（如果你编写过更新log_size和log_start的代码，你就能清楚地了解这一点）。你可以自己决定这种折衷是否值得。然而无论怎样，我们学到了一些东西，通常，不管成功与否，改进内核代码都可以加深你对内核工作原理的理解。
2.2.2 等待队列
前一节我们曾简要的提到进程（也就是正在运行的程序）可以转入休眠状态以等待某个特定事件，当该事件发生时这些进程能够被再次唤醒。内核实现这一功能的技术要点是把等待队列（wait queue）和每一个事件联系起来。需要等待事件的进程在转入休眠状态后插入到队列中。当事件发生之后，内核遍历相应队列，唤醒休眠的任务让它投入运行状态。任务负责将自己从等待队列中清除。
等待队列的功能强大得令人吃惊，它们被广泛应用于整个内核中。更重要的是，实现等待队列的代码量并不大。
1. wait_queue结构
18662：简单的数据结构就是等待队列节点，它包含两个元素：
* task—指向struct task_struct结构的指针，它代表一个进程。从16325行开始的struct task_struct结构将在第7章中进行介绍。
* next—指向队列中下一节点的指针。因而，等待队列实际上是一个单链表。
通常，我们用指向等待队列队首的指针来表示等待队列。例如，printk使用的等待队列log_wait（25647行）。
2. wait_event
16840：通过使用这个宏，内核代码能够使当前执行的进程在等待队列wq中等待直至给定condition（可能是任何的表达式）得到满足。
16842：如果条件已经为真，当前进程显然也就无需等待了。
16844：否则，进程必须等待给定条件转变为真。这可以通过调用 __wait_event来实现（16824行），我们将在下一节介绍它。由于__wait_event已经同wait_event分离，已知条件为假的部分内核代码可以直接调用__wait_queue，而不用通过宏来进行冗余的（特别是在这些情况下）测试，实际上也没有代码会真正这样处理。更为重要的是，如果条件已经为真，wait_event会跳过将进程插入等待队列的代码。
注意wait_event的主体是用一个比较特殊的结构封闭起来的：
奇怪的是，这个小技巧并没有得到应有的重视。这里的主要思路是使被封闭的代码能够像一个单句一样使用。考虑下面这个宏，该宏的目的是如果p是一个非空指针，则调用free：
除非你在如下所述的情况下使用FREE1，否则所有调用都是正确有效的：
FREE1经扩展以后，else就和错误的if（FREE1的if）联系在一起。
有些程序员通过如下途径解决这种问题：
这两种方法都不尽人意，程序员在调用宏以后自然而然使用的分号会把扩展信息弄乱。以FREE2为例，在宏展开之后，为了使编译器能更准确地识别，我们还需要进行一定的缩进调节，最终代码如下所示：
这样就会引起语法错误—else和任何一个if都不匹配。FREE3从本质上讲也存在同样的问题。而且在研究问题产生原因的同时，就能够明白为什么宏体里是否包含if是无关紧要的。不管宏体内部内容如何，只要使用一组括号来指定宏体，就会碰到相同的问题。
引入do/while(0)技巧能够克服前面所出现的所有问题，现在我们可以编写FREE4。
将FREE4和其他宏一样插入相同代码之后，这段代码当然可以正确执行。编译器能够优化这个伪循环，舍弃循环控制，因此执行代码并没有速度的损失，我们也从而得到了能够实现理想功能的宏。
虽然这是一个可以接受的解决方案，但是我们不能不提到的是编写函数要比编写宏好得多。不过如果你不能提供函数调用所需的开销，那么就需要使用内联函数。这种情况虽然在内核中经常出现，但是在其他地方就要少得多。（不可否认，当使用C+ +、gcc或者任何实现了将要出现的修正版ISO标准C的编译器时，这种方案只是一种选择，就是最后为C增加内联函数。）
3. __wait_event
16824：__wait_event使当前进程在等待队列wq中等待，直至condition为真。
16829：通过调用add_wait_queue（16791行），局部变量 __wait可以被链接到队列上。注意__wait是在堆栈中而不是在内核堆中分配空间，这是内核中常用的一种技巧。在宏运行结束之前，__wait就已经被从等待队列中移走了，因此等待队列中指向它的指针总是有效的。
16830：重复分配CPU给另一个进程直至条件满足，这一点将在下面几节中讨论。
16831：进程被置为TASK_UNINTERRUPTIBLE状态（16190行）。这意味着进程处于休眠状态，不应被唤醒，即使是信号也不能打断该进程的休眠。信号在第6章中介绍，而进程状态则在第7章中介绍。
16832：如果条件已经满足，则可以退出循环。
请注意如果在第一次循环时条件就已经满足，那么前面一行的赋值就浪费了（因为在循环结束之后进程状态会立刻被再次赋值）。__wait_event假定宏开始执行时条件还没有得到满足。而且，这种对进程状态变量state的延迟赋值也并没有什么害处。在某些特殊情况下，这种方法还十分有益。例如当__wait_event开始执行时条件为假，但是在执行到16832行时就为真了。这种变化只有在为有关进程状态的代码计算condition变量值时才会出现问题。但是在代码中这种情况我没有发现。
16834：调用schedule（26686行，在第7章中讨论）将CPU转移给另一个进程。直到进程再次获得CPU时，对schedule的调用才会返回。这种情况只有当等待队列中的进程被唤醒时才会发生。
16836：进程已经退出了，因此条件必定已经得到了满足。进程重置TASK_RUNNING的状态（16188行），使其适合CPU运行。
16837：通过调用remove_wait_queue（16814行）将进程从等待队列中移去。wait_event_interruptible和__wait_event_interruptible（分别参见16868行和 16847）基本上与wait_event和__wait_event相同，但不同的是它们允许休眠的进程可以被信号中断。信号将在第6章中介绍。
请注意wait_event是被如下结构所包含的。
和do/while(0)技巧一样，这样可以使被封闭起来的代码能够像一个单元一样运行。这样的封闭代码就是一个独立的表达式，而不是一个独立的语句。也就是说，它可以求值以供其他更复杂的表达式使用。发生这种情况的原因主要在于一些不可移植的gcc特有代码的存在。通过使用这类技巧，一个程序块中的最后一个表达式的值将定义为整个程序块的最终值。当在表达式中使用 wait_event_interruptible时，执行宏体后赋__ret的值为宏体的值（参见16873行）。对于有Lisp背景知识的程序员来说，这是个很常见的概念。但是如果你仅仅了解一点C和其他一些相关的过程性程序设计语言，你可能就会觉得比较奇怪。
__wake_up
26829：该函数用来唤醒等待队列中正在休眠的进程。它由wake_up和wake_up_ interruptible调用（请分别参见16612行和16614行）。这些宏提供mode参数，只有状态满足mode所包含的状态之一的进程才可能被唤醒。
26833：正如将在第10章中详细讨论的那样，锁（lock）是用来限制对资源的访问，这在SMP逻辑单元中尤其重要，因为在这种情况下当一个CPU在修改某数据结构时，另一个CPU可能正在从该数据结构中读取数据，或者也有可能两个 CPU同时对同一个数据结构进行修改，等等。在这种情况下，受保护的资源显然是等待队列。非常有趣的是所有的等待队列都使用同一个锁来保护。虽然这种方法要比为每一个等待队列定义一个新锁简单得多，但是这就意味着SMP逻辑单元可能经常会发现自己正在等待一个实际上并不必须的锁。
26838：本段代码遍历非空队列，为队列中正确状态的每一个进程调用 wake_up_process（26356行）。如前所述，进程（队列节点）在此可能并没有从队列中移走。这在很大程度上是由于即使队列中的进程正在被唤醒，它仍然可能希望继续存在于等待队列中，这一点正如我们在__wait_event中发现的问题一样。
2.2.3 内核模块
整个内核并不需要同时装入内存。应该确认，为保证系统能够正常运行，一些特定的内核必须总是驻留在内存中，例如，进程调度代码就必须常驻内存。但是内核其他部分，例如大部分的设备驱动就应该仅在内核需要的时候才装载，而在其他情况下则无需占用内存。
举例来说，只有在内核真正和CD-ROM通讯时才需要使用完成内核与CD-ROM通讯的设备驱动程序，因此内核可以被设置为在和设备通讯之前才装载相应代码。内核完成和设备的通讯之后可以将这部分代码丢弃。也就是说，一旦代码不再需要，就可以从内存中移走。系统运行过程中可以增减的这部分内核称为内核模块。
内核模块的优点是可以简化内核自身的开发。假设你购买了一个新的高速CD-ROM 驱动器，但是现有的CD-ROM驱动程序并不支持该设备。你自然就希望增加对这种高速模式的支持以提高系统光驱设备的性能。如果作为内核模块来编译驱动程序，你的工作将会方便得多：编译驱动程序、加载到内核、测试、卸载驱动程序、修改驱动程序、再次加载驱动程序到内核、测试，如此周而复始。如果你的驱动程序是直接编辑在内核中的，那么你就必须重新编译整个内核并且在每次修改驱动程序之后重新启动机器。这样慢得很多。
自然，你也必须留意内核模块。对于指明其他内核模块在磁盘上的驻留位置的那些模块，一定不能从内存中卸载，否则，内核将只能通过访问磁盘来装载处理磁盘访问的内核模块，这是不可能实现的。这也是我们要选择把部分内核作为模块编译还是直接编译进内核使其常驻内存的又一个原因。知道自己系统的设置方式，因而也就可以选择正确使用的方式（如果为了确保安全，可以简单的忽略内核模块系统的优点，而把所有的内容都编译到内核里面）。
内核模块会带来一些速度上的损失，这是因为一些必需的代码现在并不在RAM中，必需要从磁盘读入。但是整个系统的性能通常会有所提高，这主要是因为通过丢弃暂时不使用的模块可以释放出额外的RAM供应用程序使用。如果这部分内存被内核所占用，应用程序将只能更加频繁地进行磁盘交换，而这种磁盘交换会显著地降低应用程序的性能（磁盘交换将在第8章中讨论）。
内核模块还会带来因复杂度的增加所造成的开销，这是因为在系统运行的过程中，移进移出部分内核需要额外的代码。然而，复杂度的开销是可以管理的。通过使用外部程序来代理一些必需的工作还可以更进一步降低复杂度的开销（更为确切的说法是，这样做不是减少了复杂度的开销，而是把复杂度的开销重新分配了一下）。这是对内核模块原理的一个小小的扩展：即使是内核的支持模块，对于内核来说也只是外部的、部分可用的，只有在需要的时候才被装入内存。
通常用于这种目的程序称为modprobe。有关的modprobe代码超出了本书的范围，但是在Linux的每个发行版本中都包含有它。本节的剩余部分将讨论同modprobe协同工作，以装载内核模块的内核代码。
1. request_module
24432：作为函数说明之前的注释，request_module是一个函数。内核的其他模块在需要装载其他内核模块的时候，都必须调用这个函数。就像内核处理其他工作一样，这种调用也是为当前运行的进程进行的。从进程的角度来看，这种调用的请求通常是隐含的—正在执行进程其他请求的内核可能会发现，必须调入一个模块才能够完成该请求。例如，请参见10070行，这里是一些将在第7章中讨论的代码。
24446：以内核中的一个独立进程的形式执行exec_modprobe函数（24384行）。这并不能只通过函数的简单调用实现，因为exec_modprobe要继续调用exec来执行一个程序。因此，对函数exec_modprobe的简单调用将永远不会有返回。
这和使用fork以准备exec调用十分类似，你可以认为 kernel_thread对内核来说就是较低版本的fork，虽然两者有很大不同。fork是从指定函数开始执行新的进程，而不是从调用者的当前位置开始运行。正如fork一样，kernel_thread返回的值是新进程的进程号。
24448：和fork一样，从kernel_thread返回的负值表示内部错误。
24455：正如函数中论述的一样，大部分的信号将因当前进程而被暂时阻塞。
24462：等待exec_modprobe执行完毕，同时指出所需要的模块是已经成功装入内存，还是装载失败了。
24465：结束运行，恢复信号。如果exec_modprobe返回错误代码，则打印错误消息。
2. exec_modprobe
24384：exec_modprobe运行为内核增加内核模块的程序。这里的模块名是一个void*的指针，而不是char*的指针。原因简单说来就是kernel_thread 产生的函数通常都使用void*指针参数。
24386：设置modprobe的参数列表和环境。modprobe_path （24363行）用来定位modprobe程序的位置。它可以通过内核的sysctl特性来修改，这一点将在第11章中介绍（参见30388行）。这意味着root可以动态选择不同于/sbin/modprobe的程序来运行，以适应当modprobe被安装到其他地方或者使用修改过的modprobe替换掉了原有的modprobe之类的情况。
24400：（正如代码中描述的一样）出于安全性考虑，丢弃所有挂起的信号和信号句柄（handl-ers）。这里最重要的部分是对flush_signal_handlers的调用（28041行），它使用内核默认的信号句柄代替所有用户定义的信号句柄。如果在此时有信号被传送到内核，它将获得默认响应—通常是忽略信号或杀死进程。但是不管怎样都不会引起安全风险。由于该函数从触发它的进程中分离出来（如前所述），所以，不管原始进程在此处是否改变其原来分配的信号，句柄都不会产生任何影响。
24405：关闭调用进程打开的所有文件。最重要的是，这意味着modprobe程序不再从调用进程中继承标准输入输出和标准错误。这很有可能会引起安全漏洞（这可能是在替代modprobe的程序中引起的问题，但是modprobe本身实际上并不关心这个差异）。
24413：modprobe程序作为root运行，它拥有root所拥有的所有权限。和整个内核中其他地方一样，请注意root使用用户ID号0的假定在这里已经被写入程序。用户ID号和权能系统（capability system，在接下来的几行中会用到）将在第7章中介绍。
24421：试图执行modprobe程序。如果尝试失败，内核将使用 printk打印错误消息并返回错误代码。这里是可能产生printk的缓冲器过载的地点之一。module_name的长度并没有明确限制，就我们对该调用的看法而言，它可能长达一百万个字符。为防止printk缓冲器过载，你必需遍历所有对于该函数的调用（实际上是对request_module的调用），以保证每个调用者使用足够短的、不会为printk造成麻烦的模块名。
24427：当execve成功执行时，它不会返回任何结果，因此本处是不可能执行到的。但是编译器却并不知道这一点，因此，此处使用了return语句以保证gcc不出错。
对于内核的进一步讨论将超出本章的既定范围，因此在这个问题上我们到此为止。然而本书中也包括了其他必需的内核代码。在读完第4章和第5章之后，也许你会希望再次仔细研读一下这部分内容。有关这个问题的两个文件是 include/linux/module.h（从15529行开始）和/kernel/module.c（从24476行开始）。和 sys_create_module（24586行）、sys_init_module（24637行）、sys_delete_module （24860行）和sys_query_module（25148行）四个函数需要特别注意一样，struct module（15581行）也要特别引起注意。这些函数实现了modprobe及insmod、lsmod和rmmod所使用的系统调用，以完成模块的装载、定位和卸载。
内核触发直接回调内核程序的现象看起来很令人奇怪。但是，实际上进行的工作不止于此。例如，modprobe必须实际访问磁盘以搜寻要装载的模块。而且更为重要的一点是，这种方法赋予root对内核模块系统更多的控制能力。这主要是因为root也可以运行modprobe及相关程序。因此，root既可以手工装载、查询、卸载模块，也可以由内核自动完成。
2.3 配置与编译内核
你可能仅仅研读、欣赏而并不修改Linux内核源代码。但是，更普遍的情况是，用户有强烈的愿望去改进内核代码并完成相应的测试，这样我们就需要知道如何重建内核。本节就是要告诉你如何实现这一点，而最终则归结于如何把你所做的修改发行给别人，以使得每个人都能从你的工作中受益。
2.3.1 配置内核
编译内核的第一步就是配置内核，这是增加或者减少对内核特性的支持及修改内核的一些特性的必要步骤。例如，你可以要求内核为自己的声卡指定一个不同的DMA通道。如果内核配置和你的需要相同，那么你可以直接跳过本节，否则请继续阅读以下内容。
为了完成内核的配置，请先切换到root用户，然后转入如下内核源程序目录：
|
接着敲入如下命令组：
|
这三条命令都可以用来配置内核，但它们发挥作用的方式各不相同：
* make config—三种方法中最简单也是最枯燥的一种。但是最基本的一点是，它可以适应任何情况。通过为每一个内核支持的特性向用户提问的方式来决定在内核中需要包含哪些特性。对于大多数问题，你只要回答y（yes，把该特性编译进内核中）、m（作为模块编译）或者n（no，根本不对该特性提供支持）。在决定之前用户应该考虑清楚，因为这个过程是不可逆的。如果你在该过程中犯了错误，就只能按Ctrl+C退出。你也可以敲入?以获取帮助。图2-1显示了这种方法在X终端上运行的情况。
图2-1 运行中的make config
幸运的是，这种方法还有一些智能。例如，如果你对SCSI支持回答no，那么系统就不会再询问你有关SCSI的细节问题了。而且你可以只按回车键以接受默认的选择，也就是当前的设置（因此，如果当前内核将对于SCSI的支持编译进了内核，在这个问题上按回车键就意味着继续把对SCSI的支持编译进内核中）。即使是这样，大部分用户还是宁愿使用另外的两种方法。
* make menuconfig—一种基于终端的配置机制，用户拥有通过移动光标来进行浏览等功能。图2-2显示了在X终端上运行的make menuconfig。虽然在控制台上显示的是彩色，但是在终端上的显示仍然相当单调。使用menuconfig必须要有相应的ncurses类库。
* make xconfig—这是我最喜欢的一种配置方式。只有你能够在X server上用root用户身份运行X应用程序时，这种配置方式才可以使用（有些偏执的用户就不愿意使用这种方式）。你还必须拥有Tcl窗口系统，这实际上还意味着你必须拥有Tcl、Tk以及一个正在运行的X安装程序。作为补偿，用户获得的是更漂亮的、基于X系统的以及和menuconfig功能相同的配置方法。图2-3显示了在这种方法运行过程中打开“可装载模块支持（Loadable module support）”子窗口的情况。
如上所述，这三种方法都实现了相同的功能：它们都生成在构建内核时使用的.config文件。而唯一的区别在于创建这个文件时的难易程度不同。
2.3.2 构建内核
构建内核要做的工作要比配置内核所做的工作少得多。虽然有几种方式都能实现这一功能，但是选择哪一种依赖于你希望怎样对系统进行设置。长期以来，我已经形成了如下的习惯。虽然这种习惯比我所必须要做的略微多一些，但是它包含了所有基本的问题。首先，如果你还不在内核源程序目录中，请先再次转入这一目录：
|
现在，切换到root用户，使用下面显示的命令生成内核。现在在shell中敲入下面的命令，注意make命令因为空间关系分成了两行，但实际上这在shell输入时是一个只有一行的命令：
|
当给出了如上多个目标时，除非前面所有的目标都成功了，否则make能够知道没有必要继续尝试下面的目标。因此，如果make能够运行结束，成功退出，那么这就意味着所有的目标都正确构建了。现在你可以重新启动机器以运行新的内核。
2.3.3 备份的重要性
当修改（fooling）内核时，你必须准备一个能够启动的备用内核。实现该目的的一种方式是通过配置Linux加载程序（LILO）以允许用户选择启动的内核映象，其中之一是从没有修改过的内核的备份（我总是这样做的）。
如果你比较有耐心，那么你就可以使用zdisk目标而不使用zlilo目标；它可以把能够启动的内核映象写入软盘中。这样你就可以通过在启动时插入软盘的方式启动你的测试内核；如果没有插入软盘，则启动正常的内核。
但是请注意：内核模块并没有被装载到软盘中，它们实际上是装在硬盘中的（除非你愿意承担更多的麻烦）。因此，如果你弄乱了内核模块，即使是zdisk目标也救不了你。实际上，上面提到的这两种方法都存在这个问题。虽然有比较好的解决方法可用，但是最简单的方法（也就是我所使用的方法）是把备份内核作为严格独立的内核来编译，而不使用可装载模块的支持。通过这种方法，即使我弄乱了内核而不得不使用备份启动系统，那么不管问题是实验性内核不正确还是内核模块的原因都无关紧要。不管怎样，在备份的内核中已经有我需要的所有东西了。
由于用户所做的修改可能导致系统的崩溃，如损坏磁盘上的数据等等，并不仅仅只是打乱设备驱动程序或文件系统，在测试新内核之前，备份系统的最新数据也是一个英明的决策（虽然设备驱动程序的开发不是本书的主题，但是必需指出的是，设备驱动程序的缺陷可能会引起系统的物理损坏。例如显示器是不能备份的，而且因价格昂贵而不易替换）。作为一个潜在的内核黑客，你的最佳投资（当然是读过本书以后）是一个磁带驱动器和充足的磁带。
2.3.4 发布你的改进
下面是有关发布你所做修改的一些基本规则：
* 检查最新发行版本，确保你所处理的不是已经解决了的问题。
* 遵守Linux 内核代码编写的风格。简要的说就是8字符缩进以及K&R括号风格（if，else，for，while，switch或者do后面同一行中紧跟着开括号）。在内核源程序目录下面的文档编写和代码风格文件给出了完整的规则，不过我们已经介绍了其中的关键部分。注意本书中包含的源程序代码为节省空间而进行了大量的重新编辑，在该过程中我可能打破了其中的一些规则。
* 独立发行相对无关的修改。这样，只想使用你所做的某部分修改的人就可以十分方便地获得想要的东西，而不用一次检验所有的修改内容。
* 让使用你所做修改的用户清楚他们可以从你的修改中获取什么。同样，你也应该给出这些问题的可信度。你是15min之前才匆匆完成你的修改，甚至还没有时间对它们进行编译，还是已经在你和你的朋友的系统中已长期稳定地运行过这个修改？
假设现在你已经准备好发行自己的修改版本了，那么要做的第一步是建立一个说明你所做的修改的文件。你可以使用diff程序自动创建这个文件。结果或者被称为diffs，或者在Linux中更普遍的被称为补丁（patch）。
发布的过程十分简单。假设原来没有修改过的源程序代码在linux-2.2.5目录下，而你修改过的源程序代码在linux-my目录下，那么只要进行如下的简单工作就可以了（只有在链接不存在的情况下才需要执行ln）：
现在，输出文件my.patch包含了其他用户应用这个修改程序时所需要的一切内容。（警告：如上所述，两个源程序间的所有差别都会包含在这个补丁文件中。diff不能区分修改部分之间的关系，所以就把它们都罗列了出来。）如果补丁文件相对较小，你可以使用邮件直接发往内核邮件列表。如果补丁很大，那么就需要通过FTP或者Web站点发布。这时发给邮件列表的信件中就只需要包含一个 URL。
Linux内核邮件列表的常见问题解答（FAQ）文件位于http://www.ececs.uc.edu/~rreilova/ linux/lkmlfaq.html。该FAQ中包含了邮件列表的订阅、邮件发布及阅读邮件列表的注意事项等等。