Migrating to Linux kernel 2.6 -- Part 1: Customizing a 2.6-based kernel by William von Hagen (Feb. 6, 2004)

Foreword -- This whitepaper is the first in a series from TimeSys’s"2.6 Linux Resource Center" on using the new Linux 2.6 kernel. Authored by TimeSys Senior Product Manager William von Hagen, the whitepapers in this series place special emphasis on the primary issues in migrating existing drivers, applications, and embedded Linux deployments to a Linux distribution based on the 2.6 kernel.

Material presented is largely vendor-neutral.

Enjoy . . . !


Introduction

Linux is a shining example of the power of the Open Source movement as a positive force of change in the software industry. The Linux kernel, the core of any Linux distribution, is constantly evolving to incorporate new technologies and improve performance, scalability, support, and usability. Many of these enhancements are related to adding support for additional architectures, processors, buses, interfaces, and devices. Stable releases of the Linux kernel (even-numbered releases such as 2.0, 2.2, 2.4, and now 2.6) only occur every two years or so, after exhaustive development and testing.

In addition to new features, each new stable Linux kernel version provides many improvements that standardize its internal interfaces, extend the performance and size of supported devices, and simplify adding support for new devices and subsystems to the kernel. Some of these changes are only relevant to kernel developers or people writing device drivers, while others impact system startup, system administration, and application deployment.

If you are migrating existing applications to a 2.6-based Linux distribution such as TimeSys Linux, its performance improvements and increased support for industry-wide standards such as POSIX make porting a relatively simple task. However, if you are migrating device drivers, custom system-level applications, or a customized Linux root filesystem to 2.6-based Linux, an overview of the basic changes to kernel internals, subsystems, system startup, and system administration can save you a substantial amount of development time and debugging headaches.

The whitepapers in this series highlight the primary issues in migrating your existing drivers, applications, and embedded Linux deployments to a Linux distribution based on the 2.6 Linux kernel, such as TimeSys Linux. In conjunction with software that facilitates the development, porting, debugging, and validation cycle such as the TimeStorm Linux Tool Suite, the information in this whitepaper will help you expedite development, control your software conversion and enhancement costs, and reduce time-to-market for your Linux-based devices, systems, and applications.


Customizing a 2.6-Based Kernel

The kernel is the heart of the Linux operating system, managing all system threads, processes, resources, and resource allocation. Unlike most other operating systems, Linux enables users to reconfigure the kernel, which is usually done to reduce its size, add or deactivate support for specific devices or subsystems, or both. Reconfiguring the kernel to remove support for un-used devices is quite common when developing embedded systems, because a smaller kernel requires less memory, increasing the resources available to your applications.

The Linux kernel's support for various devices and interfaces is provided by device drivers that can either be compiled into the kernel or automatically loaded when a specific device is required. In general, kernel code that can be automatically loaded into the kernel is referred to as a loadable kernel module. Writing device drivers for the 2.6 Linux kernel and upgrading existing modules for 2.6 will be discussed in the next whitepaper in this series.

Linux kernel configuration is done through kernel configuration editors that are executed by various targets in the Makefile used when building the kernel using the make command. Each kernel configuration editor displays a description of each kernel configuration variable and enables you to specify whether it should be deactivated, compiled into the kernel, or compiled as a loadable kernel module that the kernel will load upon demand.

Kernel configuration is only the first step in building a new kernel. Once you have configured the kernel, you must compile and install it and any loadable kernel modules that you specified during configuration. This step is straightforward if you are building your kernel on the system where you will execute it, but is more complex when you are compiling for a different target system. For example, when rebuilding the Linux kernel for use in embedded systems, you typically configure your kernel on a desktop system and compile it there using a set of tools known as a cross-compiler.

Cross-compilers run on one type of system but produce binaries that are designed to run on a different type of system, with a different processor or architecture. When compiling your kernel and modules, you must specify the cross-compiler you want to use through a variety of environment variables or Makefile settings, or you can simply use an integrated development environment such as TimeSys’ TimeStorm, that makes it easy for you to select a cross-compiler with a few mouse clicks. Similarly, when cross-compiling the kernel and modules to use Linux in an embedded system, identifying how and where your kernel and modules should be installed requires additional configuration steps and manual Makefile modification if you are not using an IDE such as TimeStorm.

