如何成为一个Linu系统内核开发者.docxVIP

你想成知道如何成为一个 Linux 内核开发者么？或者你的老板告诉你，“去为这个设备写一个 Linux 驱动。 “这篇文档的目的，就是通过描述你需要经历的过程和提示你如何和社区一起工作，来教给你为达到这些目的所需要知道的所有知识。本文也尝试解释社区为什么这样工作的一些原因。 内核几乎全是用 C 写成的，有一些架构相关的部分是用汇编语言写成的。熟练掌握 C 语言是内核开发的必备条件。汇编语言(任何架构)的了解不是必须的，除非你准备做某个架构的底层开发。虽然下面这些书不能完全代替扎实的 C 语言教学和/或者成年累月的经验，他们还是不错的参考，如果用得着的话： - The C Programming Language 作 者 : Kernighan and Ritchie [Prentice Hall]- Practical C Programming 作者: Steve Oualline [OReilly] 内核是用 GNU C 和 GNU 工具链写成的。虽然它符合 ISO C89 标准，它还是使用了一些标准中没有的扩展。内核是自成体系的 C 环境，它并不依赖标准 C 库，所以某些 C 语言标准是不支持的。任意长度 long long 类型除法和浮点数是不被允许的。有时候会很难理解内核对于它所使用的工具链和扩展的假定，而且不幸的是也没有关于它们的绝对的参考。请查阅gcc 的 info 页(`info gcc`)以获取有关信息。 请记住你是在尝试学习如何与已经存在的开发社区一起工作。这是一群成分复杂的人们，他们对于代码，风格和步骤有高的标准。这些标准是经过时间检验的。 他们发现遵循这些标准对于这样一个大规模的且地理上分散的团队是最佳的选择。尝试提前学习尽可能多的有关这些标准的知识，因为它们都有很好的文档；不要期望别人会遵照你或者你公司的行事方式。 法律问题 Linux 内核源代码依照 GPL 发布。请参考源代码树下的 COPYING 文件，以获取有关这个许可证的详细信息。如果你对这个许可证有疑问，请联系你的律师，不要在 Linux 内核邮件列表里询问。邮件列表里的人们不是律师，你不应该依赖于他们对于法律问题的解释。 文档 Linux 内核源代码树有很多文档，它们对于学习如何与内核社区交流来说有不可估量的价值。当新的功能加进内核的时候，通常建议作者把解释这个新功能的文档也加进内核。如果一个内核变动导致了内核对用户空间界面的改变，建议你把这个信息或者一个解释了这个变动的 manpage 的补丁发送给手册页的维护者 mtk-manpages@。 这里有一个内核源代码树里需要阅读的文件列表： README 这个文件简单介绍了 Linux 内核的背景，并描述了配置和编译内核需要做哪些事情。内核新手应该从这里开始。 Do*****entation/Changes 这个文件介绍了成功编译和运行内核所需要各种不同软件的列表。 Do*****entation/CodingStyle 这个文件描述了 Linux 内核代码风格，还有背后的一些原因。所有的新代码的要符合这个文档里的准则。大多数维护者只会接受符合这些规则的补丁，很多人只看符合正确风格的代码。 Do*****entation/SubmittingPatches Do*****entation/SubmittingDrivers 这些文件非常详细的介绍了如何成功的创建和发送一个补丁，包括(但不限于)： -Email 内容 -Email 格式 -发送给谁 遵守所有这些规则并不能保证成功(对所有的补丁都需要进行内容和风格的详细检查)，但是不遵守这些规则就一定不会成功。 其他关于如何创建补丁的很好的文章有： “The Perfect Patch .au/~akpm/linux/patches/stuff/tpp.txt Linux kernle patch submission format linux.yyz.us/patch-format.html Do*****entation/stable_api_nonsense.txt 这个文件解释了有意识的决定-不在内核里使用稳定的 API-的原因，包括： -子系统分隔层(为了兼容？) -操作系统之间的驱动可移植性 -缓和(或者阻止)内核源代码树的急速变动 这个文档对于了解 Linux 的开发哲学是非常关键的，对于由开发其他操作系统转而开发 Linux 人也是很重要的。 Do*****entation/SecurityBugs 如果你感觉到你发现了 Linux 内核里的一个安全问题，请遵照这个文档里所描述的步骤来提醒内核开发者，并帮助解决问题。 Do*****entation/ManagementStyle 这个文档描述了 Linux 内核维护者