linux内核程序开发,如何做Linux内核的开发

How to do Linux Kernel development

Introduction

The kernel is written mostly in C, with some architecture-dependent parts written in assembly.

“The C Programming Language” by Kernighan and Ritchie

“Practical C Programming” by Steve Oualline

“C: A Reference Manual” by Harbison and Steele

The kernel is written using GNU C and GNU toolchain. While it adheres to the ISO C89 standard, it uses a number of extensions that are not featured in the standard. Arbitrary long long divisions and floating point are not allowed.

Legal issues

The Linux kernel source code is released under the GPL.

For common questions and answers about the GPL, please see:

https://www.gnu.org/licenses/gpl-faq.html

Documentation

When a kernel change causes the interface that the kernel exposes to userspace to change, it is recommended that you send the information or a patch to the manual pages explaining the change to the manual pages maintainers at mtk.manpages@gmail.com and CC the list linux-api@vger.kernel.org.

Here is a list of files that are in the kernel source tree that are required reading:

README

People who are new to the kernel should start here.

Documentation/Changes

Documentation/CodingStyle

*Documentation/SubmittingPatches*

Documentation/SubmittingDrivers

These files describe in explicit detail how to successfully create and send a patch, including (but not limited to):

- Email contents

- Email format

- Who to send it to

Other excellent descriptiosn of how to create patches properly are:

"The Perfect Patch"

https://www.ozlabs.org/~akpm/stuff/tpp.txt

"Linux kernel patch submisstion format"

http://linux.yyz.us/patch-format.html

Documentation/stable_api_nonsense.txt

Documentation/SecurityBugs

Documentation/ManagementStyle

Documentation/stable_kernel_rules.txt

Documentation/kernel-docs.txt

*Documentation/applying-patches.txt

A good introduction describing exactly what a patch is and how to apply it to the different development branches of the kernel.

The kernel also has a large number of documents that can be automatically generated from the source code itself or from ReStructuredText markups (ReST), like this one. This includes a full description of th in-kernel API, and rules on how to handle locking properly.

All such documents can be generated as PDF or HTML by running:

make pdfdocs

make htmldocs

respectively from the main kernel source directory.

The documents that uses ReST markup will be generated at Documentation/output. They can also be generated on LaTeX and ePub formats with:

make latexdocs

make epubdocs

Becoming A Kernel Developer

If you don’t know anything about Linux kernel development, you should look at Linux KernelNewbies project:

https://kernelnewbies.org

This website has basic information about code organization, subsystems, and current projects(both in-tree and out-of-tree).

Useful links:

https://kernelnewbies.org/KernelJanitors

https://selenic.com/mailman/listinfo/kernel-mentors

http://lxr.free-electrons.com/

The development process

当前Linux内核开发流程由几个不同的主分支和许多“特定子系统”分支组成。这些不同主分支是：

main 4.x kernel tree

4.x.y -stable kernel tree

4.x -git kernel patches

subsystem specific kernel trees and patches

the 4.x -next kernel tree for integration tests

4.x kernel tree

- 一旦一个新的kernel发布了，一个为期2周的时间窗口就开放了。在这2周内，维护者可以提交big diffs给Linus，通常都是些已经被包含在 -next kernel已经有几周时间了的patch.

提交大改动的推荐方式是使用git，但是纯的patch也可以。

- 2周后，一个 -rc1 kernel就会被发布，它基本上知识包含了patches，而不会包含新的features，因为那可能会影响整个kernel的稳定性。

请注意一个全新的驱动(driver)或文件系统(filesystem)在 -rc1 之后也可能被接受，因为没有引起regression失败的风险(只要改动不会影响它自身代码之外的其他代码)。

在 -rc1 之后，可以使用git给Linus提patches，但是patches也要被发送给公共的邮件列表做review.

- 只要Linus认为当前的git树是处于正常可以测试的状态的，一个新的 -rc kernel 就会被发布。目标是每周都会有一个新的 -rc kernel被发布。

- 以上流程一直进行，直到kernel被认为是“ready”了。整个流程大约为期6周。

值得一提的是Andrew Morton在linux-kernel邮件列表中所写的关于kernel发布的一段话：

没有人知道一个kernel什么时候会发布，因为它的发布是根据当前所知的bug的状态，而不是根据预设的时间表。

4.x.y -stable kernel tree

有3段版本号的kernel是 -stable kernel. 它们包含了相对小而重要的安全问题或重要的回归测试问题(发现在4.x版本上)的改动。

对于希望得到最新的稳定的kernel而对测试不感兴趣的用户来说，这个branch是比较好的。

如果没有4.x.y版本的kernel，则最高版本的4.x kernel就是当前的stable kernel.

4.x.y是被”stable” team (stable@vger.kernel.org)来维护和根据需求发布的。一般的发布周期大约是2周，但是可能因为没有什么紧急的问题而周期更长。相反，一个安全相关问题就可以使得一个新的版本立即被发布出来。

文件 Documentation/stable_kernel_rules.txt 描述了什么样的改动会被 -stable tree 接受以及整个发布流程是怎样的。

4.x -git patches

这些是Linus的kernel tree的每日快照(daily snapshot)。一般每日都会发布一些patches，而这就代表了Linus的树的当前状态。它们可能并不稳定，因为它们是自动生成的而没有经过测试。

Subsystem Specific kernel trees and patches

这些子系统(subsystems)的仓库地址被列在了 MAINTAINERS 文件中。其中许多也可以在 https://git.kernel.org 中找到。

在一个patch被提交(commit)到一个子系统树之前，它需要在邮件列表中被review(查看相关章节). 对于有一些kernel subsystems，这个review过程被工具patchwork所track. Patchwork提供一个web界面，展示patch的提交(posting)、comments、patch的版本等等，而maintainer可以标记patch为accpted、under review或rejected. 该工具见：

https://patchwork.kernel.org

4.x -next kernel tree for integration tests

在子系统树的更新被merge到mainline 4.x之前，它们需要经过集成测试。因此，一个专门的测试仓库就被用来将所有的subsystem tree给虚拟地拉过来：

https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git

这样，这个 -next kernel 就可以检测出哪些改动可以在下一个merge时间段被合并到mainline kernel上。

Bug Reporting

Managing bug reports

Mailing Lists

在网络上有许多的关于mailing list的archives. 使用一个搜索引擎来找到这些archives：

http://dir.gmane.org/gmane.linux.kernel

强烈建议在提交一个主题到邮件列表之前，先去archive里面搜一搜有没有人以前提过相同的主题。其实有许多细节的讨论都在邮件列表的archives里面了。

大多数的子系统都有它们自己的邮件列表。可以查看 MAINTAINERS文件得到这些邮件列表。

Working with the community

Justify your change

Document your change