Kernel configuration has changed for the better in the 2.6 Linux kernel. The new graphical configuration editors used by the 2.6 Linux kernel make it easier than ever before to reconfigure kernel compilation settings and identify the dependencies between different kernel configuration variables. Earlier 2.x-based kernels provided four basic kernel configuration editors:

The first three are still available for configuring a 2.6-based kernel, but the interface that you used to see after executing make xconfig has been replaced by two new graphical configuration editors, both of which depend on specific graphical libraries as well as on the X Window system. Another new target for the make command, make defconfig, generates a kernel configuration file by automatically using all of the default values for kernel configuration variables.


New Graphical Editors for Kernel Configuration

The more robust of the new graphical configuration editors is displayed when you execute the command make xconfig. The new version of this kernel configuration editor uses the Qt toolkit from Trolltech. The Qt toolkit is not installed by default on many Linux systems, but a freely downloadable version is available from http://www.trolltech.com. Figure 1 shows a sample screen from this new kernel configuration interface.


Figure 1: Sample make xconfig Screen for the 2.6 Kernel
(Click for larger view)


The configuration editor displayed by the make xconfig command displays a three-paned graphical interface, as shown in Figure 1. The left panel displays an expandable tree-structured view of available kernel configuration options. The upper right panel shows configuration options in the configuration hierarchy selected in the left panel. The lower right panel displays any help information that is available for the currently selected configuration hierarchy or item.

The second graphical configuration editor provided with 2.6-based Linux kernels is displayed when you execute the command make gconfig. This kernel configuration editor depends on the GTK2 (GIMP Toolkit, Version 2) toolkit used by many Linux packages including the GNOME desktop. These libraries and their related widgets are installed on most desktop Linux distributions by default.

The configuration editor displayed by the make gconfig command initially displays a two-paned graphical interface, as shown in Figure 2, which can be made to resemble the make xconfig interface by clicking the Split button in its toolbar.

In general, the editor displayed by the make gconfig command is less mature than that displayed by make xconfig. Unless you are using software with integrated support for kernel configuration, such as TimeSys TimeStorm Linux Development Suite, we strongly recommend that you use make xconfig for kernel configuration.


Figure 2: Sample make gconfig Screen


Kernel Configuration Tips

Discussing all of the available kernel configuration options is outside the scope of this whitepaper, but a few general tips and suggestions are worth noting here. The 2.6 Linux kernel is more easily configured than any previous Linux kernel, but it also has more configuration options than ever before. This means that it is easier than ever before to configure a kernel that won't boot and run on your hardware or that will not support an existing application.

As an example of the first case, devices such as the PS/2 keyboards and mice used on most x86-based systems are now configurable like other devices, largely because the 2.6 kernel standardizes the Linux device model and now treats these as devices on a processor-specific, legacy bus interface. These options are found on the Device Drivers > Input device support > Keyboards and Device Drivers > Input device support > Mice > PS/2 Mouse configuration screens, and should not be deactivated unless you do not want to use a PS/2 keyboard or mouse.

You should also check the options for Graphics support in the Device Drivers section to ensure that you have enabled a console display driver or framebuffer support unless you specifically intend to use a system without a graphical console. Finally, as an example of changes that modify system or application behavior, you must enable module unloading as a separate kernel option if you ever want to unload a module after loading it.

As a general tip, the Options menu in the make xconfig or make gconfig editors provides several very useful settings for kernel configuration:

Once you've configured your kernel to match your requirements, the actual make commands used to compile and install your kernel differ for the Linux 2.6 kernel. As a convenience, you can always execute the make help command, which displays all of the available options for building a 2.6 kernel.

Other make-related changes include the elimination of the make dep (create dependency information) build step. The "make" command (with no arguments) now automatically (and silently) generates dependency information, compiles the kernel, and compiles any drivers that you have selected for installation as modules. Once you have configured your kernel, simply issuing the make command, followed by the make install and make modules_install commands, is the most common build and install procedure for 2.6-based kernels.

