Linux kernel download and building tips

Linux Kernel Configuration and Development

Embedded Linux development when you're creating applications is much less about kernel development and more about kernel configuration. Because hardware vendors have a vested interest in making sure Linux is ready for their hardware the day it ships, the days of a developer on an embedded Linux project porting a kernel for a board has become a thing of the past. A typical embedded developer needs to know how the kernel project works but doesn't spend time doing in-depth kernel hacking like in the days of yore. This article explains the kernel project layout and how to build the kernel for your board. If you're changing the kernel and want to make your changes part of the Linux project, a part explains the kernel development process, how to make a patch, and the steps necessary to get your changes accepted into the mainline kernel build. If you receive a patch, a part reviews how to apply it to your current kernel code. The kernel project is complex, but the complexity is tempered with good organization and a welldefined process for building and development. Compared to other open-source project, the kernel is very well engineered for cross-building; you should have very few problems getting the kernel to build for your target platform. As hardware companies have made it their business over the years to fully support Linux, they have been aggressive in making sure their changes make become part of the mainline Linux kernel and making sure engineers choosing Linux for their operating system can be confident that building a functional Linux kernel for an embedded board will be as simple as building one for a desktop system.

Kernel Project Layout

The Linux kernel is a large-scale C and Assembler project that's held together with GNU Make and GCC. Some additional scripts control the way the project builds, and some additional helper programs are contained in the scripts directory and aren't part of the code that goes into the final kernel image. The kernel has hundreds of active developers. To keep things in order, the Linux project has established its own "a place for everything and everything in its place" policy that's important to understand.

Downloading the Kernel

You can find the current releases of the kernel at http://kernel.org. This site is the canonical location of the Linux kernel sources and the hub of activity for the kernel project. Present on the site is every Linux distribution released along with links to the various mailing lists you can use to follow and participate in the Linux project. There are three ways for you to get the kernel sources. Each is describedy:

Download a compressed tar file: This is the traditional (as much as this term can be applied to open source distributed software development) method of getting the kernel sources. This archive contains a snapshot of the sources during the development cycle. When the kernel is released, a tar file is created with the sources constituting that release. If you want or need to get a certain version of the kernel (say, 2.6.31.2), this is the easiest method.
Use Git to clone the repository: Git is a distributed source code control system used by developers (and by developers of other projects; Git is a general-purpose tool) for the kernel project. If you start from a Git repository, it's much easier to retrieve updates to the kernel release and incorporate them into your kernel tree.
Supplied by your vendor: You board vendor may supply you with some kernel sources. These could be supplied to you in any number of ways; this article assumes that sources supplied in this manner also include enough support that you can get them unpacked and in a place where they can be used for a build.

Downloading a Compressed Tar File

This is the easiest way to get the sources. Just click the link, and wait for the download to complete; the waiting is the hardest part. After the download completes, you can unarchive the file by doing the following:

tar xzf linux-2.6.30.1.tar.gz

The kernel version you download will likely be something different, but the format will be the same. A directory is created named after the tar file, sans the .tar.gz suffix.

Using Git to Clone the Repository

When working with Git, you don't check out the sources, as with other source code control systems; you create a copy, or clone, of a repository. For the Linux kernel, you use the following command:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.31.y.git

You'll likely use a different version of the Linux kernel, so the 2.6.31 in this link will be the version of the kernel that you want to download. Your company may have a firewall that blocks the URL git://; if this is the case, replace git: with http:, and the data will be downloaded over port 80.

Building the Kernel

Building the kernel is frequently viewed as a difficult proposition. There's also the view that building the Linux kernel is risky because the newly build kernel won't work properly even if it does compile. These assumptions are simply false. Building a kernel from source is easy, and the risks of the software not working are minimal-the kernel is tested by thousands of software engineers on a daily basis. Because the Linux project is complex, building the kernel requires a few steps not necessary for other project. The basic steps are as follows:

1. Configuration: During the configuration step, you set the parameters and options that control how the kernel is built. There are several different ways of configuring the kernel, but it doesn't matter which one you select because all of them perform the same underlying activities. Configuration is frequently aided by default configuration settings supplied with the kernel for most boards and processors; for many boards, you can use this default configuration as is to build a kernel that will boot on the board.

2. Building the kernel: After it's configured, the kernel can be compiled and linked. This process works much like any other Linux project using GNU Make as the build tool. The result of the kernel build is a binary that can be put on the board and booted as well as file suitable for debugging.

3. Building the modules: The Linux kernel supports linking code into the image at runtime, similar to the way a program uses a shared library. Kernel modules support hardware components that may not be present when the kernel is started, so having the code in memory is a waste of resources. The code that can be linked into the kernel, in a process called loading, is called a module; these modules can be built separately from the kernel. Modules can be loaded and unloaded on demand.

The Linux kernel build process involves first priming the kernel source tree so that it's in the right state to be compiled; this process is called configuration or configuring the kernel. The kernel configuration process grew out of environment variables that were set in the shell, which were then used by the make file to compile certain code or change the compilation method. As the complexity of the kernel project grew, the configuration process advanced similarly and gained a text-based menu interface that is essentially unchanged in the current distribution of Linux. To start the kernel configuration process using the text-based menu-oriented configuration program (other methods are discussed later), do the following from the command prompt while in the kernel's top-level directory:

$ make menuconfig ARCH=

If the kernel has never been configured before, the programs used to configure the kernel and display the text-based menu are compiled. The value for ARCH is one of the entries in the kernel's arch directory and is always in lowercase. If you're uncertain what to pick for the architecture, run uname -m on the target machine. If you're still uncertain, get in touch with the technical support department or FAE for the board. The most popular targets for embedded (in alphabetical order) are arm, mips, powerpc, sh, and x86. Many people prefer to use GUI tools that can work with a mouse, as opposed to the text-oriented configuration program. For the kernel, there are two different graphical kernel configuration systems: one that uses the QT graphics library and the other that uses GTK libraries. No matter what configuration program you use, the program does the same thing, so feel free to experiment with each and pick the one you prefer. Many Linux kernel developers have a preference for the console-based menu configuration tool, so if you're working with a kernel developer, learning and using this tool is a good idea. The options selected by the kernel configuration program are stored in a .config file. Because this file starts with a . it doesn't appear when you list a directory's contents in Linux and use the default parameters for ls (hint: use the -a argument to ls to see files starting with a dot); that confuses users who look for the file containing their configuration information.

How Kernel Configuration Works

The kernel configuration process works when the kernel configuration program reads a kernel configuration specification file, called the kconfig file. This file resides in the arch directory, as specified with the ARCH= parameter when you run menuconfig. The kconfig file for the architecture contains the settings specific to the architecture and then includes configuration files for the rest of the kernel. The kernel configuration program reads in the .config file for the kernel, applies the settings to the kconfig that was just read into the system, and renders the menu. After you select options, the changes are written back out to the .config file. Early in the build process, the file include/linux/autoconf.h is generated: it contains all the settings in the .config file as C preprocessor macros. The autoconf.h file is included in all the files in the Linux kernel; that is how the options you select in the configuration program are made available to the kernel.