2.比较简单的方法:http://vger.kernel.org/vger-lists.html列出了linux内核的邮件列表,点击"subscribe / unsubscribe",你要的应该是http://vger.kernel.org/vger-lists.html#linux-kernel
在开头简述问题会有所帮助，接下来按时间顺序详述。这样黑客们就知道该在你的说明中找什么
5 提问的技巧
--------------
别要求私下答复
--------------
黑客们认为解决问题应该有公开、透明的流程。只要任何更有见地的人注意到答案的不完
善或者不正确，这个最初的答案就可以和应该得到纠正。同时，通过能力和知识被大家注
意，被大家接受，回答问题者得到了应有的奖励。
如果你要求对方私下回答你，这既破坏了整个流程，也破坏了奖励制度。别提这要求，这
是回答者的权利，由他来选择是否私下答复--如果他选择这样做，通常是因为他认为这个
答案过于显而易见或者有不良的公开影响，别人不会感兴趣。
只有一种有限的例外：如果你预计将收到大量雷同的答复，你可以说：“把答案寄给我，
由我来汇总吧。”将邮件列表或者新闻组从大量重复的帖子中打救出来是很有君子之风的
--但请记住，履行自己关于汇总的承诺。
--------------
明白你想问什么
--------------
漫无边际的提问近乎无休无止的时间黑洞。最能给你有用答案的人也正是最忙的人（他们
忙是因为要亲自完成大部分工作）。这样的人对无节制的时间黑洞不太感冒，因此也可以
说他们对漫无边际的提问不大感冒。
如果你明确表述需要回答者做什么（提供建议，发送一段代码，检查你的补丁或是别
的），就最有可能得到有用的答案。这会定出一个时间和精力的上限，便于回答者集中精
力来帮你，这很凑效。
要理解专家们生活的世界，要把专业技能想象为充裕的资源，而回复的时间则是贫乏的资
源。解决你的问题需要的时间越少，越能从忙碌的专家口中掏出答案。
因此，优化问题的结构，尽量减少专家们解决它所需要的时间，会有很大的帮助--这通常
和简化问题有所区别。因此，问“我想更好的理解X，能给点提示吗？”通常比问“你能
解释一下X吗？”更好。如果你的代码不能工作，问问它有什么地方不对，比要求别人替
你修改要明智得多。
------------------------
别问应该自己解决的问题
------------------------
黑客们总是善于分辨哪些问题应该由你自己解决；因为我们中的大多数都曾自己解决这类
问题。同样，这些问题得由你来搞定，你会从中学到东西。你可以要求给点提示，但别要
求得到完整的解决方案。
----------------
去除无意义的疑问
----------------
别用无意义的话结束提问，例如“有人能帮我吗？”或者“有答案吗？”。首先：如果你
对问题的描述不很合适，这样问更是画蛇添足。其次：由于这样问是画蛇添足，黑客们会
很厌烦你--而且通常会用逻辑上正确的回答来表示他们的蔑视，例如：“没错，有人能帮
你”或者“不，没答案”。
----------------------------
谦逊绝没有害处，而且常帮大忙
----------------------------
彬彬有礼，多用“请”和“先道个谢了”。让大家都知道你对他们花费时间义务提供帮助
心存感激。
实话实说，虽然这不象合乎语法、清楚准确的描述，避免私有格式等等那么重要（也不能
用来替代它们）；黑客一般更喜欢直接了当然而技术上敏锐的bug报告，而不是彬彬有礼
的废话（如果这让你迷惑不解，请记住，我们衡量一个问题价值的标准是：它能让我们学
会多少）。
然而，如果你有很多问题无法解决，礼貌将会增加你得到有用答案的机会。
（我们注意到，自从本指南发布后，从资深黑客处得到的唯一严重缺陷反馈，就是对预先
道谢这一条。一些黑客觉得“先谢了”的言外之意是过后就不会再感谢任何人了。我们的
作者： jianchunchen 2005-7-7 10:18 回复此发言
--------------------------------------------------------------------------------
6 提问的技巧
建议是：都道谢。）
------------------------
问题解决后，加个简短说明
------------------------
问题解决后，向所有帮助过你的人发个说明，让他们知道问题是怎样解决的，并再一次向
他们表示感谢。如果问题在新闻组或者邮件列表中引起了广泛关注，应该在那里贴一个补
充说明。
补充说明不必很长或是很深入；简单的一句“你好，原来是网线出了问题！谢谢大家
--Bill”比什么也不说要强。事实上，除非结论真的很有技术含量，否则简短可爱的小结
比长篇学术论文更好。说明问题是怎样解决的，但大可不必将解决问题的过程复述一遍。
除了表示礼貌和反馈信息以外，这种补充有助于他人在邮件列表/新闻组/论坛中搜索对你
有过帮助的完整解决方案，这可能对他们也很有用。
最后（至少？），这种补充有助于所有提供过帮助的人从中得到满足感。如果你自己不是
老手或者黑客，那就相信我们，这种感觉对于那些你向他们求助的导师或者专家而言，是
非常重要的。问题久拖未决会让人灰心；黑客们渴望看到问题被解决。好人有好报，满足
他们的渴望，你会在下次贴出新问题时尝到甜头。
============
如何理解答案
============
--------------------
RTFM和STFW：别烦我啦
--------------------
有一个古老而神圣的传统：如果你收到“RTFM （Read The [censored] Manual）”的回
复，回答者认为你应该去读TMD手册。当然，基本上他是对的，你应该读一读。
RTFM有一个年轻的亲戚。如果答案是“STFW （Search The [censored] Web）”，回答者
认为你应该到TMD的网上去搜索。基本上，他也是对的，你就去找吧。
通常，用这两句之一回答你的人会给你一份包含你需要内容的手册或者一个网址，而且他
们打这些字的时候正在阅读着。这些答复意味着回答者认为(1). 你需要的信息非常容易
获得；(2). 你自己去搜索这些信息比灌给你能让你学到更多。
别为这个而不爽；依照黑客的标准，他没有对你的要求视而不见，已经能大致能表示对你
的关注。你应该对他祖母般的慈祥表示感谢。
----------
还是不懂:(
----------
如果你不是很理解答案，别立刻要求对方解释。象你以前试着自己解决问题时那样（利用
手册，FAQ，网络，身边的高手），去理解它。如果你真的需要对方解释，记得表现出你
已经学到了点什么。
比方说，如果我回答你：“看来似乎是zEntry被阻塞了；你应该先清除它。”，然后：
一个很糟的后续问题：“zEntry是什么？”
聪明的问法应该是这样：“哦~我看过帮助了:)但是只有-z和-p两个参数中提到了
zEntry:(而且还都没有清楚的解释:<你是指这两个中的哪一个吗？还是我看漏了什么？”
--------
面对无礼
--------
黑客圈子里很多貌似粗鲁的言行并非有意冒犯。更恰当的说，这是直率、不说废话的沟通
方式的产物，这种沟通方式源于人们关注问题的解决--多过让人感受温暖亲情然而却依旧
糊里糊涂--的天性。
如果你觉得受到粗鲁的对待，请保持冷静。如果真有人表现粗野，通常会有列表/新闻组/
论坛的长辈找他谈心，如果没有这样，而你又大发脾气，则很可能对方的言行是黑客社区
行为规范许可内，而你被认为是有过错的。这会不利于你得到信息或者帮助。
另一方面，你偶尔也会无缘无故有粗野的言行和心态。上述现象的另一面是，人们允许狠
狠打击真正的冒犯者，用尖刻的言语剖析他们的不当言行。如果你真决定这样做，先仔细
7 提问的技巧
又仔细的掂量一下你自己的分量。合理的粗鲁与发动一场无意义的论战之间只隔了一条细
细的线，冒冒失失撞上去的黑客不在少数；如果你是新手或者门外汉，不犯这种错的机会
是很渺茫的。如果你想得到信息而不是来胡闹，别冒险回复，最好把手从键盘上拿开。
（有些人声称多数黑客有孤僻症或者社交障碍综合征的轻度症状，而且确实缺少部分有助
“常人”进行社交行为的脑组织结构。这也许是真的，也许不是。如果你自己不是黑客，
那么，把我们想象成脑部有缺陷的人有助你面对我们的古怪。有话直说，我们无所谓；我
们乐于按自己的想法生活，而且总是对医学概念持相当怀疑的态度。）
在下一节里，我们将谈论另一个话题；当你行差踏错时可能遇到的“无礼”。
================
决不要象个失败者
================
很有可能，你在黑客社区的论坛会受到很多公开的攻击--用本文提到的各种方式或类似的
方法，而且很可能会有各式各样的旁敲侧击来告诉你你有多讨厌。
如果噩梦成真，你能做的最糟的事就是为此发牢骚，抱怨受到人身攻击，要求对方道歉，
尖叫，屏住呼吸，威胁要控诉对方，向他老板告状，不掀起马桶座圈，等等等等。然而，
你应该这样：
由它去吧，这没什么大不了的。实际上这么做是恰当的和有益的（主要是有利身心健
康:）。
社区的规范不靠社区，而是靠积极推行它们的人们来维护，这种维护是公开的，显而易见
的。别抱怨说一切批评都应该通过私信传送，它本来就不该那样。当别人指出你的话有错
误，或者他有不同观点的时候，坚持认为他在羞辱你是没有用的。这些都是失败者的态
度。
有那么一些黑客论坛，出于对高度自谦的误解，禁止参与者张贴专给人找茬的帖子，而且
被告知“如果不愿帮助用户，那就闭嘴。”，他们认为，引开参与者的话题，只会使得他
们陶醉在毫无意义的喋喋不休中，从而失去了技术论坛的意义。
夸张的“友善”（以那种方式）还是有用的帮助：你自己选择吧。
记住：当黑客说你很烦人，（无论用多么粗暴的语言）警告你别再那样做了，他的本意并
非是针对(1)你，以及(2)他的社区。他本来可以轻易的忽略你，把你从他的视线中抹去。
如果你无法接受要向他表示感激，至少应该表现出你的气度，别抱怨，别期望只因为你是
新人，你有戏剧般的敏感脆弱的神经和自封的权利，而受到易碎玩偶般的特别对待。
==========
三思而后问
==========
以下是几个经典蠢问题，以及黑客在拒绝回答时的心中所想：
问题：我能在哪找到X程序？
问题：我的程序/配置/SQL申明没有用
问题：我的Windows有问题，你能帮我吗？
问题：我在安装Linux（或者X）时有问题，你能帮我吗？
问题：我怎么才能破解root帐号/窃取OP特权/读别人的邮件呢？
提问：我能在哪找到X程序？
回答：就在我找到它的地方啊蠢货--搜索引擎的那一头。天呐！还有人不会用Google吗？
提问：我的程序（配置、SQL申明）没有用
回答：这不算是问题吧，我对找出你的真正问题没兴趣--如果要我问你二十个问题才找得
出来的话--我有更有意思的事要做呢。在看到这类问题的时候，我的反应通常不外如下三
种：
1. 你还有什么要补充的吗？
2. 真糟糕，希望你能搞定。
3. 这跟我有什么鸟相关？
提问：我的Windows有问题，你能帮我吗？
回答：能啊，扔掉萎软的垃圾，换Linux吧。
提问：我在安装Linux（或者X）时有问题，你能帮我吗
8 提问的技巧
回答：不能，我只有亲自在你的电脑上动手才能找到毛病。还是去找你当地的Linux用户
组寻求手把手的指导吧（你能在这儿找到用户组的清单）。
提问：我怎么才能破解root帐号/窃取OP特权/读别人的邮件呢？
回答：想要这样做，说明你是个卑鄙小人；想找个黑客帮你，说明你是个白痴！
==============
好问题，坏问题
==============
最后，我举一些例子来说明，怎样聪明的提问；同一个问题的两种问法被放在一起，一种
是愚蠢的，另一种才是明智的。
蠢问题：我可以在哪儿找到关于Foonly Flurbamatic的资料？
这种问法无非想得到“STFW”这样的回答。
聪明问题：我用Google搜索过“Foonly Flurbamatic 2600”，但是没找到有用的结
果。谁知道上哪儿去找对这种设备编程的资料？
这个问题已经STFW过了，看起来他真的遇到了麻烦。
蠢问题：我从FOO项目找来的源码没法编译。它怎么这么烂？
他觉得都是别人的错，这个傲慢自大的家伙:(
聪明问题：FOO项目代码在Nulix 6.2版下无法编译通过。我读过了FAQ，但里面没有提到
跟Nulix有关的问题。这是我编译过程的记录，我有什么做得不对的地方吗？
他讲明了环境，也读过了FAQ，还指明了错误，并且他没有把问题的责任推到别人头上，
这个家伙值得留意。
蠢问题：我的主板有问题了，谁来帮我？
普通黑客对这类问题的回答通常是：“好的，还要帮你拍拍背和换尿布吗？” ，然后按
下删除键。
聪明问题：我在S2464主板上试过了X、Y和Z，但没什么作用，我又试了A、B和C。请注意
当我尝试C时的奇怪现象。显然边带传输中出现了收缩，但结果出人意料。在多处理器主
板上引起边带泄漏的通常原因是什么？谁有好主意接下来我该做些什么测试才能找出问
题？
这个家伙，从另一个角度来看，值得去回答他。他表现出了解决问题的能力，而不是坐等
天上掉答案。
在最后一个问题中，注意“告诉我答案”和“给我启示，指出我还应该做什么诊断工作”
之间微妙而又重要的区别。
事实上，后一个问题源自于2001年8月在Linux内核邮件列表上的一个真实的提问。我
（Eric）就是那个提出问题的人。我在Tyan S2464主板上观察到了这种无法解释的锁定
现象，列表成员们提供了解决那一问题的重要信息。
通过我的提问方法，我给了大家值得玩味的东西；我让人们很容易参与并且被吸引进来。
我显示了自己具备和他们同等的能力，邀请他们与我共同探讨。我告诉他们我所走过的弯
路，以避免他们再浪费时间，这是一种对他人时间价值的尊重。
后来，当我向每个人表示感谢，并且赞赏这套程序（指邮件列表中的讨论--译者注）运作
得非常出色的时候，一个Linux内核邮件列表（lkml）成员表示，问题得到解决并非由于
我是这个列表中的“名人”，而是因为我用了正确的方式来提问。
我们黑客从某种角度来说是拥有丰富知识但缺乏人情味的家伙；我相信他是对的，如果我
象个乞讨者那样提问，不论我是谁，一定会惹恼某些人或者被他们忽视。他建议我记下这
件事，给编写这个指南的人一些指导。
================
找不到答案怎么办
================
如果仍得不到答案，请不要以为我们觉得无法帮助你。有时只是看到你问题的人不知道答
案罢了。没有回应不代表你被忽视，虽然不可否认这种差别很难区分。
总的说来，简单的重复张贴问题是个很糟的想法。这将被视为无意义的喧闹。
你可以通过其它渠道获得帮助，这些渠道通常更适合初学者的需要。
有许多网上的以及本地的用户组，由狂热的软件爱好者（即使他们可能从没亲自写过任何
软件）组成。通常人们组建这样的团体来互相帮助并帮助新手。
另外，你可以向很多商业公司寻求帮助，不论公司大还是小（Red Hat和LinuxCare就是
两个最常见的例子）。别为要付费才能获得帮助而感到沮丧！毕竟，假使你的汽车发动机
汽缸密封圈爆掉了--完全可能如此--你还得把它送到修车铺，并且为维修付费。就算软件
没花费你一分钱，你也不能强求技术支持总是免费的。
对大众化的软件，就象Linux之类而言，每个开发者至少会有上万名用户。根本不可能由
一个人来处理来自上万名用户的求助电话。要知道，即使你要为帮助付费，同你必须购买
同类软件相比，你所付出的也是微不足道的（通常封闭源代码软件的技术支持费用比开放
源代码软件要高得多，而且内容也不那么丰富）
内核是 *** 作系统最基本的部分。它是为众多应用程序提供对计算机硬件的安全访问的一部分软件，这种访问是有限的，并且内核决定一个程序在什么时候对某部分硬件 *** 作多长时间。直接对硬件 *** 作是非常复杂的，所以内核通常提供一种硬件抽象的方法来完成这些 *** 作。硬件抽象隐藏了复杂性，为应用软件和硬件提供了一套简洁，统一的接口，使程序设计更为简单。严格地说，内核并不是计算机系统中必要的组成部分。程序可以直接地被调入计算机中执行，这样的设计说明了设计者不希望提供任何硬件抽象和 *** 作系统的支持，它常见于早期计算机系统的设计中。最终，一些辅助性程序，例如程序加载器和调试器，被设计到机器核心当中，或者固化在只读存储器里。这些变化发生时， *** 作系统内核的概念就渐渐明晰起来了。
一个更重要的问题是，什么人才要了解内核。或者说，对内核的了解程度，会怎样影响一个人的工作，毕竟，它是复杂的。
[编辑本段]内核分类
单内核 它为潜在的硬件提供了大量完善的硬件抽象 *** 作。
微内核 只提供了很小一部分的硬件抽象，大部分功能由一种特殊的用户态程序：服务器来完成。
混合内核 它很像微内核结构，只不过它的的组件更多的在核心态中运行，以获得更快的执行速度。
外内核 这种内核不提供任何硬件抽象 *** 作，但是允许为内核增加额外的运行库，通过这些运行库应用程序可以直接地或者接近直接地对硬件进行 *** 作。
单内核
单内核结构在硬件之上定义了一个高阶的抽象界面，应用一组原语(或者叫系统调用)来实现 *** 作系统的功能，例如进程管理，文件系统，和存储管理等等，这些功能由多个运行在核心态的模块来完成。
尽管每一个模块都是单独地服务这些 *** 作，内核代码是高度集成的，而且难以编写正确。因为所有的模块都在同一个内核空间上运行，一个很小的bug都会使整个系统崩溃。然而，如果开发顺利，单内核结构就可以从运行效率上得到好处。
很多现代的单内核结构内核，如Linux和FreeBSD内核，能够在运行时将模块调入执行，这就可以使扩充内核的功能变得更简单，也可以使内核的核心部分变得更简洁。
单内核结构的例子：
1.传统的UNIX内核，例如伯克利大学发行的版本
2.Linux内核
微内核
微内核结构由一个非常简单的硬件抽象层和一组比较关键的原语或系统调用组成，这些原语仅仅包括了建立一个系统必需的几个部分，如 线程管理，地址空间和进程间通信等。
微核的目标是将系统服务的实现和系统的基本 *** 作规则分离开来。例如，进程的输入/输出锁定服务可以由运行在微核之外的一个服务组件来提供。这些非常模块化的用户态服务器用于完成 *** 作系统中比较高级的 *** 作，这样的设计使内核中最核心的部分的设计更简单。一个服务组件的失效并不会导致整个系统的崩溃，内核需要做的，仅仅是重新启动这个组件，而不必影响其它的部分
微内核将许多OS服务放入分离的进程,如文件系统,设备驱动程序,而进程通过消息传递调用OS服务.微内核结构必然是多线程的,第一代微内核,在核心提供了较多的服务,因此被称为'胖微内核',它的典型代表是MACH,它既是GNU HURD也是APPLE SERVER OS 的核心,可以说,蒸蒸日上.第二代为微内核只提供最基本的OS服务,典型的OS是QNX,QNX在理论界很有名,被认为是一种先进的OS.
微内核的例子：
1.AIX
2.BeOS
3.L4微内核系列
4.Mach, 用于GNU Hurd和Mac OS X
5.Minix
6.MorphOS
7.QNX
8.RadiOS
9.VSTa
单内核与微内核的比较
单内核结构是非常有吸引力的一种设计，由于在同一个地址空间上实现所有低级 *** 作的系统控制代码的复杂性的效率会比在不同地址空间上实现更高些。
20世纪90年代初，单内核结构被认为是过时的。把Linux设计成为单内核结构而不是微内核引起了无数的争议。
现在，单核结构正趋向于容易被正确设计，所以它的发展会比微内核结构更迅速些。两个阵营中都有成功的案例。微核经常被用于机器人和医疗器械的嵌入式设计中，因为它的系统的关键部分都处在相互分开的，被保护的存储空间中。这对于单核设计来说是不可能的，就算它采用了运行时加载模块的方式。
尽管Mach是众所周知的多用途的微内核，人们还是开发了除此之外的几个微内核。L3是一个演示性的内核，只是为了证明微内核设计并不总是低运行速度。它的后续版本L4甚至可以将Linux内核在单独的地址空间作为它的一个进程来运行。
QNX是一个从20世纪80年代就开始设计的微内核系统。它比Mach更接近微内核的理念。它被用于一些特殊的领域，在这些情况下由于软件错误导致系统失效是不允许的。例如航天飞机上的机械手，还有研磨望远镜镜片的机器，一点点失误就会导致上千美元的损失。
很多人相信，由于Mach不能够解决一些提出微内核理论时针对的问题，所以微内核技术毫无用处。Mach的爱好者表明这是非常狭隘的观点，遗憾的是似乎所有人都开始接受这种观点。
混合内核
混合内核实质上是微内核，只不过它让一些微核结构运行在用户空间的代码运行在内核空间，这样让内核的运行效率更高些。这是一种妥协做法，设计者参考了微内核结构的系统运行速度不佳的理论。然而后来的实验证明，纯微内核的系统实际上也可以是高效率的。大多数现代 *** 作系统遵循这种设计范畴，微软视窗就是一个很好的例子。另外还有XNU，运行在苹果Mac OS X上的内核，也是一个混合内核。
混合内核的例子：
BeOS 内核
DragonFly BSD
ReactOS 内核
Windows NT、Windows 2000、Windows XP、Windows Server 2003以及Windows Vista等基于NT技术的 *** 作系统
XNU
一些人认为可以在运行时加载模块的单核系统和混合内核系统没有区别。这是不正确的。混合意味着它从单核和微核系统中都吸取了一定的设计模式，例如一些非关键的代码在用户空间运行，另一些在内核空间运行，单纯是为了效率的原因。
外内核
外内核系统，也被称为纵向结构 *** 作系统，使一种比较极端的设计方法。
它的设计理念是让用户程序的设计者来决定硬件接口的设计。外内核本身非常的小，它通常只负责系统保护和系统资源复用相关的服务。
传统的内核设计(包括单核和微核)都对硬件作了抽象，把硬件资源或设备驱动程序都隐藏在硬件抽象层下。比方说，在这些系统中，如果分配一段物理存储，应用程序并不知道它的实际位置。
而外核的目标就是让应用程序直接请求一块特定的物理空间，一块特定的磁盘块等等。系统本身只保证被请求的资源当前是空闲的，应用程序就允许直接存取它。既然外核系统只提供了比较低级的硬件 *** 作，而没有像其他系统一样提供高级的硬件抽象，那么就需要增加额外的运行库支持。这些运行库运行在外核之上，给用户程序提供了完整的功能。
理论上，这种设计可以让各种 *** 作系统运行在一个外核之上，如Windows和Unix。并且设计人员可以根据运行效率调整系统的各部分功能。
现在，外核设计还停留在研究阶段，没有任何一个商业系统采用了这种设计。几种概念上的 *** 作系统正在被开发，如剑桥大学的Nemesis，格拉斯哥大学的Citrix系统和瑞士计算机科学院的一套系统。麻省理工学院也在进行着这类研究。
[编辑本段]无核
TUNES Project和UnununiumOS都进行无内核的尝试. 无内核的系统is not limited to a single centralizing entry point.
[编辑本段]参考
*** 作系统
[编辑本段]内核发展中的改进
红旗5就是2.6内核了，期待中
转：期待已久的2.6内核终于到来了。IBMLinuxTechnologyCenter的PaulLarson暗中关注那些让2.6成为有史以来最好内核的工具、测试和技术——从修正控制和回归测试到缺陷追踪和列表保持。
经过为期三年的积极开发，新2.6Linux内核最近已经发布了，在这期间，Linux内核的开发和测试方法发生了一些有趣的变化。当前，开发内核的方法在很多方面与三年前没什么不同。不过，一些关键变化已经使整体的稳定性和质量得到了提高。
源代码管理
历史上，从来没有出现过用于Linux内核的正式的源代码管理或修正控制系统。实际上，很多开发者实现了他们自己的修正控制器，但是并没有官方的LinuxCVS档案库，让LinusTorvalds检查加入代码，并让其他人可以由此获得代码。修正控制器的缺乏，常常会使发行版本之间存在“代沟”，没有人真正知道加入了哪些改变，这些改变是否能很好地融合，或者在即将发行的版本中哪些新内容是值得期待的。通常，如果更多的开发者可以像了解他们自己所做的改变一样了解到那些变化，某些问题就可以得到避免。
由于缺乏正式的修正控制器和源代码管理工具，使得很多人提议使用一个名为BitKeeper的产品。BitKeeper是一个源代码控制管理系统，很多内核开发者已经成功地将其应用于他们自己的内核开发工作中。最初的2.5内核发布后不久，LinusTorvalds开始试用BitKeeper，以确定它是否能满足他的需要。现在，主要的2.4和2.5内核的Linux内核源代码都是用BitKeeper来管理的。对大部分可能很少或者根本不关心内核开发的用户来说，这一点看起来可能无关紧要。不过，在一些情况下，用户可以受益于那些由于使用BitKeeper而带来的开发Linux内核的方法的改变。
使用BitKeeper的最大好处之一是补丁的融合。当多个补丁应用于同一基础的代码之上，并且其中一些补丁会对同一部分产生影响时，就可能会出现融合问题。一个好的源代码管理系统可以自动地完成其中一些更为复杂的部分工作，这样可以更快地融合补丁，并使更多的补丁加入到内核中。随着Linux内核开发者社区的扩大，非常需要修正控制器来帮助保持对所有改变的追踪。由于每个人都可以将这些改变集成到主要的Linux内核中，为保证补丁不会被遗忘并可以方便地融合和管理，BitKeeper等工具是必不可少的。
非常有必要使用一个实时的、集中的档案库来保存对Linux内核的最新更新。每一个被内核接受的改变或者补丁都被作为一个改变集被追踪。终端用户和开发者可以保存他们自己的源文件档案库，并根据需要可以通过一个简单的命令用最新的改变集进行更新。对开发者来说，这意味着可以始终使用最新的代码拷贝。测试人员可以使用这些逻辑的改变集合来确定哪些变化导致了问题的产生，缩短调试所需要的时间。甚至那些希望使用最新内核的用户也可以直接利用实时的、集中的档案库，因为现在一旦他们所需要的部件或缺陷修复加入到内核中，他们就可以马上进行更新。当代码融合到内核时，任何用户都可以提供关于这些代码的即时反馈和缺陷报告。
并行开发
随着Linux内核的成长，变得更加复杂，而且吸引更多开发者将注意力集中到内核的特定方面的专门开发上来，出现了另一个开发Linux方法的有趣改变。在2.3内核版本的开发期间，除了由LinusTorvalds发行的主要的一个内核树之外，还有一些其他的内核树。
在2.5的开发期间，内核树出现了爆炸式的增长。由于使用源代码管理工具可以保持开发的同步并行进行，这样就可能实现开发的部分并行化。为了让其他人在他们所做的改变被接受之前可以进行测试，有一些开发需要并行化。那些保持自己的树的内核维护者致力于特定的组件和目标，比如内存管理、NUMA部件、改进扩展性和用于特定体系结构的代码，还有一些树收集并追踪对许多小缺陷的纠正。
图1.Linux2.5开发树
这种并行开发模型的优点是，它使得需要进行重大改变的开发者，或者针对一个特定的目标进行大量类似改变的那些开发者可以自由地在一个受控环境中开发，而并不影响其他人所用内核的稳定性。当开发者完成工作后，他们可以发布针对Linux内核当前版本的补丁，以实现到此为止他们所完成的改变。这样，社区中的测试人员就可以方便地测试这些改变并提供反馈。当每一部分都被证明是稳定的之后，那些部分可以单独地，或者甚至同时全部地，融合到主要Linux内核中。
在实际应用中测试
过去，Linux内核测试方法围绕开放源代码开发模型进行。由于代码一经发布后就公开给其他开发者进行审查，因此从来没有出现过一个与其他形式的软件开发类似的正式的验证周期。这种方法背后的理论依据是“TheCathedralandtheBazaar”中所谓的“Linus法则”（请查阅参考资料以获得相关的参考），这一法则的内容为“众人的眼光是雪亮的”。换句话说，高力度的审查可以找出大部分真正的大问题。
然而实际上，内核有很多复杂的相互联系。即使进行了足够力度的审查，还是会漏过很多严重的缺陷。此外，最新的内核一经发布，终端用户可以（也经常是）下载并使用。2.4.0发布时，社区中很多人都提议进行更有组织的测试，以保证特定测试和代码审查的强度。有组织的测试包括运用测试计划、测试过程中的可重复性等等。使用所有的三种方法比最初只使用两种方法会带来更高的代码质量。
Linux测试项目
最早对Linux开始进行有组织测试的贡献者是Linux测试项目(LinuxTestProject，LTP)。这个项目的目的是通过更有组织的测试方法提高Linux的质量。这个测试项目的一部分是自动测试套件的开发。LTP开发的主要测试套件也叫做Linux测试项目。2.4.0内核发布时，LTP测试套件只有大约100个测试。随着2.4和2.5版本Linux的发展与成熟，LTP测试套件也正在发展和成熟。当前，Linux测试项目包括超过2000个测试，而且这个数字还在增长!
代码覆盖分析
现在所使用的新工具为内核提供了代码覆盖分析的功能。覆盖分析告诉我们，在一个给定的测试运行时，内核中哪些行代码被执行。更重要的是，覆盖分析提示了内核的哪些部分还根本没有被测试到。这个数据是重要的，因为它指出了需要再编写哪些新测试来测试内核的那些部分，以使内核可以得到更完备的测试。
持续多日的内核回归测试
在2.5的开发周期中，Linux测试项目所采用的另一个项目是，用LTP测试套件对Linux内核执行持续多日的回归测试。人们用BitKeeper创建了一个实时的、集中的档案库，以随时可以获得Linux内核的快照。在没有使用BitKeeper和快照时，测试人员不得不等到内核发布后才可以开始测试。现在，内核只要发生了改变，测试人员就可以进行测试。
使用自动化工具来执行持续多日的回归测试的另一个优点是，和上一次测试相比变化较小。如果发现了一个新的回归缺陷，通常会容易地检测出这个缺陷可能是哪个改变导致的。
同样，由于是最新的改变，因此它在开发者的脑海中印象还比较深——希望这能让他们更容易地记起并修订相应的代码。或许Linus法则应该有这样一个结论，有一些缺陷比其他缺陷更容易被发现，因为那些正是持续多日的内核回归测试所发现并处理的那些。在开发周期中和实际发布之前能够每天进行这些测试，这就使那些只关注完整发行版本的测试者可以将精力集中于更严重和耗时的缺陷。
可扩展测试平台
另外一个名为开放源代码开发实验室(OpenSourceDevelopmentLabs,OSDL)的团队也为Linux测试做出了重要的贡献。2.4内核发布后不久，OSDL创建了一个叫做可扩展测试平台(ScalableTestPlatform，STP)的系统。STP是一个自动化的测试平台，让开发者和测试者可以运行OSDL硬件之上的系统所提供的测试。开发者甚至可以使用这个系统来测试他们自己的针对内核的补丁。可扩展测试平台简化了测试的步骤，因为STP可以构建内核、设置测试、运行测试，并收集结果。然后得到结果以进行深入地比较。很多人无法接触大型系统，比如具有8个处理器的SMP机器，而通过STP，任何人都可以在像这样的大型系统上运行测试，这个系统(STP)的另一个好处就在于此。
追踪缺陷
自从2.4发布以来，对Linux内核的有组织测试最大的改进之一是缺陷追踪。过去，在Linux内核中发现的缺陷会报告给Linux内核邮件列表，报告给特定组件或者特定体系的邮件列表，或者直接报告给维护发现缺陷的那部分代码的个人。随着开发和测试Linux的人数的增加，这个系统的不足之处很快就暴露了出来。在以前，除非人们对缺陷的报告可以惊人地维持下去，缺陷经常被遗漏、遗忘或者忽略。
现在，OSDL安装了一个缺陷追踪系统（请参阅参考资料中的链接），来报告和追踪Linux内核的缺陷。系统经过了配置，这样当某个组件的缺陷被报告时，那个组件的维护者就会得到通知。维护者既可以接受并修复那个缺陷，或重新指定缺陷（如果最终确定实际上那是内核另外一部分的缺陷），也可以排除它（如果最终确定并不是真正的缺陷，比如错误配置的系统）。报告给邮件列表的缺陷还有丢失的危险，因为越来越多的电子邮件涌向那个列表。然而，在缺陷追踪系统中，始终有对每一个缺陷及其当前状态的记录。
大量信息
在为将来的2.6Linux内核进行开的过程中，除了这些自动化的信息管理方法之外，开放源代码社区的不同成员还收集和追踪了数量惊人的信息。
例如，在KernelNewbies站点上创建了一个状态列表，来保持对已经提出的内核新部件的追踪。这个列表包含了以状态排序的条目，如果它们已经完成了，则说明它们已经包含在哪个内核中，如果还没有完成，则指出还需要多长时间。列表上很多条目的链接指向大型项目的Web站点，或者当条目较小时，链接指向一个解释相应部件的电子邮件信息的拷贝。
内核版本历史
到现在我们很多人已经熟悉了Linux内核的版本编号系统，不过AndriesBrouwer提醒了我们实际上它是如何不规则的。
Linux的第一个公开版本是1991年10月的0.02版本。两个月以后，在1991年12月，Linus发布了0.11版本，这是第一个可以不依赖于Minix就可以使用的独立内核。
0.12版本发布一个月以后，在3月，版本号跳到了0.95，反映出系统正变得成熟。不仅如此，直到两年后，也就是1994年3月，具有里程碑意义的1.0.0才完成。
大约从这时起开始使用两“路”编号方法标注内核的开发。偶数号的内核（比如1.0、2.2、2.4，现在是2.6）是稳定的，“产品”型号。同时，奇数号的内核版本（1.1、2.3）是前沿的或者“发展中的”内核。直接最近，一个稳定的内核发布以后几个月就开始新内核的开发工作。然而，2.5的开发工作是在2.4完成后几ten个月以后才开始的。
那么我们什么时候可以期待2.7呢？这不好说，不过在KernelTrap已经有了一个讨论的头绪。
在那之前，您可以阅读RagibHasan的文章以深入了解Linux的历史。
同时，“post-halloween文档”告诉用户即将到来的2.6内核有哪些可期待的东西（参阅参考资料中的链接）。post-halloween文档的大部分讨论内容是用户需要注意的主要改变，以及需要更新的系统工具（为了利用它们）。关心这一信息人的主要是那些期望提前了解2.6内核中有哪些内容的Linux发行商，还有终端用户，这可以让他们确定为了能利用新部件是否有需要升级的程序。
KernelJanitors项目保持了（实际上现在还在保持）一个列表，内容是需要修复的较小缺陷和解决方法。这些缺陷解决方法中大部分是由于向内核打较大的补丁时需要改动很多部分代码而导致的，比如有些地方会影响设备驱动程序。那些新近从事内核开发的人开始时的工作可以选择列表中的条目，这样让他们可以通过小项目学习如何编写内核代码，同时有机会为社区做出贡献。
还有，在另一个预发布的项目中，JohnCherry追踪了在对每个已经发布的内核版本进行编译时发现的错误和警告。这些编译统计数字随着时间的流逝一直持续下降，而且，以系统的形式来发布这些结果使得所取得的进展一目了然。在很多情况下，可以像使用KernelJanitors列表一样来利用这些警告和错误消息中的一部分，因为编译错误通常是由小的缺陷引起的，需要一些努力去修复。
最后，还有AndrewMorton的“must-fix”列表。由于他已经被选定为2.6内核发布后的维护者，他运用他的特权概括地列出了那些他认为在最终的2.6内核发布前最迫切需要解决方案的问题。must-fix列表中包含了内核Bugzilla系统中的缺陷，需要完成的部件，以及其他已知的问题，这些问题如不解决将阻碍2.6发布。这一信息可以帮助指明在新内核发布前还需要哪些步骤；对那些关心这一万众期待的2.6内核发布何时能完成的人来说，它还可以提供有价值的信息。
自从去年年底2.6内核发布以后，这些资料中有一些已经明显不再进行维护了。其他的相关工作在主要版本发布后仍未结束，还要继续进行后期的更新。有趣的是能看到哪些又被重新提起，有了哪些革新，我们又一次接近了一个主要发布版本。
结束语
多数人在考虑内核的一个新的稳定版本时，第一个问题通常是“这一版本中有什么新东西吗？”实际上除了一些新特性和修复之外，在幕后还有一个随着时间而不断改进的过程。
在Linux社区中，开放源代码开发日益兴旺。致力于Linux内核和其他方面工作的编码者之间联系是松散的，这就使得团队可以成功地适应变化。在许多方面，相对于已经完成的很多单个的改进和缺陷修复而言，Linux的开发和测试方法——尤其是这些方法随时间的推移得到了改进——对新内核的可靠性影响更为深远。
[编辑本段]天文学意义上的内核
从天文学意义上讲，一颗行星（或一颗恒星）都有两个核：内核和外核，星体内核的温度可高达几千摄氏度。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）