Red Hat Linux 7 Unleashed

By William Ball

• Table of Contents
  • Copyright
  • About the Lead Authors
  • About the Contributing Authors
  • Acknowledgments
  • Tell Us What You Think!
  • Introduction
  • I. Red Hat Linux Installation and User Services
  • Chapter 1. Introduction to Red Hat Linux
  • Chapter 2. Installation of Your Red Hat System
  • Chapter 3. LILO and Other Boot Managers
  • Chapter 4. Configuring the X Window System, Version 11
  • Chapter 5. Window Managers
  • Chapter 6. Connecting to the Internet
  • Chapter 7. IRC, ICQ, and Chat Clients
  • Chapter 8. Using Multimedia and Graphics Clients
  • II. Configuring Services
  • Chapter 9. System Startup and Shutdown
  • Chapter 10. SMTP and Protocols
  • Chapter 11. FTP
  • Chapter 12. Apache Server
  • Chapter 13. Internet News
  • Chapter 14. Domain Name Service and Dynamic Host Configuration Protocol
  • Chapter 15. NIS: Network Information Service
  • Chapter 16. NFS: Network Filesystem
  • Chapter 17. Samba
  • III. System Administration and Management
  • Chapter 18. Linux Filesystems, Disks, and Other Devices
  • Chapter 19. Printing with Linux
  • Chapter 20. TCP/IP Network Management
  • Chapter 21. Linux System Administration
  • Chapter 22. Backup and Restore
  • Chapter 23. System Security
  • IV. Red Hat Development and Productivity
  • Chapter 24. Linux C/C++ Programming Tools
  • Chapter 25. Shell Scripting
  • Chapter 26. Automating Tasks
  • Chapter 27. Configuring and Building Kernels
    • Introduction to the Linux Kernel
    • Understanding the Kernel
    • Understanding the Kernel Sources Structure
    • Obtaining the Kernel Sources
    • Configuring the Linux Kernel
    • Building and Installing the Kernel
    • Recovering from Faulty Kernels
    • Summary
  • Chapter 28. Emulators, Tools, and Window Clients
  • V. Appendixes
  • A. The Linux Documentation Project
  • B. Top Linux Commands and Utilities
  • C. The GNU General Public License
  • D. Red Hat Linux RPM Package Listings

Understanding the Kernel Sources Structure

Linux is "UNIX-like." Linux is not a version of UNIX, but a new OS that aims to be UNIX-interface compatible. Linux is also a large and complex piece of software. The kernel itself contains over 1.7 million lines of source code; by commercial software standards, such a project would take 5 to 10 years and require up to 500 programmers. The methodology of Open Source has been proven through the kernel project: Richard Gooch'sKernel FAQ (http://www.tux.org/lkml/) observes that Linux is a little more than eight years old, placing it right on track compared to industrial standards.

Linux is developed by thousands of programmers spread worldwide, and under constant peer review by many thousands more. According to Brooks' Law, communications complexity grows exponentially with the size of the development team, eventually stifling all progress, but the Linux project defeats this law by two clever hacks: Linux is organized into modules and subsystems, and the explosive growth and experimentation on new features is isolated from the mainstream users through a separation into development and production source streams. The modular design distributes communications hierarchically into sub-teams and sub-teams of sub-teams, avoiding the omni-topology that invokes Brooks' Law.

Figure 27.1 shows a package map of the kernel sources. A quick inspection of /usr/src/linux/MAINTAINERS shows almost direct correspondence. The gross structure of Linux partitions the sources by subsystems; since those technologies suit the fancies of the developers, someone with an interest in filesystems may be deeply involved in the /fs package but only marginally involved in /mm.

Figure 27.1 Package map of /usr/src/linux.

The per-developer partitioning is carried deeper in per-service relationships within the /net and /driver packages. This makes sense when you consider that each service is added and maintained by owners (or vendors) of that hardware who would want to keep their realm of interest localized. This "implementation-oriented" source structure may overlook similarities and opportunities for code re-use, but it is highly pragmatic within the Open Source methodology.

Kernel Version Numbers

Linux kernel version numbers identify the base design and the revision, and also identifies whether you are running an experimental or a production release. The version in use by any Linux system can be queried with uname -a:

$ uname -a
Linux kato 2.3.21 #1 Tue Oct 12 16:08:21 EDT 1999 i486 unknown

This line identifies that kernel as version 2.3.21 and gives the architecture and the date when the kernel was compiled. The version number contains three parts:

• The major number (2)
• The minor number (3)
• The current revision (21)

There are enough version-1 Linux machines to be impressive, but they are rare. For practical purposes, the major number is 2; no one is quite sure what change would be big enough to jump to Linux-3, but we might assume it would cease to promise Linux-2 compatibility.

The last number is the incremental patch number and changes with every update. The first important portion of the kernel version number is the middle digit, the "minor" number. Odd minor numbers denote "experimental" kernels, the testbed for developers to explore, add new code, and bounce ideas off each other. Even minors, on the other hand, carry a stamp of respectability as "production editions."

When a development kernel is ready, it follows the usual process of a feature freeze, then a code freeze, and is then promoted to the next even number. Thus, 2.3.99 became 2.4.0 and was simultaneously branched to become the new development 2.5 source. The road goes ever on.

Share This