Unless you have purchased a complete 2.6-based distribution, you will need to update some of the Linux software and tools used during system startup before rebooting with a 2.6 kernel. A later whitepaper in this series will discuss the packages that you will need to update in order to build and use a 2.6-based kernel with an existing Linux installation and filesystem.


Migrating Existing Kernel Configurations

As discussed earlier in this whitepaper, one of the available options for configuring the Linux kernel is using the make command's oldconfig target, which generates a new kernel configuration file based on the contents of an existing kernel configuration file. If you do not have an existing kernel configuration file, you can generate one quickly by executing the make defconfig command from any command line, or by starting any of the graphical kernel configuration editors.

The make oldconfig command is especially useful when moving existing kernel configurations to an updated kernel. The make oldconfig command causes the kernel configuration process to read in your existing configuration information and then prompt you for a value for any kernel configuration variables that were not provided set the existing kernel configuration file.

To migrate an existing kernel configuration from a Linux distribution based on the 2.4 kernel to a 2.6-based distribution, copy the file named .config (located in the main source code directory for your existing Linux kernel source code) to the directory where your Linux 2.6 kernel source code is located. For example, to migrate a customized configuration file that you were using with TimeSys Linux 4.1 (using the 2.4.21 kernel) for the Intel IQ80315 reference board to TimeSys Linux based on the 2.6 kernel, you would do the following:

# cd /opt/timesys/linux/4.1/iq80315/src/2.4.21-timesys-4.1/kernel
# cp .config /opt/timesys/linux/5.0/iq80315/src/2.6-timesys-5.0/kernel
# cd /opt/timesys/linux/5.0/iq80315/src/2.6-timesys-5.0/kernel
# make oldconfig

At this point, you will be prompted for a value for all currently undefined kernel configuration variables. Once you supply values for these variables, the make oldconfig command will generate an updated kernel configuration file. You can then simply build the new kernel, or can continue kernel configuration using a more sophisticated configuration editor such as make xconfig.

Conclusion

Simplifying system configuration is more important than ever before with 2.6-based Linux distributions, and the new graphical configuration editors in 2.6 make it easier to reconfigure the kernel to meet your needs. TimeSys is taking a leadership role in porting and supporting the 2.6 Linux kernel to architectures beyond just the x86 platform, where most of the testing and development has taken place to date. However, each new architecture, interface, subsystem, and device further increases the number of kernel configuration variables that you may need to be familiar with.

Additional software tools, such as the Target Configurator, a component of the TimeStorm Linux Development Suite and powered by the Open Source Eclipse framework, provide integrated support for kernel configuration. To further simplify configuration, TimeSys Linux includes customized kernel configuration files targeted towards high performance, general development, and debugging. Regardless of which tools and distribution you are using, kernel configuration in the 2.6 Linux kernel has come a long way from previous stable Linux kernel releases.


About the author: William von Hagen is a Senior Product Manager at TimeSys Corp., has been a Unix devotee for over twenty years, and has been a Linux fanatic since the early 1990s. He has worked as a system administrator, writer, developer, systems programmer, drummer, and product and content manager. Bill is the author of Linux Filesystems, Hacking the TiVo, SGML for Dummies, Installing Red Hat Linux 7, and is the coauthor of The Definitive Guide to GCC (with Kurt Wall) and The Mac OS X Power Users Guide (with Brian Profitt). Linux Filesystems is available in English, Spanish, Polish, and traditional Chinese. Bill has also written for publications including Linux Magazine, Mac Tech, Linux Format, and online sites such as Linux Planet and Linux Today. An avid computer collector specializing in workstations, he owns more than 200 computer systems.


Next…

The next whitepaper in this series provides an overview of the changes to device drivers in the Linux 2.6 kernel, highlighting the basic changes you must make when migrating existing device drivers to work with the 2.6 kernel. For additional whitepapers and other related information from TimeSys, please visit here. TimeSys also offers webinars on 2.6-related topics –- further details are here.


This article is part one in a series on Migrating to Linux kernel 2.6 by William von Hagen. The complete series includes: