操作系统源代码详细分析二物业

目前国内火车的成本为250元左右 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来报告失败，那么就有可能触发无限循环。