Merge pull request #1362 from bazz2/master

[bazz2-ed]Linux Kernel Testing and Debugging 1
This commit is contained in:
Xingyu.Wang 2014-07-22 20:29:51 +08:00
commit 3b29b19bc9
3 changed files with 78 additions and 78 deletions

View File

@ -1,77 +0,0 @@
[let bazz2 try it]
Linux Kernel Testing and Debugging
================================================================================
### Linux Kernel Testing Philosophy ###
Testing is an integral and important part of any software development cycle, open or closed, and Linux kernel is no exception to that. Developer testing, integration testing, regression, and stress testing have different individual goals, however from 1000 feet up, the end goal is the same, to ensure the software continues to work as it did before adding a new body of code, and the new features work as designed.
Ensuring software is stable without regressions before the release, helps avoid debugging and fixing customer and user found bugs after the release. It costs more in time and effort to debug and fix a customer found problem. Hence, testing is very important in the case of any software, not just the Linux kernel. Unlike closed and proprietary operating systems, the development process is open and is not locked down. This process is its strength as well as weakness. With several developers continuing to add new features, and fixing bugs, continuous integration and testing is vital to ensure the kernel continues to work on existing hardware as new hardware support and features get added. In the open source development, developers and users share the testing responsibility. This is another important difference between a closed development model and an open one.
Almost all Linux kernel developers, if not all, are very active Linux users themselves. There is no requirement that testers should be developers, however, users and developers that are not familiar with the new code could be more effective at testing a new piece of code than the original author of that code. In other words, developer testing serves as an important step in verifying the functionality, however, developer testing alone is not sufficient to find interactions with other code, features, and unintended regressions on configurations and/or hardware, developer didn't anticipate and didn't have the opportunity and resources to test. Hence, users play a very important role in the Linux Kernel development process.
So now that we understand the importance of continuous integration testing, we will go into the details of testing itself. Before we talk about testing, I would like to walk through the development process itself to help understand how it works and how the changes funnel into the mainline kernel.
3000+ kernel developers from around the world contribute to the Linux kernel. It is a 24hours, seven days a week, and 365 days of continuous development process that results in a new release once every 2+ months and several stable and extended stable releases. New development and current release integration cycles run in parallel.
For further reading on the development process, please refer to [Greg Kroah-Hartman's presentation on the Linux Kernel Development][1].
It is my intent that this guide should be useful to a beginner as well as an experienced contributor and/or individuals interested in getting involved in the Linux kernel development. Experienced developers can chose to skip sections that go over basic testing and debugging.
This paper will discuss how to test and debug Linux kernel, tools, scripts and debug mechanisms that aid in regression and integration testing. In addition, this paper will go into details on how to use git bisect to isolate a patch that introduced a bug, and what to test before sending patches to the Linux Kernel Mailing List. I will use Linux PM as an example target area for the testing and debugging discussion. Even though this paper is Linux Kernel testing focused, the importance of testing is applicable to any software project.
### Configuring Development and Test System ###
Let's get started. First order of business is finding a development system that suits your needs. x86-64 systems are a good choice for a basic development system, unless there is a need for a specific architecture and/or configuration.
The second step is to install distribution of your preference. I prefer Ubuntu, hence this document will have the details on how to configure a kernel development system running Ubuntu distribution. Please follow [How to Ubuntu][2] for installing the Ubuntu release of your choice.
On development and test systems, it is a good idea to ensure there is ample space for kernels in the boot partition. Choosing whole disk install or setting aside 3 GB disk space for the boot partition is recommended.
Once the distribution is installed and the system is ready for development packages, enable root account and also enable sudo for your user account. The system might already have the build-essential package which is what you need to build Linux kernels on an x86_64 system. If build-essential is not already installed, run the following command to install it:
sudo apt-get install build-essential
At this point, you may install the following packages as well, so the system is ready for cross-compiling Linux kernels. Note that ncurses-dev is a required package to run make menuconfig.
sudo apt-get install binutils-multiarch
sudo apt-get install ncurses-dev
sudo apt-get install alien
Now let's install a few tools every Linux kernel developer need in his/her tool chest.
sudo apt-get install git
sudo apt-get install cscope
sudo apt-get install meld
sudo apt-get install gitk
If you would like to get the system configured for cross-compiling other supported architectures non-natively on your x86-64 system, please follow: [Cross-compiling Linux kernel on x86 64][3].
The Stable Kernel
Start by cloning the stable kernel git, building and installing the latest stable kernel. You can find information on the latest stable and mainline releases at [The Linux Kernel Archive][4].
git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
The above step will create a new directory named linux-stable and populate it with the sources.
You can also download just the Linux Kernel source tar-ball instead of cloning the git, and then unpack the tar-ball.
tar xvf linux-3.x.y.tar.xz
--------------------------------------------------------------------------------
via: http://www.linuxjournal.com/content/linux-kernel-testing-and-debugging?page=0,0
译者:[译者ID](https://github.com/译者ID) 校对:[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译,[Linux中国](http://linux.cn/) 荣誉推出
[1]:http://events.linuxfoundation.org/images/stories/pdf/als2012_gregkh.pdf
[2]:http://howtoubuntu.org/
[3]:http://linuxdriverproject.org/mediawiki/index.php/Cross-compiling_Linux_kernel_on_x86_64
[4]:https://www.kernel.org/

View File

@ -1,3 +1,4 @@
[bazz2 so handsome]
Linux Kernel Testing and Debugging
================================================================================
### Compiling and Installing Stable Kernel ###
@ -104,4 +105,4 @@ via: http://www.linuxjournal.com/content/linux-kernel-testing-and-debugging?page
译者:[译者ID](https://github.com/译者ID) 校对:[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译,[Linux中国](http://linux.cn/) 荣誉推出
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译,[Linux中国](http://linux.cn/) 荣誉推出

View File

@ -0,0 +1,76 @@
Linux 内核的测试和调试
================================================================================
### Linux 内核测试哲学 ###
不管是开源还是闭源所有软件的开发流程中测试是一个重要的、不可或缺的环节Linux 内核也不例外。开发人员自测、系统测试、回归测试、压力测试,都有各自不同的目的,但是从更高一个层次上看,这些测试的最终目的又是一样的:保证软件能一直运行下去,当有新功能加进去时,要保证新功能可以正常工作。
在软件释出 release 版之前,不用回归测试就能保证稳定性,并且尽量避免在软件发布后被用户发现 bug。调试被用户发现的 bug 是一项非常浪费时间和精力的工作。因此测试是一项非常重要的工作。不像闭源和专有的操作系统Linux 内核的开发过程是完全开放的。这种处理方式即是它的优点,也是它的缺点。多个开发者持续增加新功能、修 bug、不断集成与测试 —— 当环境有新的硬件或功能时,这种开发方式能够保证内核能持续工作。在开源项目中,开发者与用户共享测试的结果,这也是开源项目与闭源项目之间的一个很重要的差别。
几乎所有 Linux 内核开发者都是活跃的 Linux 用户。内核测试人员不一定非得是内核开发者,相反,用户和开发者如果对新增的代码不是很熟悉,他们的测试效果会比代码开发人员自己测试的效果要好很多。也就是说,开发者的单元自测能验证软件的功能,但并不能保证在其他代码、其他功能、其他软件、硬件环境下面运行时会出现什么问题。开发者无法预料、也没有机会和资源来测试所有环境。因此,用户在 Linux 内核开发过程中起到非常重要的角色。
现在我们已经了解了持续集成测试的重要性,接下来我们会详细介绍测试的知识。但在此之前,我还是向介绍一下开发的过程,以便让大家了解它是怎么工作的,以及如何把补丁打进内核主线。
全世界共有3000多个内核开发者为 Linux 内核贡献代码每天都有新代码添加到内核结果是大概2个月就能产生一个稳定版和多个扩展的稳定版。新功能的开发与已发布的稳定版集成测试流程在同时进行。
关于开发流程的详细描述,请参考[Greg Kroah-Hartman 的 Linux 内核开发的介绍][1]。
这份教程适合与初学者以及有经验的内核开发者,如果你想加入到内核开发者行列,那么它也适合你。有经验的开发人员可以跳过那些介绍基础测试和调试的章节。
这份教程介绍如何测试和调试 Linux 内核、工具、脚本以及在回归测试会集成测试中使用的调试机制。另外,本文还会介绍如何使用 git 把针对一个 bug 的补丁分离出来,在介绍介绍把你的补丁提交到内核的邮件列表之前需要做些什么。我将会使用 Linux PM 作为测试它调试的对象。尽管本文讨论的是 Linux 内核,但是介绍的方法适用于任何其他软件开发项目。
### 配置开发与测试的系统 ###
第一步找一个满足你需求的开发环境x86-64 是一个比较理想的选择,除非你必须用特别的架构。
第二步,安装 Linux 发行版,我推荐 Ubuntu所以本教程会介绍基于 Ubuntu 的配置过程。你可以参考[如何使用 Ubuntu][2] 来安装一个 Ubuntu 系统。
在开发和测试环境,最好要保证你的 boot 分区有足够的空间来存放内核文件。你可以为 boot 分区留下 3GB 空间,或把 boot 分区直接放到根目录下,这样 boot 分区可以使用整个磁盘的空间。
安装好操作系统后,确保 root 用户可用,确保你的用户可以使用 sudo 命令。你的系统也许已经安装了 build-essential它是编译内核必备的软件包如果没安装运行下面的命令
sudo apt-get install build-essential
然后运行下面的命令,保证你的系统能够交叉编译内核。下面的 ncurses-dev 安装包是运行 make menuconfig 命令必须用到的。
sudo apt-get install binutils-multiarch
sudo apt-get install ncurses-dev
sudo apt-get install alien
然后安装一些每个内核开发者都会用到的工具包:
sudo apt-get install git
sudo apt-get install cscope
sudo apt-get install meld
sudo apt-get install gitk
如果你喜欢把内核通过交叉编译以支持非 x86_64 架构的环境,请参考[在 x86_64 上交叉编译 Linux 内核][3]。
### 稳定的内核 ###
使用 git 克隆一个稳定的内核,然后编译安装。你可以参考[Linux 内核结构][4]来找到最新的稳定版和开发主线。
git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
上面的步骤将会创建一个新的目录,名为 linux-stable然后把源码下载到里面。
你也可以直接下载压缩包并解压出源码,无需使用 git
tar xvf linux-3.x.y.tar.xz
--------------------------------------------------------------------------------
via: http://www.linuxjournal.com/content/linux-kernel-testing-and-debugging?page=0,0
译者:[bazz2](https://github.com/bazz2) 校对:[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译,[Linux中国](http://linux.cn/) 荣誉推出
[1]:http://events.linuxfoundation.org/images/stories/pdf/als2012_gregkh.pdf
[2]:http://howtoubuntu.org/
[3]:http://linuxdriverproject.org/mediawiki/index.php/Cross-compiling_Linux_kernel_on_x86_64
[4]:https://www.kernel.org/