标签 GNU 下的文章

如何加入Linux内核开发社区(5)

本文翻译自The Linux Foundation的《How to Participate in the Linux Community》(基于2012-03-21最新版本),原作者为Jonathan Corbet(corbet@lwn.net)。 下面是该文章第五章节的中译文。

 
5、发布补丁
 
迟早有一天你的工作将提交到开发社区进行评审,并最终合入内核主线。不出所料,内核开发社区在发布补丁方面已经逐步形成了一套约定和程序;遵循这 些约定和程序将使得开发者们的工作变得更加轻松。本文将尝试适当详尽地对这方面的内容进行说明;更多内容可以参考内核文档目录下的 SubmittingPatches、SubmittingDrivers和SubmitChecklist文档。
 
5.1、何时发布
 
一直存在这样一种诱惑:在补丁完全"具备条件"之前不要发布补丁。对于简单的补丁,这不是问题。但如果补丁的工作比较复杂,则在补丁完成前,很多事情需要从开发社区获取的反馈中得到。因此你应该考虑将正在进行中的工作发布给社区,或者甚至可以提供一个可用的git源码树,让那些对你的补丁感兴趣的开发者随时了解到你的工作进展。
 
当发布一些尚不具备被合入内核条件的代码时,最好在发布时如实告知社区。同时要说明还有哪些主要工作尚待去做以及所有已知的问题。与已完成的补丁相比,那些已知尚未完成的补丁获得的青睐更少,但那些确实提出想法的人能够帮助你始终工作在正确的方向上。
 
5.2、在补丁创建之前
 
在你考虑将补丁发布到开发社区之前,有一些事情是需要预先做的,这些事情包括:
 
  * 尽你所能的对补丁代码进行测试。充分利用内核调试工具,确保内核可以在所有合理的配置选项组合下编译,使用跨平台编译器进行不同体系的构建,等等。
 
  * 确保你的代码与内核编码风格准则兼容。
 
  * 你的变化会对内核性能有影响吗?如果有的话,你应该运行基准测试来看看你的改变对内核的具体影响(或带来的好处);补丁中应该包含这个测试结果的总结。
 
  * 确保你有权发布这个补丁代码。如果代码是为某个雇佣者开发的,雇佣者很可能才是这段代码的真正拥有者,那么雇佣者必须同意补丁在GPL许可证下发布。
 
一般来说,在发布代码之前多做一些考虑总是会在短时间内让你的付出收到回报的。
 
5.3、补丁准备
 
补丁发布准备的工作量可能十分巨大,不过,再重申一遍,即便是短期内尝试在这个阶段节省时间通常也是不可取的。
 
补丁必须是为某一个特定的内核版本而准备的。通常,补丁应该基于linus的git树中的当前主线版本。但为了能让补丁得到更为广泛的测试和评审,制作针对-mm、linux-next或某个子系统树的补丁版本可能会变得很必要。针对其他源码树的补丁可能需要大量工作来解决代码冲突以及处理API的改变,这取决于你的补丁所在的领域以及其他方面的当前进展情况。
 
只有最简单的改变才应该以一个单独的补丁形式提供;其他所有补丁都应该由一系列合理的改变组成。拆分补丁是一门艺术;一些开发者花费很长时间考虑如何以一种开发社区期望的方式进行补丁拆分。下面是一些经验法则,但却相当有帮助:
 
  * 你发布的补丁序列决不应该仅仅是你的版本控制系统下的一系列改变。相反,你应该考虑这些改变的最终形式,将他们分成有意义的若干部分。开发者只对离散的、自完备的改变感兴趣,而不是你提供的这些改变的路径信息。
 
  * 每个逻辑上独立的改变都应该以一个单独的补丁提供。这些改变可小("为这个结构体增加一个字段")可大(例如,增加一个重要的新驱动程序),但它们都应该是小概念的并且可用一行文字描述的。每个补丁所带来的改变都应该可以被独立评审和独立验证的。
 
  * 这里再次重申一下上面的准则:不要将不同类型的改变混在一个补丁中。如果一个单独的补丁修复了一个极其重要的安全bug、重新调整了一些结构体并且重新对代码进行了格式化,那么这个补丁很有可能被置之不理,这个重要的修复也将会丢失。
 
  * 每个补丁都应该生产出一个可以正确编译和运行的内核;即使你的补丁序列在中间被打断,结果仍然应该是一个可工作的内核。部分应用一个补丁序列是一种常见的情况,尤其是当"git bisect"工具被用于查找regression时;如果补丁序列被打断的结果是一个损坏的内核,则会导致那些参与追查内核问题的开发者和用户的工作更加困难。
 
  * 但也不要做的太过分。最近一个开发者将一个文件的多处修改放在500个补丁中发布 — 这一行为并没有使他成为内核邮件列表上最受欢迎的人。只要仍然包含一个单一的*逻辑*改变,一个单一的补丁也可以适当地大些。
 
  * 人们可能很想通过一系列的补丁来为内核增加一个完整的新基础设施,但直到这个系列的最后一个补丁生效,这个新设施才好用。这种想法应该尽可能的避免;如果这一系列补丁新增了regression,折半问题查找方法会把最后一个补丁视为导致问题罪魁祸首,即使真正的bug发生在别处。所以无论何时,添加了新代码的补丁都应该使得那些代码立即可用。
 
创建一个完美补丁的工作可能是一个令人沮丧的过程,这个过程将在"真正的编码工作"完成之后花费大量的时间和思考。但一旦正确地完成,你会感觉这个时间花费是值得的。
 
5.4、补丁格式化
 
现在,你已经有了一系列准备发布的完美补丁,但工作还远没有完成。每个补丁都需要被格式化为一条消息,这条消息可以快速清晰地将补丁的目的阐述给其他人。因而,每个补丁将由下面几个部分组成:
 
  * 一个可选的"From"行,用于指出补丁作者的名字。这一行只是在你通过mail对别人的补丁进行评论时才是必要的,并且在有疑问时加上这一行没有什么坏处。
 
  * 一行关于补丁做什么的描述。这行消息应该足以让一个读者在无需其他上下文信息提示的情况下确定这个补丁的范围;它就是将记录在简易格式的变更日志(changelog)中的那一行。这个消息的格式通常是以相关子系统的名字开头,后面跟随着这个补丁的目的。例如:
 
     gpio: fix build on CONFIG_GPIO_SYSFS=n
 
  * 在补丁内容的详细描述之后跟随一个空行。补丁内容描述的长度可以根据需要而定;这份描述应该说明补丁做了哪些事情以及为何该补丁应该被应用于内核。
 
  * 一个或多个标签(tag)行,至少应该有一个来自补丁作者的signed-off-by:行。接下来会有对标签(tags)的更为详细的说明。
 
上面的三项通常应该是提交补丁代码到版本控制系统时所使用的文本。后面跟着:
 
  * 补丁本身,使用统一标准的("-u")补丁格式。结合"-p"选项使用diff会将函数名字与改变相关联,结果可以使得补丁更易于被其他人阅读。
 
你应该避免在补丁中包含无关文件(比如那些由编译过程产生的文件或编辑器备份文件)的改变。Documentation目录下"dontdiff"在这方面可以提供帮助;在执行diff命令时使用"-X"选项。
 
上面提到的标签(tag)用于描述不同开发者是如何与此补丁的开发相关联的。在SubmittingPatches文档中有关于这方面的详细说明;下面是一个简要的总结。每行的格式是这样的:
 
  tag: Full Name <email address> optional-other-stuff
 
常用的标签如下:
 
  * Signed-off-by: 这是一个开发者有权提交可以被内核合并的补丁的证明。表示同意"Developer's Certificate of Origin"协议,该协议的全部文本内容可以在Documentation/SubmittingPatches中找到。没有正确signoff的代码将无法合并到内核主线中去。
 
  * Acked-by: 表明另外一名开发者(通常是相关代码的维护者)认可该补丁适合合并到内核中。
 
  * Tested-by: 说明这个人已经测试过这个补丁并发现它可以工作。
 
  * Reviewed-by: 这个签名的开发者已经对这个补丁的正确性进行了评审;在Documentation/SubmittingPatches中有关于"Reviewer's statement(评审者的声明)"的详尽描述。
 
  * Reported-by: 说明了这个补丁所修正的问题是哪个用户提出的;这个标签用于赞扬那些对内核代码进行测试并让大家知道什么时候内核无法正确工作的人(常常是未得到正确评价的)。
 
  * Cc: 列出哪些人会接收到一份补丁的拷贝并有机会对补丁进行评判。
 
在向你的补丁中添加标签时要小心:只有Cc:标签适合在没有得到指定名字的人的显式许可下添加。
 
5.5、发送补丁
 
在通过mail发送你的补丁之前,还有其他几个事情需要你小心处理:
 
  * 确认你的邮件发送程序不会破坏这个补丁?那些被邮件客户端工具无缘无故进行空白转换或换行的补丁将无法在另一端适用,并且常常无法被详细地检查。如果在这方面有任何疑问,可以先将补丁邮寄给你自己并确认补丁可以原封不动地展现。
    
   Documentation/email-clients.txt中有一些关于如何使特定的邮件客户端程序适合发送补丁的提示。
 
  * 确认你的补丁中已经没有愚蠢的错误了吗?你应该一直使用scripts/checkpatch.pl检查你的补丁并处理这个脚本提出的各种抱怨。不过请记住,虽然checkpatch.pl是对内核补丁应有的形式进行了大量思考后的体现,但它并不比你更聪明。如果为了修复一个checkpatch.pl的抱怨而使得代码变得更加糟糕,那就不要这么做。
 
补丁应该总是以普通文本形式发送。请不要以附件形式发送补丁;那样将会让评审者在回复中引用补丁部分内容时更加困难。直接将补丁放入邮件消息中即可。
 
在邮件发送补丁时,给那些可能对该补丁感兴趣的人发送一份补丁拷贝是很重要的。与其他一些项目不同,Linux内核项目鼓励大家在发送过多补丁拷贝方面犯错;千万不要假设相关人员会在邮件列表上看到你发布的补丁。尤其是,补丁拷贝应该发送给:
 
  * 受影响的子系统(s)的维护者(们)。前面曾经提到过,MAINTAINTERS文件是寻找这些维护者们的起点。
 
  * 其他曾工作在相同领域的开发者–尤其是那些可能正在此领域工作的人。使用git查看哪些人曾经修改过你正在修改的文件,这样做可能会很有帮助。
 
  * 如果你的补丁应对的是一个bug报告或一个特性请求,也发送一份补丁拷贝给原始问题或请求发起者。
 
  * 发送一份补丁拷贝到相关的邮件列表,如果找不到此类列表,那就发送到linux-kernel邮件列表。
 
  * 如果修复了一个bug,考虑一下该修复是否应该进入到下一个内核稳定版的更新版本中。如果应该进入,你应该给stable@kernel.org发送一份补丁的拷贝。同时也要在补丁内部标签中加入一条:"Cc: stable@kernel.org";这将使得内核稳定版维护小组在你的修复进入主线时收到一个通知。
 
当为一个补丁选择接收者时,最好对谁将最终接受并合并你的补丁做到心中有数。虽然将补丁直接发给Linus Torvalds并让他合并你的补丁是可能的,但事情通常不是这样做的。Linus非常忙,而且有各个子系统的维护者负责监视内核的某个特定部分。通常你将会让那个维护者合并你的补丁。如果没有专门的维护者,Andrew Morton常常作为补丁的最后依赖目标。
 
补丁需要一个好的标题行。补丁标题行的标准格式类似:
 
  [PATCH nn/mm] subsys: one-line description of the patch
 
这里"nn"是补丁的序号,"mm"是这个补丁序列的补丁总数,"subsys"是补丁所影响的子系统的名字。很显然,对于一个单一独立的补丁来说,nn/mm可以被省略的。
 
如果你有一个重要的补丁序列要提交,通常应该先发送一个介绍性的描述作为第零部分。但这个约定并不是被普遍遵循的;如果你使用这种方式,记住介绍部分的信息不会进入到内核的变更日志(changelog)中。因此要保证补丁自身包含完整的变更日志(changelog)信息。
 
通常,一个由多部分组成的补丁的第二以及接下来的部分应该以第一部分的答复(reply)的形式发送,这样他们在接收端才能组合在一起。像git和quilt这样的工具支持群发一批具有适当线索的补丁的命令。但是,如果你的补丁序列很长,且使用git,请使用–no-chain-reply-to命令行选项以避免创建过深的嵌套。

如何加入Linux内核开发社区(4)

本文翻译自The Linux Foundation的《How to Participate in the Linux Community》(基于2012-03-21最新版本),原作者为Jonathan Corbet(corbet@lwn.net)。 下面是该文章第四章节的中译文。

 
4、正确地编写代码
 
关于那个可靠的面向社区的设计过程我们已经说的够多了,任何内核开发项目的证据都是最终的代码。被其他开发者检查的是代码,被(或没有被)合并到主线树的也是代码。因此是代码质量决定了内核开发项目最终的成功。
 
这一节我们会对内核编码过程进行剖析。我们会首先看看内核开发者可能会出错的几个方面;接下来我们会将关注点转向如何正确地做事以及一些可以在此过程中帮助到我们的工具。
 
4.1、陷阱
 
* 编码风格
 
内核早已拥有了一套标准的编码风格,在Documentation/CodingStyle文件中有关于编码风格的说明。但长久以来,这个文档中所描述的风格策略充其量被视为是建议性的。因此内核中有大量的代码并不符合编码风格准则的要求。这类代码的存在给内核开发者设下了两个陷阱。
 
第一个陷阱是相信内核编码标准无关紧要并且不是强制性的。而这事儿的真实情况是如果代码没有按照标准编写,新代码将很难被添加到内核中去;许多开发者会要求代码应该在评审之前被重新格式化。像内核这么大规模的代码库需要一种格式一致的代码,这样才能保证开发人员可以快速地理解代码库中的任何一部分。因此这里没有给奇怪格式代码生存的空间。
 
有时,内核编码风格会与某个雇佣者要求的风格相冲突。这种情况下,在代码可以被合并到内核之前,内核编码风格将取得胜利。将代码放入内核意味着你将在多个方面放弃一些对代码的控制,这其中就包括对代码风格的控制。
 
另外一个陷阱是假定那些已经存在于内核中代码急需修复代码风格。开发者在开始阶段很可能会将创建修复代码风格的补丁作为一种熟悉开发过程的手段,或作为一种将自己的名字写进内核Changelog文件的手段,或者二者兼具。但纯粹的代码风格修复补丁会被开发社区视为噪音;并很可能会被冷眼对待。因此最好杜绝这类补丁。比较自然合理的做法是在因其他原因修改某段代码时顺便修复其代码风格,不要为了自身的考虑而去修改代码风格。
 
这个代码风格文档也不应该被当成绝对不能违背的准则。如果你有违反这一风格的好理由(例如,某一行如果按照80列的限制做拆分,可读性就会变得很差),那就按照你的想法去做吧。
 
* 抽象层
 
计算机科学教授教育学生应广泛使用抽象层以实现系统的灵活性和信息隐藏。当然内核也广泛使用了抽象;如果不这样的话,没有哪个具有百万行代码的项目可以实现并存活下来。但经验证明过度或过早抽象可能同过早优化一样是有害的。抽象应该被用在需要的层次上并且不要再深入了。
 
在一个简单的层次上,考虑这样一个只有一个参数的函数,调用者在调用该函数时参数总是传0。只是在有人最终需要使用这个函数提供的额外的灵活性时人们才会记起那个参数。但是到了那时,很可能实现了这个额外参数的代码已经被一种未被察觉的微妙方式改变了– 因为它从未被使用过。或者,当对这个额外灵活性的需求增多时,它的行为已经不再是开发者早先期望的那样的了。核心开发者将会按惯例提交补丁删除无用的参数;通常来讲,这些参数从一开始就不应该加上。   
 
那些隐藏了对硬件访问的抽象层尤其不被赞成使用,因为这些抽象层常常允许一个驱动程序的主要部分被多个操作系统使用。这些抽象层使代码更加难以理解并且很可能引入性能问题;他们不应该被归入Linux内核范畴。
 
另一方面,如果你发现自己正在从另一个内核子系统拷贝大量重要代码,那么是时候问问你自己将一些代码抽出放入单独的库或在更高层次上实现那个功能是不是更有意义。在内核内部复制相同的代码没有价值。
 
* #ifdef以及预处理器的一般使用
 
C预处理器对一些C程序员来说是一种强大的诱惑,这些C程序员将预处理器看作是一种在源文件中嵌入灵活性的手段。但是预处理器不是C语言,过度地使用预处理器将导致代码可读性大大降低,同时也使得编译器进行正确性检查的难度大大增加了。过度使用预处理器通常是一种信号,预示着代码需要一些整理了。
 
采用#ifdef的条件编译确实是一种强大的特性,并且它已经被用于内核代码中。但我们仍然不希望看到那些不受限制地使用#ifdef代码块的代码。一般来说,#ifdef应该尽可能地被限制在头文件中使用。条件编译代码可用于那些尚未实现完毕的函数,使之变为空函数。编译器接下来会在优化过程去掉对这些空函数的调用。结果我们将得到更加简洁和易理解的代码。
 
C预处理器宏会带来一些危害,包括可能带有副作用的多次表达式求值以及类型不安全。如果你总想定义一个宏,不妨考虑创建一个内联函数替代这个宏,两者的执行结果是相同的,但内联函数可读性更好,也不会多次对其参数进行求值,并且支持编译器对参数以及返回值进行的类型检查。
 
* 内联函数
 
不过内联函数也有他的一个危害之处。程序员们可能会迷恋于因省略函数调用而带来的效率提升,并在源文件中到处使用内联函数。然而那些函数实际上可能降低系统性能。由于在每个调用处这些函数的代码都会被复制一份,最终会导致编译后的内核尺寸膨胀。相应地,这会给处理器的内存缓存带来压力,并可能显著降低执行性能。通常,内联函数应该非常小并且相对较少。毕竟函数调用的消耗并不是那么大;大量创建内联函数是过早优化的一个典型例子。
 
一般来说,内核程序员忽略缓存效果是冒着风险的。在数据结构课程上学到经典的时空开销转换并不适用于当代的硬件。空间即是时间,因为尺寸更大的程序与更加紧凑的程序运行的要更慢。
 
* 锁
 
2006年5月,Devicescape网络协议栈在GPL的授权下大张旗鼓地发布了,并且等待着被主线内核合并。这次捐赠受到了社区的极大欢迎;因为当时Linux对无线网络的支持被认为是不符合标准的,而Devicescape协议栈则许诺修复这一问题。但直到2007年6月份(2.6.22),这份代码也没有被真正合并到内核主线中。究竟发生了什么呢?
 
这份代码显现出诸多闭门造车的迹象。然而一个更为严重的问题是它不是针对多处理器系统设计的。在这份网络协议栈(现在叫作mac80211)能够被合入主线之前,社区需要一个锁方案来重新对该代码进行改造。
 
曾几何时,Linux内核代码的开发可以无需考虑多处理器系统的并发问题。不多,现在,就连这篇文章也是在一个双核处理器笔记本上编写的。即使在单处理器系统上,那些为了改善响应速度的工作也会提升并发在内核内部的级别。那些无需考虑锁的内核编码的日子已经一去不复返了。
 
任何可被不止一个线程并发访问的资源(数据结构、硬件寄存器等)都必须用锁保护起来。开发新代码时应牢记这一要求;即成事实后再进行锁改造将会是一个特别困难的任务。内核开发者应该花时间去好好地了解一下已经存在的锁原语以足够自己为开发任务挑选一个合适的工具。那些缺少对并发关注的代码在通往内核主线的道路上会走得更加艰难。
 
*Regressions(退步)
 
最后一个值得一提的危害是:作出一些给现有用户带来破坏的改变(可能带来较大的改进)。这类改变被称作"regression(退步)",内核主线最厌恶regression。如果regression不能在短时间内修复,那些导致regression的改变将极少例外地被清退出内核。最好从一开始就避免regression。
 
如果因某个regression所带来的改变而受益的人比因其受害的人更多,这个regression是否可能被合法化呢?这里常常引发社区的争论。为什么不可以做出这样一个改变呢:它能给10个系统带来新功能,但只破坏其中一个系统?对于这个问题,Linus在2007年7月给出的最佳答案:
 
所以,我们不能通过引入新问题的方式来修复bug。那种方式很愚蠢,根本没有人知道你实际上是否带来的真正的进步?是前进两步,后退一步,还是前进一步后退两步呢?(http://lwn.net/Articles/243460/).
 
一个尤其让人生厌的regression是那种对用户空间ABI(译注:Application Binary Interface,应用程序二进制接口)的改变。一旦一个接口被导出到用户空间,它就必须被无限期地支持。这种情况让创建用户空间接口变得尤其具有挑战性:因为它们不能被以一种不兼容的方式改变,它们必须在一开始时就被正确地创建。为此,用户空间接口总是需要大量的考量、清晰的文档以及大范围的评审。
 
4.2、代码检查工具
 
至少在目前,编写无错代码仍旧是一个几乎无人可及的理想。然而,我们可以期望的是,在代码进入内核主线之前,尽可能多的捕捉和修复bug。为达到此目的,内核开发者们设计和实现了一系列工具,这些工具可以自动地捕捉到各种隐蔽的问题。被计算机捕捉到的问题后续将不会折磨用户,因此,顺理成章,我们应该尽可能多地使用这些自动化工具。
 
第一步就是留心编译器给出的警告。当前版本的gcc可以检测出(并针对…警告)大量潜在的错误。这些警告常常意味着真实的问题。一般来说,提交评审的代码应该不会再产生任何编译器警告了。当关闭警告时,注意务必理解警告的真实原因并且避免进行那种只去除警告但未真正解决问题的"修复"。
 
注意不是所有编译器警告是默认打开的。使用"make EXTRA_CFLAGS=-W"来编译内核以获得所有警告设置。
 
内核提供了多个用于打开调试特性的配置选项;其中大多数选项可以在"kernel hacking"子菜单中找到。对于那些用于开发或测试目的的内核来说,多数此类选项都应该被打开。尤其是,你应该打开:
 
  * ENABLE_WARN_DEPRECATED、 ENABLE_MUST_CHECK和FRAME_WARN。打开这几个选项可以获得一些额外的警告设置,这些设置针对的问题诸如使用了不赞成使用的接口或忽略了一个重要的函数返回值等。这些警告的输出可能比较冗长罗嗦,但其他内核部分的警告不会如此,你大可不必担心。
 
  * DEBUG_OBJECTS会增加代码来跟踪内核创建的各种对象的生存期,并且在对象出现故障时给出警告。如果你添加了一个子系统,该子系统创建(或导出)了属于自己的复杂对象,请考虑为该子系统加上对对象调试基础设施的支持。
 
  * DEBUG_SLAB可以查找到大量关于内存分配以及使用的错误;它应该在大多数开发专用的内核上使用。
 
  * DEBUG_SPINLOCK、DEBUG_SPINLOCK_SLEEP和DEBUG_MUTEXES可以找到很多常见的锁错误。
 
内核中还有很多其他调试选项,其中一些将在下面讨论。有些调试选项将对内核性能产生显著的影响,不应该被一直使用。不过,花些时间了解已有的调试选项很可能会在短时间后给你带来几倍的回报。
 
一个重量级的调试工具就是锁检查器,或叫做"lockdep"。这个工具可以跟踪系统中每把锁(自旋锁或互斥锁)的加锁和解锁操作、相对于彼此的加锁顺序、当前的中断环境以及更多其他内容。它还能保证始终以相同的顺序进行加锁,保证对所有情况应用相同的中断假设等等。换句话说,lockdep可以找出许多系统可能偶尔死锁的场景。在一个已经部署的系统上,这类问题是很让人头疼的(对开发者和用户都);lockdep支持以一种自动的方式提前发现这类问题。任何重要的代码在提交合入前都应该在lockdep工具的监控下运行。
 
作为一名勤奋的内核程序员,你将毫无疑问地检查任何可能失败的操作(诸如内存分配)的返回状态。然而,事情的真实情况是,因此进行的失败恢复的路径很可能根本没有经过测试。未测试的代码极可能是有问题的代码;如果所有失败处理路径被执行过多次,你才可能会对你的代码更加有信心。
 
内核提供了一个故障注入的框架,它可以制造故障,特别是涉及内存分配的地方。在开启故障注入的情况下,内存分配可以按照配置的比例执行失败;这些失败可以被限制在一个特定的代码范围中。在故障注入框架开启的前提下运行可以让程序员们看到代码在出现错误的情况下是如何作出反应的。更多关于如何使用这个工具方面的内容可参见Documentation/fault-injection/fault-injection.txt。
 
其他类错误可以通过"sparse"静态分析工具查找到。使用sparse,程序员在混淆用户空间与内核空间地址,混用大端法和小端法表示的数量值以及传递对一组特定位标志有要求的整型值时会收到警告。sparse必须单独安装(如果你用的发行版不包含sparse的话,你可以在http://www.kernel.org/pub/software/devel/sparse/下面找到它);当你执行的make命令包含"C=1"时,sparse会被执行。
 
其他有关可移植性类别的错误最好在代码进行针对其他体系的编译时发现,如果手头没有S/390系统或Blackfin开发板的话,你仍然能够执行这个编译步骤。一套适合x86系统的跨平台编译器可以在下面页面中找到:
 
http://www.kernel.org/pub/tools/crosstool/
 
花些时间安装和使用这些编译器可以帮助你避免日后难堪。
 
4.3、文档
 
文档常常不仅仅是内核开发规则的例外。即使这样,充足的文档会有助于你的新代码合并入内核,有助于其他开发人员理解你的代码并且也会对你的用户带来帮助。在很多情况下,增加文档已经变成了必不可少的强制要求了。
 
任何补丁的文档的第一部分内容应该是与之相关的变更日志(changelog)。日志记录应该描述解决了什么问题、解决方案的构成、补丁相关的人员、任何对性能产生的影响以及其他理解该补丁所需要的内容。
 
任何添加了新用户空间接口–包括新的sysfs或/proc文件–的代码都应该包含一份关于那个接口的说明文档,以便用户空间程序员了解这个接口。关于这类文档应该如何进行格式化以及应该提供哪些信息,请参见Documentation/ABI/README。
 
Documentation/kernel-parameters.txt描述了内核引导阶段的所有参数。任何添加新参数的补丁都应该在该文档中添加适当的记录。
 
任何新增的配置选项都必须伴随一份帮助文字,这些文字应该清楚地说明这些选项的功用以及用户何时可能会对它们进行选择。
 
在多个子系统中使用的内部API信息需要以一种特定格式的注释的方式记录到文档中;这些注释可以被"kernel-doc"脚本以多种方式提取和格式化。如果你正在一个具有kerneldoc注释的子系统上进行开发,你应该视具体情况为外部可用的函数维护和添加注释。即使在尚没有文档记录的区域,为将来添加kerneldoc注释也是无害的;实际上,对于那些刚进入内核开发领域的开发者来说,这可能是一种有益的工作。关于这些注释的格式以及如何创建kerneldoc模板的说明可以参见Documentation/kernel-doc-nano-HOWTO.txt。
 
读过大量现有内核代码的人常常都会注意到内核代码严重缺少注释。对新代码中注释的期望远远高于之前的代码;没有注释的代码想要合入内核会更加困难。但即便如此,那些具有冗长注释的代码想进入内核依旧是希望渺茫。代码自身应该具有良好的可读性,同时使用注释解释那些不明显、更具技巧的特性。
 
某些地方应该始终使用注释。内存栅栏(memory barrier)的使用应该始终伴随一行注释,解释这里使用栅栏的必要性。数据结构的加锁规则一般需要在某处给予解释。通常主要的数据结构都需要详细的文档。小块代码间的不明显的依赖需要被指出。任何可能诱使一个代码看门人(code janitor)作出不合规矩地"清理"的地方都需要一个注释解释为何这里要这么做。等等。
 
4.4、内部API变化
 
除非是最为严重的情况下,内核提供给用户空间的二进制接口都不能被破坏。相反,内核内部的编程接口则是经常改变的,并且可以在有需要的情况下被改变。如果你发现自己围绕着一个内核API进行开发或只是没有使用一个特定的功能,因为该功能无法满足你的需要,这很可能是一个API需要被改变的信号。作为一个内核开发者,你有权做出这样的改变。
 
当然,这里还是有一些隐患的。API可以被改变,但这种改变应该是合理的。因此任何导致一个内部API变化的补丁都应该伴随一个描述,该描述包括改变了什么以及这种改变的必要性。这类改变还应该被拆分成多个独立的补丁,而不是放在一个大补丁中。
 
另外一个隐患是改变内部API的那个开发者通常还要负责修正内核树上那些因API改变而被破坏的代码。对于一个被广泛使用的函数来说,这个责任可能会意味着成百或上千处改变– 多数都可能是与其他开发者所编写的代码的冲突。不用说,这也是一个工作量庞大的工作,因此最好确认你对API改变的合理性是可靠的。
 
当做出一个不兼容的API改变时,开发者应该尽快能的保证编译器可以捕捉到那些尚未更新的代码。这将有助于你在树内找到所有使用这个接口的代码。它还会警告那些树外代码的开发者有一个需要他们处理的新变化。虽然树外代码的支持不是内核开发者需要担心的事情,但我们还是不要让树外代码的开发者的开发工作变得更难。 

如何加入Linux内核开发社区(3)

本文翻译自The Linux Foundation的《How to Participate in the Linux Community》(基于2012-03-21最新版本),原作者为Jonathan Corbet(corbet@lwn.net)。 下面是该文章第三章节的中译文。

3、早期规划

当考虑一个Linux内核开发项目时,人们可能很想尽快投入并开始编码。但和任何重要的项目一样,推动项目成功的大量基础工作需要在第一行代码编写之前被精心安排好。一些在早期计划和沟通阶段所花费的时间可能在后期为你节约更多的时间。

3.1、明确问题

和任何工程项目一样,一次成功的内核改进都始于对所要解决问题的清晰描述。在某些情况下,这一步很简单:例如,当需要一块特定硬件的驱动程序时。但在其他情况下,人们很可能把真正的问题与提议的解决方法混为一谈,这将带来更多麻烦和困难。

考虑一个例子:几年前,Linux音频开发者试图找到一种方式使得音频应用在运行时不会因系统过分延迟而导致丢帧或其他人造干扰。在他们给出的解决方案 中,他们打算在Linux Security Module (LSM)框架中挂接一个模块;这个模块可以配置某特定应用是否具有访问实时调度器的权限。他们将实现后的模块发布到linux-kernel邮件列表 中,瞬即就遇到了问题。

对于这些音频开发者来说,安全模块(security module)足以可以解决他们目前遇到的问题。但对于更广大的内核开发社区而言,这却是一种对LSM框架(该模块不是用来给那些本就不会具有权限的进程 授权的)的误用,同时对系统稳定也是个风险。因此社区开发者们的首选方案是短期内通过rlimit机制访问实时调度,并将减少延迟作为长期工作。

然而,音频社区不愿放弃他们已经实现的方案,他们不愿接受其他选择。由此导致的分歧让这些开发者不再对整个内核开发过程抱有幻想;其中一个开发者回到audio邮件列表并发表了下面这段话:

这里的确有很多优秀的Linux内核开发者,但他们往往是一群大声喊叫的傲慢自大的傻瓜。和这些人沟通用户需求简直就是浪费时间。他们都太过聪明,根本听不进去凡人的建议。

(http://lwn.net/Articles/131776/).

现实的情况却不是这样的;与一个特定的模块相比,内核开发者们更加关心系统的稳定性、长期维护以及找到问题的正确解决方案。这个故事的寓意是把重点放在问题上,而不是某个特定的方案,并且在实现方案前与开发社区进行充分的讨论。

因此,当考虑一个内核开发项目时,每个开发者都应该首先得到下面几个问题的答案:

  * 要解决的问题到底是什么?
  * 这个问题究竟影响了哪些用户?这个方案到底解决了哪些用例?
  * 当前在解决这个问题上内核是如何无法达到要求的?

只有这样,开始考虑可能的方案才是有意义的。

3.2、早期讨论

当规划了一个内核开发项目时,在开始实现前保持与社区的充分讨论是十分有意义的。早期沟通可以从许多方面帮你节省时间和省去麻烦:

  * 内核很可能以你未曾听说过的方式解决问题。Linux内核规模巨大,有一些特性和能力并非是显而易见的。另外不是所有的内核能力都有完好的文档的,你很容 易错过一些事情。 笔者就曾经见到过有人提交的一个完整的驱动程序与已有的驱动程序重复了,并且这个新驱动程序的作者之前并不知道这个驱动程序已经有了。那些重新发明已有轮 子的代码不仅仅是浪费,而且它也不会被主线内核接受。

  * 提出的方案无法被主线接受也许有很多因素,最好在编写代码前先弄清楚此类问题。

  * 其他开发者完全有可能已经考虑过这个问题了;也许他们有更好的解决方案,并且可能愿意帮助你实现那个解决方案。

多年的内核开发社区经验清楚地告诫我们:通过闭门造车设计和开发的内核代码无疑例外都会有这样那样的问题,而这些问题只有在代码被发布到社区后才能被发现。有时,这些问题十分严重,需要几个月或几年努力才能达到内核社区的标准。下面是一些例子:

  * Devicescape网络协议栈只是针对单处理器系统设计和实现的。它无法被合并到主线版本,除非它适合多处理器系统。对这些代码做锁改造非常困难。结果,这份代码(现在称为mac80211)的合并工作推迟了一年多。

  * Reiser4文件系统包含了许多能力,但核心内核开发者认为这些能力本应该在虚拟文件系统层实现。它还包含了一些特性,但如果不将系统暴露给用户导致的 死锁,这些特性就无法轻易实现。后续发现的这些问题 — 以及作者拒绝解决其中一些问题 –导致了Reiser4依旧置身于内核主线之外。

  * AppArmor安全模块使用了内部虚拟文件系统的数据接口,这种方式被认为是不安全和不可靠的。虽然代码已经明显做过返工,但仍然被排除在主线之外。

在这些例子中,大量痛苦和多余的工作本可以通过早期与其他内核开发者的讨论而被避免。
   
3.3、你与谁讨论?

当开发者决定将他们的项目公开时,接下来的问题将是:我们从哪里开始?答案是找到正确的邮件列表(s)以及正确的维护者。对于邮件列表,最佳的方法就是在 MAINTAINERS文件中寻找一个相关的地方。如果存在一个合适的子系统邮件列表,在那里发布往往比在linux-kernel上发布要更好;你更有 可能碰到具备相关子系统专业知识的开发者以及更能给你提供支持的环境。

找到维护者可能更为困难些。这次,MAINTAINERS文件依旧可以作为寻找的起点,但该文件的更新不总是那么及时,并且不是所有子系统的维护者都会放 在那里。实际上,在MAINTAINERS文件中所列的维护者目前可能已经不再扮演维护者那个角色了。因此,当不知道应该联系谁时,一个实用的技巧是使用 git查看(尤其是"git log")谁是当前你所感兴趣的子系统库的积极开发者。看看谁在写补丁,谁在评审那些补丁。这些人将是给新开发项目带来帮助的最佳人选。

如果以上尝试都失败了,咨询Andrew Morton不失为一个有效的查找特定代码维护者的方法。

3.4、什么时候发布?

如果可能的话,在早期阶段发布你的计划是有帮助的。描述一下你的项目解决的问题以及如何进行实现的计划。你能提供的任何信息都可以帮助开发社区在此项目上提供有用的输入。

在此阶段发生的一个令人沮丧的事情不是怀有敌意的反应,而是少有反应或根本没有反应。这个事情的真实情况是(1)内核开发者都很忙;(2)拥有宏大计划但 几乎没有代码(或甚至是代码展望)的人有太多了,(3)没有人有义务去评审或评论其他人发表的想法。如果一个请求发表建议的mail没有收到几条建议,千 万不要以为没人对你的项目感兴趣。当然,你也不能假定你的想法就没有任何问题。这种情况下最好的做法是继续做下去,并将你做的事情持续通告给社区。

3.5、获得官方认可

如果你的工作是在公司环境下完成的–就像大多数Linux内核开发工作那样–显然你在将你公司的计划或代码发布到公共邮件列表之前应该先从适当的管理 者那获得授权。那些没有清楚地在GPL兼容许可证下发布的代码很可能是有问题的;公司的管理和法律人员越快同意发布这个内核开发项目,参与的人员才能更好 的脱离。

一些读者此刻可能会想到他们的内核开发工作是打算支持一个尚未正式承认存在的产品。在一个公共邮件列表上透露他们雇主的计划可能不是一个可行的方案。在这种情况下,值得考虑保密是否真的必要;实际上,常常并不是真的需要对开发计划进行保密。

不过,也有一些情况下,公司不能在其开发过程早期透露其开发计划。拥有丰富经验内核开发者的公司可能选择以开环的方式继续进行,前提是假设他们能够避免后 续很多严重的集成问题。对于那些没有专们内核开发经验的公司,常见的最佳选择是雇佣一个外部开发者,让其在不公开协议的约束下去评审开发计划。Linux 基金会运营了一个NDA计划,专门设计用于帮助此类情况;更多的信息参见:http://www.linuxfoundation.org/en/NDA_program

在不要求公开项目的情况下,这种评审对于避免后期出现的一些严重问题往往是足够的了。




这里是Tony Bai的个人Blog,欢迎访问、订阅和留言!订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:


如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:


以太币:


如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多