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

Configuring the Linux Kernel

Once you know what your new kernel must accomplish and have the sources installed, you are ready to begin creating a customized Linux operating system. Before setting the compile in motion, there are a few last minute details to ensure a successful run, or at least a graceful recovery.

Preparing lilo.conf for Kernel Updates

Before you begin, double-check your system against the requirements in linux/Documentation/Changes. In particular, ensure you have the correct version of the binutils and the gcc compiler.

You should also create an entry in your /etc/lilo.conf to keep your current kernel installed as a backup. In addition to adding a few seconds' delay on the boot prompt with the delay parameter (so you can interrupt to add parameters or select an alternate image), add a section for a known stable kernel (such as the original distribution kernel image) and also for the generated backup left behind by the build commands.

image=/boot/vmlinuz.orig
        label=stable
        root=/dev/hda3
        append=""
        read-only
image=/boot/vmlinuz.bak
        label=backup
        root=/dev/hda3
        append=""
        read-only

Using this configuration, if you have trouble booting from the new kernel, you can enter stable at the LILO: prompt and boot your original kernel.

The make bzlilo compile command will automatically back up the previous kernel from $(INSTALL_PATH)/vmlinuz to $(INSTALL_PATH)/vmlinuz.old and then run the lilo command to install the new kernels. The preceding /etc/lilo.conf sections give one more line of defense against a kernel that cannot boot. The fourth section, labeled backup, also allows you to make periodic backups of particularly stable development kernels in case repeated compiles leave both vmlinuz and vmlinuz.old unstable and utility upgrades have cut you off from the original vmlinuz.orig. It happens.

Is lilo.conf prepared to find the new kernel? Do you have a backup kernel and a boot disk? Do you have enough disk space? These may seem trivial questions, but they are important. An error in any of these may leave your system in an inoperable state and entirely devour your weekend. Even if all you are doing is setting a few /proc values or adding a network interface on the boot prompt, it is good defensive driving to consider the recovery plan.

Configuring with make

The Linux Makefile provides four methods of setting your configuration options:

• make config—A command-line terminal program
• make menuconfig—An ncurses-based console program
• make xconfig—A tk/tcl-based X11 GUI program
• make oldconfig—A semi-automatic update program

Why have a command-line interface at all? Suppose you had an autonomous robot submarine or a space probe. Imagine you are in the midst of maneuvers and need a fast kernel reconfig. Simple dumb terminal interfaces can go places other interfaces cannot dream of going! The X11/tk interface may be more elegant and esthetically appealing, but it does require that Tk and X11 are both installed and working.

A forms-based interface is often more comfortable, but X11 is sometimes impractical—for example, while doing remote administration over a slow telnet connection or in a Linux machine for blind users. For these situations, we have the ncurses-based menuconfig. Both the X11 and the ncurses configuration tools offer the same options in the same order, and they have roughly the same capability to navigate backward and forward through the configuration options.

To start the configuration, simply go to the /usr/src/linux directory and enter one of the configuration commands. If you choose either of the ncurses or X11 methods, you will see a brief flurry of compiler activity while the user-interface programs compile, and then you will be greeted by an overview screen with all the categories of kernel options.

Those of you who recoil in horror at the thought of a command line can now rest easy. From this point on, those using the xconfig method will be in carpal-tunnel land (a.k.a. "mouse mode") until the configuration is done.

Selecting Configuration Options

Figure 27.2 shows the initial screen as seen in the xconfig display for the 2.4 kernel. 2.2.x kernels are very similar, but with fewer options and minor cosmetic differences. In all of the configuration methods, most kernel options can be set to be included, included as a module, or left out of the compile. On the xconfig and menuconfig screens, there are options to include or exclude complete sections of configuration; disabling these will gray out any dependent options (the dumb-terminal config option will silently skip these sections).

This guide cannot attempt to describe every one of the 1,302 individual options in the Linux kernel; this chapter will only cover the major groups, focus on options of interest to specific applications, and explain some of the implications and configuration options for common Intel-based modules.

Figure 27.2 Online Help in make xconfig.

Whether you use the dumb-terminal, ncurses, or X11 method, and whether you are a beginner or advanced user, the most important feature on all the kernel configuration screens is the HELP option. Almost all kernel features are documented right in the configuration screen; whether you are looking at options for installing sound or network support or seeking expert options for filesystems and firewalls, most options carry very reassuring advice: "It is safe to say Y" (or N).

Code Maturity Level

Although a "stable" kernel release such as the 2.4 series is considered to be ready for prime time, the kernel will still offer some features deemed experimental. These may be for supporting new technology for which a standard is not yet set, or they may simply offer new techniques that were considered too essential to omit, but were not completely stable at the time of the release.

This option will also include older kernel options that have been replaced or otherwise considered obsolete. Again, the inference is that these modules were dropped from the mainstream for good reason and although you may need this support to use the kernel on old hardware, the module may be less stable than normally expected, and it may no longer have active developers.

All experimental features are clearly marked; you can only select them if you have specifically enabled experimental services. The experimental code may be essential to your purpose; for example, your real-world testing is essential to the success of these experimental components. You are encouraged to try these new features, report on their results, and file proper bug reports, but do remember these components are not considered stable. We are asked not to flood the mailing lists and newsgroups with complaints, and, if your kernel fails to load or crashes mid-stream, you should suspect experimental modules first, and remove all experimental modules before you suspect you have found a bug among the stable modules.

Processor Type and Features

Most distributions are preset for the safest setting, the old Intel 386 computer. This may be the first kernel option you will change.

Use this option with due caution. Compiling for an advanced CPU may mean your kernel will not boot or will fail on an older machine. This is also true for excluding the floating-point co-processor emulation. A 386-SX may not run if the emulator is missing. Table 27.1 shows the recommended mapping of processor types to processor options.

Table 27.1. Intel CPU Kernel Options

Intel CPU Options: Microcode, MSR, and MTRR

The CPU microcode option is required to use the userspace tools to insert updated microcode into Intel Pentium Pro, Pentium II, Pentium III, and Xeon processors. Note that this uploading is not persistent; rebooting the computer will return to the original microcode and requires re-inserting the update in the boot scripts.

The MSR option will create a /proc entry for the model-specific registers of the Intel CPU, making the RDMSR and WRMSR instructions accessible by userspace programs. These registers provide access to the FPU execution state, the time stamp counters, and performance monitoring.

Detailed information on Intel MSRs can be found in the Pentium Processor User's Manual (http://x86.org/intel.doc/586manuals.htm).

For Pentium II and Pentium Pro machines supporting the Memory Type Range Register (MTRR), Linux can double video transfer performance through the MTRR option. To use MTRR, you must use an X server that can use MTRR through either ioctl() calls or through the /proc/mtrr pseudo-file. You can query your MTRR system through cat /proc/mtrr, and code for manipulating the interface is provided in linux/Documentation/mtrr.txt. An initialization bug on some Symmetric Multi-Processor (SMP) machines can also be corrected by including MTRR support.

High Memory Support

Linux will support up to 64 gigabytes of RAM, but this support must invoke Intel Physical Address Extensions (PAE) to use memory above the 4GB limit. All Intel Pentium series CPUs and the new ia64 support PAE, but enabling this option will crash on CPUs that do not support PAE. For systems with up to 1GB of RAM, no special options are required, and for systems with between 1GB and 4GB of RAM, the 4GB option will split memory into a 3GB space useable by other applications and a 1GB region for internal use by the kernel.

SMP and IO-APIC

With the 2.4 kernels, SMP will support up to 16 processors on Intel x86 machines; SMP support for other architectures is still considered experimental.

Symmetric Multi-Processing (SMP) can have some unexpected side effects and enabling this option can restrict the portability of your kernel. Whereas a non-SMP kernel will run on a multi-CPU machine (but will use only one processor), an SMP kernel will slow a single CPU machine, hang on ix486 machines, and different architectures such as Pentium III versus Pentium Pro will not run the same SMP code. SMP will also require the Enhanced Real Time Clock Support and will disable Advanced Power Management; you may also need to set your BIOS options for Unixware. For more information on SMP support, look up the SMP-FAQ (http://www.irisa.fr/prive/mentre/smp-faq/).

The Advanced Programmable Interrupt Controller options APIC and IO-APIC are generally related to SMP machines but may be supported on some single-processor boards; the option will not slow the kernel if your hardware lacks this support, so it is safe to set this option, and this support will be automatically included if you select SMP.

Loadable Module Support

It is hard to imagine a circumstance in which you would not want to include module support and enable the kernel module loader. For most situations, module support allows the kernel to support many devices and filesystems without incurring the overhead of including this support at all times. In some situations, incompatible devices can share ports through the loading and unloading of modules, such as when using a single parallel port for both a printer and for a parallel-port SCSI drive.

Modules are usually loaded by init scripts or other shell scripts that explicitly call the insmod and rmmod utilities to load and unload modules as needed. Modern kernels automagically load modules as needed through the program specified in /proc/sys/ kernel/modprobe (usually /sbin/modprobe) and then clear out unused modules through explicit calls to rmmod -a; this cleanup is often added to the root crontab:

001 0-59/5 * * * * /sbin/rmmod --a
002 

General Setup

General options setup includes enabling networking, PCI hardware, Microchannel and Parallel ports, Advanced Power Management, and support for ELF, aout, and other binary executables. For most Intel-based Linux systems, the important details here will be the Parport and PCI options. Advanced administrators will probably want to pay close attention to the PCI options and to the new sysctl interface.

PCMCIA

New in the 2.4 kernel, support for plug-in devices, typically the "PC-Card" or PCMCIA cards used in laptops, have been folded into the main kernel source tree. If you had previously configured a laptop using the pcmcia-modules package, this will be familiar ground.

Networking Support

Unless you have a very good technical reason (that is, you know what you are doing), you will include networking support. Many applications require this module, even on non-networked machines. You must also ensure your version of net-tools understands the new /proc/dev/net (net-tools-1.50 is also required to accommodate IPv6 protocol).

BSD Accounting

BSD Accounting is of most interest to ISPs and others who need to trace and track the use of their systems for billing or other accounting purposes. Adding BSD Accounting will create a special file that logs system process information, allowing compatible software to gather detailed usage information.

SysV IPC (DOSEMU)

Interprocess Communications (IPC) is an MS-DOS protocol for synchronizing and exchanging data between separate programs. If you plan on running the DOSEMU MS-DOS Emulator, you must include IPC. Although, now that kmod has replaced the old Linux 2.0 kerneld dynamic loader and allows the automatic loading and unloading of kernel modules, there is no real need to include IPC in the main kernel; removing kerneld support from the IPC module has also reduced its size by 40%.

sysctl Support

Adding sysctl provides means for controlling the running kernel either through system calls, or, if the /proc filesystem is enabled, through pseudo-files in the /proc/sys directory. In the /proc interface, the directory is partitioned into several areas that govern different aspects of the kernel:

• dev/device—Specific information (for example, dev/cdrom/info)
• fs/control—Control of specific filesystems, such as setting the number of file-handles and inodes, dentry and quota tuning, and configuring the support for arbitrary binaries (see Support for Misc Binaries later in this chapter)
• kernel/—Kernel status and tuning
• net/—Networking parameters
• sunrpc/—SUN Remote Procedure Call (RPC)
• vm/—Virtual memory, and buffer and cache management

These services are both powerful and dangerous. Be sure you know what you are getting into before you fiddle with these files! Kernel parameters include the interpretation of Ctrl+Alt+Delete, the time delay for a reboot after a kernel panic, your system host and domain name, and a number of architecture-dependent features for the Sparc and Mac platforms. The sunrpc directory also includes debug flags for kernel hacking of remote procedure calls.

Detailed information on using and interpreting all these features can be found in linux/Documentation/sysctl/.

Virtual Memory Tuning Through sysctl

Virtual memory tuning allows for hand-optimizing the machine for disk activity. For example, by setting the system's tolerance for dirty memory pages to a higher value, the kernel will have less disk activity (which saves power and improves speed) although it increases the risk of thrashing if real memory becomes scarce). On a very large-memory machine with a lot of memory, the default behavior of the caching algorithm could be modified with

echo "80 500 64 64 80 6000 6000 1884 2" >/proc/sys/vm/bdflush

This would restrict the flushing of the dirty buffers until memory was 80% full (plus some other changes, see linux/Documentation/sysctl/vm.txt). For a single-purpose machine that had to run many processes, other options could be modified, making the buffer cache claim a major chunk of the total memory and then restricting the pruning of this cache until nearly all of this memory was consumed:

echo "60 80 80" >/proc/sys/vm/buffermem

Keep in mind that these changes may improve file or process performance for one purpose, but they might upset this machine terribly for many other purposes. Be certain you know what you are doing before you install any optimization.

Other tunable vm parameters include setting the number of pages that can be read in one transaction and removing the page-table caching for single-CPU machines with limited memory such as embedded systems and older machines.

Support for Misc Binaries

Long before other operating systems supported Java from the command line, this feature was added to the Linux kernel. Later, this was generalized to all binary and interpreter types. Using the sysctl pseudo-files, Linux can integrate Java, MS-DOS, Windows, tk/tcl, Perl, or any other strange executable as seamlessly as an ELF binary or a shell script.

To use the misc binaries support, you must register the "magic cookie" of the file type and the corresponding interpreter through the sysctl pseudo-files in /proc/sys/fs/ binfmt_misc. The magic cookie can be derived from the first few bytes of the file or from the filename (such as .com or .exe), and can be registered by echoing a control string to /proc/sys/fs/binfmt_misc/register. The format of the command string is

:name:type:offset:magic:mask:interpreter:

where

• name is an arbitrary identifier for this executable type.
• type specifies M or E denoting whether the cookie is by mask or by extension.
• offset is the count in bytes from the front of the file where the cookie occurs. If omitted, the default is zero.
• magic is the sequence of bytes to match. Hex codes may be specified as \x0A or \xFF (be careful to escape the slash character if you set this through a shell statement!). For Extension matching, the magic pattern is the extension string that follows the last dot in the filename.
• mask is also optional and, if included, must be the same length as the magic sequence. The bits in the mask are applied against the file contents before comparison to the magic cookie sequence.
• interpreter is the program invoked to run the executable.

To use misc binary support, you could create a boot script in /etc/rc.d/init.d to echo the control strings to /proc/sys/fs/binfmt_misc, or add these statements to your /etc/rc.d/rc.local. For example, to emulate the original Java support, you might add the following line to the end of /etc/rc.d/rc.local:

echo ':Java:M::\xca\xfe\xba\xbe::/opt/jdk/bin/javawrapper:'>     /proc/sys/fs/binfmt_misc/register

This creates /proc/sys/fs/binfmt_misc/Java in the sysctl directories, and lets you run any Java application by simply using the full filename on the command line. Support for running applets through appletviewer might be added by the following:

echo ':Applet:E::html::/usr/local/jdk/bin/appletviewer:'>      /proc/sys/fs/binfmt_misc/register

Before this will work, you need a special wrapper script to run the Java interpreter. Brian Lantz provides a sample script in linux/Documentation/java.txt (see Listing 27.2). Once installed and registered, Java applications and applets can be run from the command line. Use chmod +x to set the .class or .html file as executable and then simply call it from the command line:

./HelloWorld.class

or

./HelloApplet.html

Adding similar support for JDK 1.2 jar files is left as an exercise for the reader.

Example 27.2. Lantz's Wrapper Script for binfmt_misc Java Support

#!/bin/bash
# /opt/jdk/bin/javawrapper for binfmt_misc/java

CLASS=$1
# if classname is a link, we follow it

if [ -L "$1" ] ; then
   CLASS=   `ls --color=no -l $1 |tr -s '\t '''|cut -d ''-f 11`
fi

CLASSN=`basename $CLASS .class`
CLASSP=`dirname $CLASS`

FOO=$PATH
PATH=$CLASSPATH

if [ -z "`type -p -a $CLASSN.class`" ] ; then
# class is not in CLASSPATH
   if [ -e "$CLASSP/$CLASSN.class" ] ; then

# append dir of class to CLASSPATH

      if [ -z "${ CLASSPATH} " ] ; then
         export CLASSPATH=$CLASSP
      else
         export CLASSPATH=$CLASSP:$CLASSPATH
      fi
   else

# uh! now we would have to create a symbolic link - really
# ugly, i.e. print a message that one has to change the setup

   echo "Hey! This is not a good setup to run $1 !"
   exit 1
   fi
fi

PATH=$FOO
shift
/usr/local/jdk/bin/java $CLASSN "$@"

To run Windows applications via the WINE emulator, you could add the following line:

echo ':DOSWin:M::MZ::/usr/local/bin/wine:'>
    /proc/sys/fs/binfmt_misc/register

You can read the status of a binfmt_misc file by using cat on the filename. For example, cat /proc/sys/fs/binfmt_misc/Java might produce the following:

enabled
interpreter /usr/local/jdk/bin/javawrapper
offset 0
magic cafebabe

Power Management

New to 2.4, Linux includes support for the more complete Advanced Configuration and Power Interface. ACPI is an open and extensible power-saving specification co-developed by Compaq, Intel, Microsoft, Phoenix, and Toshiba and is intended to supercede the older APM standard. ACPI features support for "smart batteries," general-purpose event trapping, and Super I/O (SIO) devices.

Like APM, ACPI requires hardware support on the motherboard. The complete protocol is described on the ACPI home page (http://www.teleport.com/~acpi/). For the very adventurous, Linux includes an ACPI Interpreter, which can be added to the kernel to allow experimenting with the power-saving modes.

The older Advanced Power Management (APM) is more widely supported and has been included on most motherboards since about 1996. Note that Linux APM does not power down hard drives and the use of APM is almost exclusively restricted to battery-powered computers such as laptops. Although APM is a very good idea in principle, there are many different interpretations of the standard among laptop manufacturers.

APM support is a prime suspect when debugging laptop kernel problems, so when in doubt, turn off all APM options and only enable each one as you verify that it is either useful or benign.

In addition to the traditional battery-control support, Linux 2.4 now provides limited energy-savings support for "green" monitors. Similar support at the application level is also now appearing in GNOME and KDE.

Memory Technology Devices (Flash Memory)

Memory Technology Devices are the "flash" memory cards (typically found in digital cameras and other portable devices) and "disk on a chip" components used in embedded applications. The MTD support is also responsible for RAM disks and can be used to access otherwise inaccessible memory regions (see the section High Memory Support).

Watchdog Support

Detailed support for hardware-based watchdog systems comes later in the configuration, but this general option also allows for a software-based watchdog. The watchdog option enables a periodic update of /dev/watchdog; userspace software can then force a reboot if these updates fail to occur. This is useful where the machine is unattended and must be rebooted if any sort of lockup occurs. If you are using the software watchdog, you may also want to append panic=60 as a boot parameter in /etc/lilo.conf.

linux/Documentation/watchdog.txt includes information on watchdog hardware manufacturers and source code for creating a software watchdog update program.

Parallel Ports (parport)

Parports are an abstract representation of the parallel ports separating architecture-dependent code from the parallel interface. Parports allow developers to create parallel port device drivers for multiple hardware architectures, and the separation also allows sharing the same physical parallel port between many devices. For example, you can use the same port for both a printer and a ZIP drive or Qcam video camera.

Parallel ports can be dangerous beasts to probe, especially when many onboard ports may be fixed at IRQ numbers that conflict with sound and network cards. It is best to avoid probing and to specify the port addresses and IRQ settings of the parallel port hardware by setting the IRQ values in your computer CMOS and then appending the parameters to the bootparams, or by loading parport as a module and specifying the parameters on the insmod command line or in /etc/modules.conf. By default, the parport module does not probe for IRQs and will initialize all parallel ports in "polling" mode.

Parport splits parallel port control into two modules: the basic parport to manage port sharing and an architecture-dependent layer, for example, parport_pc. Either may be compiled into the kernel, or built as a module and loaded as needed. Port configurations can be set with bootparams, or, when built as modules, with insmod command line or /etc/modules.conf. For example, to manually load parport and the parport_pc as modules:

# insmod parport.o
# insmod parport_pc.o io=0x3bc,0x378,0x278 irq=none,7,auto

This would install three parallel ports, where the first is in polling mode, the second on IRQ7, and the third is probed for the current values. A more common method is to specify the parport_pc options in /etc/modules.conf and to load the port with modprobe or to let the kmod load it automatically.

Once these modules are installed, parport_probe can be inserted to query for IEEE1284-compliant devices—this will output a status report to the system messages and to /proc/parport/x/autoprobe. Other files in /proc/parport/x include the devices file where parport will record the attached devices and flag those currently using the port, as well as the irq file. irq can be used to query the IRQ number of the port and also to set this value by echoing either the number or none to that file.

Modules that require the parallel port can be given bootparam options to direct them to a particular port. For example:

# insmod lp.o parport=0,2

This will install printer support only on ports 0 and 2, rather than the default action of installing the module on all available ports. As with all bootparams, you can also do this by adding lp=parport0 lp=parport2 to the boot prompt or in /etc/lilo.conf.

Plug-and-Play Support

These options enable kernel support of generic plug-and-play devices, and enable probing of devices attached to the parallel ports for mapping peripherals to parport modules. In general, probing parallel ports for IRQ numbers can cause problems. A better course is to explicitly specify your parport options through bootparams (see the preceding section).

Block Devices

The Block Devices dialog contains options for out-of-the-ordinary disks such as Parallel-Port IDE, Logical Volumes, and RAID systems. With the 2.4 kernel, options for the low-cost IDE/ATA disks have been factored out into the section "ATA/IDE Support."

Floppy Disk Driver

Because of its use for other devices (such as tape backup units) and its capability to run multiple disk controllers, the floppy disk driver is worth some attention. It also serves as a typical example of the fine control achieved through the bootparam interface.

The following is a partial list of floppy driver options:

• floppy=daring—With well-behaved (modern Pentium) controllers, this option enables optimizations that can improve throughput, but may fail on incompatible systems.
• floppy=one_fdc, floppy=two_fdc, floppy= address ,two_fdc—These options set the number of controllers. The default is a single FDC. The dual controller option can specify the address, use a default of 0x370, or query CMOS memory if the cmos option is selected.
• floppy= drive, type ,cmos—Sets the CMOS type of the specified drive to the given type and is a required option on systems with more than two floppy drives. Codes for the CMOS types can be found in drivers/block/README.fd.
• floppy=thinkpad—Alerts the driver to the inverted convention for the disk change line used in some IBM ThinkPad laptops.
• floppy=L40SX—Prevents the printing of messages when unexpected interrupts are received, and it is required on IBM L40SX laptops to prevent a conflict between the video and floppy disk controllers.
• floppy=omnibook, floppy=nodma—Prevents using DMA for data transfers. You will need this option if you get frequent "Unable to allocate DMA memory" messages or if you are using an HP Omnibook. DMA is also not available on 386 computers or if your FDC does not have a FIFO buffer (for example, 8272A and 82072). When using nodma, the FIFO threshold should also be set to 10 or lower to limit the number of data transfer interrupts.
• floppy=yesdma—Forces DMA mode. When using a FIFO-enabled controller, the driver will fall back to nodma mode if it cannot find the contiguous memory it needs. The yesdma option will prevent this. This option is the default setting.
• floppy=nofifo—Required if you receive "Bus master arbitration" errors from the ethernet card (or any other devices) while using your floppy controller. The default is the fifo option.
• floppy= threshold ,fifo_depth—Sets the FIFO depth for DMA mode. A higher setting will tolerate more latency, but will trigger more interrupts and impose more load on the system; a lower setting will generate fewer interrupts but will require a faster processor.
• floppy= nr ,irq, floppy= nr ,dma—Sets the IRQ and DMA for the given device. The defaults are 6 and 2, respectively.
• Floppy=slow—Required on some PS/2 machines that have a dramatically slower step rate.

The full list of FDC module options can be found in drivers/block/README.fd and the fdutils package. A set of floppy driver utility programs, including an enhanced mtools kit, can be downloaded from the misc directory on MetaLab (ftp://metalab.unc.edu/pub/linux/system/misc/).

insmod floppy 'floppy="daring two_fdc"'

PARIDE and parports

Parallel-IDE support (PARIDE) can safely combine both parports and paride devices on the same physical parallel port; if parport is included as a loadable module, paride must also be included as a module. Also, if paride is included directly into the kernel, individual protocols for disks, tapes, and CD drives may still be included as modules and loaded dynamically as needed.

Loopback Disk Devices

Loopback disks are somewhat cool: loopback allows you to treat a normal file as a separate filesystem. For example, you can mount and test a CD-ROM or floppy disk image before committing the image to the physical disk. This also allows you to use cryptographic methods to secure a filesystem. Before using the loopback disk devices, you will need to ensure that your util-linux package is up to date with the requirements of linux/Documentation/Changes.

Network Block Devices

Using Network Block devices allows the client to transparently use a remote block device over TCP/IP—this is very different from NFS or CODA. For example, a thin client could use an NBD disk for any filesystem type, including as a swap disk.

Logical Volume Manager (LVM)

LVM puts an additional layer between the physical filesystems and the OS and allows binding two or more partitions or disks into a single virtual disk. These storage units are then accessed through special device files of the form /dev/groupname/volumename. LVM also allows changing the logical groups at runtime, effectively altering the size of the storage unit as required.

Multiple Devices and Software-RAID

For those needing reliable and reasonably efficient redundant filesystems on a tight budget, Linux includes a Software-RAID package that binds several disks as one RAID unit. Multiple Devices support can be used to append, stripe, or mirror partitions together to form one logical partition.

More information on Software-RAID can be found on in the Software-RAID HOWTO (ftp://metalab.unc.edu/pub/linux/docs/howto/mini).

Networking Options

UNIX was designed from the start to be a networking operating system, and Linux follows this tradition. In UNIX, computers are not isolated personal possessions, but nodes, mere portals, points of entry into a much larger network. Building a workstation without network services is like building an office with no windows or doors. Yes, it's is very secure, but…

Most small-network installations will only need TCP/IP and perhaps IPX to coexist with Windows machines or to run the DOSEMU MS-DOS emulator. You can also add CODA or NFS network filesystems to share disks between machines. A popular option is to configure a Linux machine as a firewall and dialup-gateway for a home office or small enterprise. Small Novell-based shops will also require IPX support en route to using Linux as a high-powered NetWare fileserver.

For the enterprise network administrator, however, this dialog box is a playground of protocols, with options, system diagnostics, and controls that position Linux as the glue holding the enterprise together. Linux can be optimized for routing or forwarding between interfaces, and set as a secure WAN router for a virtual private network over the Internet. Linux speaks IPX, Appletalk, Acorn Econet, and Ipv6. It can log attacks, perform multicast (MBONE) routing, encapsulate IP over IP, do IP masquerading (to give machines inside the firewall access to services without using a proxy server), provide ARP services over huge networks, and boot a diskless client. It's pretty darn amazing, and it keeps getting better.

Kernel Netlink Socket

Netlink is a communication channel between kernel services and user programs through a special character device in the /dev directory. This interface can be used by the Routing Messages package to log network behavior, or by the IP Firewall Netlink device to log information about possible attacks. Netlink is also required when you're using the arpd daemon to map IP numbers to local network hardware addresses outside of kernel space, or when using ethertap (user programs using raw ethernet frames).

Network Firewall

The only firewall impervious to attack is implemented with scissors. We all do what we can to be as secure as we need to be, balancing cost, necessity, and practical realities. If you need almost-scissors, Linux will take you there, too, but for more modest security requirements, the stock kernel firewall provides decent protection with a minimum of fuss.

The Network Firewall is a packet-based protection that will accept or deny incoming or outbound packets based on the port, the protocol, and the originating and/or destination network IP addresses. Proxy-based firewalls can expand this protection and use knowledge about the protocols to provide additional security, but this most often requires modified software, and more work to install. Even if you plan to use a proxy-based system, most often these systems also require including the packet-based firewall. For most situations of a gateway firewall for a small or medium-sized enterprise or a home office, packet-based protection is simple, easy to install, and offers pretty good security.

To set up a TCP/IP firewall, you must include Network Firewall and IP:Firewalling. Adding IP:masquerading will give inside machines access to services outside the firewall; the remote computer will perceive these connections as originating from the firewall machine, removing the need to register IP addresses for all local network hosts that require outside connections.

For example, Let's say your office LAN includes a workstation that needs HTTP and ICQ access. Using IP:masquerading, this workstation can run Netscape or ICQ without any proxy and can connect directly to the Web site or ICQ servers. An extra level of security can be added to this scheme by enabling IP:Transparent Proxy, which silently redirects traffic from local machines to a predesignated proxy server address.

Basic IP:Masquerading will only redirect UDP and TCP traffic. This blocks some Windows applications that depend on ICMP packets, such as ping and tracert. Support for these applications can be enabled through the IP:ICMP Masquerading option.

Inside hosts cannot receive connections unless port forwarding is enabled using the Special Modules options. Through the external port administration utilities ipautofw and ipportfw, the Linux firewall can provide a gateway for outside machines to reach services on inside machines by forwarding packets for predefined ports. For example, if the gateway machine is not using X11, port 6001 can be forwarded to another machine to run remote X11 applications.

Optimize as Router

This option prevents checksum operations on incoming packets that are not required when using the machine exclusively as a router. In the future, this option may contain other router-only optimizations.

IP Tunnelling

IP Tunnelling connects two LANs across another network while staying under the same network address. For example, machines at a trade show could use services only available inside the corporate firewall, or a roaming user in a hotel room could be granted access to his office files. The basic support for IP Tunnelling wraps plain IPv4 inside IPv4. The GRE tunnel support is more useful if you are connecting through Cisco routers, and can also encode IPv6 inside IPv4.

GRE/IP can create what appears to be a normal ethernet network, but which can be distributed all over the Internet. For example, this would allow all branch offices of a global enterprise to use the same LAN IP numbers and to appear to be within a single firewall. This feature requires GRE Tunnelling with the GRE Broadcast and IP:multicast.

echo 1 >/proc/sys/net/ipv4/tcp_syncookies

IPX and Appletalk Support

IPX adds Novell NetWare services and enables your Linux machine to communicate with NetWare file and print servers through the ncpfs client program, available from the MetaLab Archives (ftp://metalab.unc.edu/pub/linux/system/filesystems/). IPX also allows DOSEMU programs to access the network.

AppleTalk provides similar support for Apple services using the netatalk program. Details can be found in the Netatalk FAQ (http://www.umich.edu/~rsug/netatalk/faq.html). Linux supports both AppleTalk and LocalTalk Mac protocols. According to the recent kernel help files, the GNU boycott of Apple is now over, and so even politically correct people may now set this option.

Linux may be configured as a fully functional NetWare server, and even provides support for the SPX protocol. For more information on IPX services, see the IPX-HOWTO, which can be found at the Linux Documentation Project (http://www.linuxdoc.org).

Installing Linux as the Grand Unified Network Field is content enough for its own book, but general information on configuring Linux to glue together a heterogeneous network of Novell, Macintosh, and TCP/IP workstations can be found at Linux/Mac/Win Web page (http://www.eats.com/linux_mac_win.html).

Enterprise Networks and X.25 Support

Enterprise administrators will be most interested in the Linux support for X.25 protocol. This is a method for putting many virtual circuits through one high-speed line. This support is presently labeled experimental and does not yet include support for dedicated X.25 network cards. Linux does provide X.25 services over ordinary modems and Ethernet networks using the 802.2 LLC or LAPB protocols.

The WAN option is also of interest to enterprise admins looking for an inexpensive alternative to a dedicated WAN router. Using commercially available WAN interface cards and the WAN-tools package from Sangoma (ftp://ftp.sangoma.com), a low-cost Linux machine will make a perfectly serviceable WAN router. This router can also still be used for other purposes, such as providing a firewall, a Web server, or an FTP site. For the serious enterprise, the FreeS/WAN project in Toronto has a free encryption layer for the Linux WAN, using 1,024-bit keys and 168-bit Triple-DES technology, and incorporating the Internet Protocol Security (IPSEC).

Related to X.25 and WAN, Linux also provides support for frame-relay. Look under the DLCI options in Network Devices for more information.

Ethernet Bridging

Ethernet Bridging will bind together the network segments on multiple Ethernet cards to create one seamless network. Several such nodes can be used to link multiple composite networks. For more information, consult the Ethernet Bridge Mailing List home page (http://openrock.net/mailman/listinfo/bridge).

Forwarding on High-Speed Interfaces and Slow CPUs

One popular use of Linux is to breathe new life into aging hardware. This can, however, lead to networking problems because even a 120MHz machine can be overrun by a 10Mb/sec ethernet connection. If you experience trouble with network overruns, these options will modify the network support to accommodate the slower machines.

Telephony Support

Telephony support is the product of work done by Quicknet Technologies (http://www.quicknet.net) to support their Internet PhoneJACK and Internet LineJACK telephone, key system, and PBX connectors for Voice over IP (VoIP) applications. These drivers are highly experimental and are only intended as development tools for Quicknet card owners.

ATA/IDE Support

Linux will support up to eight low-cost ATA/IDE drives. With Linux 2.1/2.2, support was also added for IDE ATAPI floppy drives, tape drives, and CD-ROM drives (with auto-detection of interfaces), IRQs, and disk geometries. The new driver now adds support for PIO modes on OPTi chipsets, SCSI host adapter emulation, and PCI Bus-master DMA, as well as support for many PCI chipsets, and detection of buggy PCI IDE systems, such as the prefect feature of the RZ1000 or "IRQ unmasking" on the CMD640. Full details of the IDE driver and supported systems can be found in linux/Documentation/ide.txt.

While the driver automatically probes for disk drives, geometries, and IRQs, these interfaces may be specified using kernel bootparam. For example, to set the port addresses and the IRQ for the fourth controller set ide3=0x168,0x36e,10 .

The driver will probe for the IRQ if it is omitted. Any number of interfaces may also share an IRQ, although this will degrade performance. The driver will detect and account for this situation, but your controller cards may suffer damage in the process (theoretically).

Disk geometry can also be specified on the command line as three numbers for sectors, cylinders, and head, as in hdc=768,16,32. If your CD-ROM is not being detected, you can give the kernel an extra nudge by using the hdd=cdrom option.

IDE interfaces on sound cards may require initialization before they can be used. The program to initialize the driver is most often among the software that comes with the card and is usually part of the MS-DOS driver—the only alternative for using these devices is to boot your computer under MS-DOS, to allow the drivers to initialize the device, and then to use loadlin to switch to Linux.

Older hard drives may not be compatible with the newer IDE driver. In this situation, you can include both interfaces in the kernel. The older driver will command the primary IDE interface while still allowing newer hardware to be used on the other interfaces.

insmod ide.o options="ide0=serialize ide2=0x1e8;0x3ee;11"

SCSI Support

SCSI drives are more expensive than IDE, but give much higher performance and are the method of choice for large enterprise servers. Linux SCSI support is also required for certain parallel-port disk devices, such as the Omega ZIP drive. Linux also supports SCSI CD-writers, scanners, and synthesizers via the SCSI Generic option, and provides options for logging errors and activity on these devices.

To enable SCSI support, you need to know your hardware. The Low-Level Drivers dialog presents a long list of supported adapters, with some options for setting device parameters.

IEEE 1394 FireWire Support

FireWire is a high-performance serial bus, also known as i.Link and described by the IEEE 1394 standard. This hardware is most often used with digital video cameras and other high-speed peripherals, and I/O cards with this support are available from Texas Instruments, Adaptec, and on the Miro DV boards. With the exception of the RAW option to enable direct manipulation of FireWire by userspace programs, the remaining options in this section select among specific vendor implementations.

I²O Support

Intelligent Input/Output uses a coprocessor for interface adapters and is designed to separate the logical device from the physical implementation. Drivers for I²O devices can be written to an abstract Operating System Module (OSM) definition that is portable across many hardware implementations of the standard. These devices include block devices (disks), network interfaces, and SCSI devices.

I²O also includes a sysctl option to allow probing the driver through the /proc/i2o files.

Network Device Support

If you have a network card, you must specify the network hardware. If you have a network card but don't know what it is, if it is a cheap one, it is more than likely an NE2000-compatible.

The main network device option links in the basic network subsystem. You must enable this support even if you only connect to networks via local SLIP, PPP, or PLIP, or if your machine will dial an ISP to connect to the Internet.

Dummy Network Device

The Dummy device is just that: It holds a place for a device and discards any traffic sent to it. This is most often used to make SLIP or PPP interfaces appear to be active even while offline. For example, if you are using a demand-dialing program such as diald, the Dummy device will enable network programs to function, but the packets sent to this interface will be re-routed through to the Internet after the dialer has established the connection.

EQL and Ethernet Bonding

EQL is rarely used, but extremely useful. In these days of wave modems and cheap xDSL lines, we often forget that many do not have the luxury of cheap, high-speed dialup lines. Using EQL, Linux can bind together several modems as the same IP interface and effectively multiply the bandwidth. For example, a rural school could install a Linux gateway server with demand-dialing sensitive to the bandwidth requirements. When one phone line became saturated (old-copper rural lines are often 31.2KB), a second line could be opened to the same ISP, and then a third, and so on, giving the school symmetric, ISDN-like bandwidth for the cost of a few extra phone lines. EQL does require support at both ends of the connection. It works very well with the Livingstone Portmaster 2e, which is fortunately a popular choice among smaller ISPs.

Ethernet Bonding provides the same service for ethernet cards, tying together multiple network interfaces as a single virtual interface.

PLIP, PPP, and SLIP Dialup Networking Support

PLIP is a means to network two machines over a null-printer ("Turbo Laplink") cable to provide four or eight parallel data channels. This is often used to NFS-install to a laptop where there is no CD-ROM. Wiring for this cable is described in Documentation/ networking/PLIP.txt. Russell Nelson has also created MS-DOS drivers for PLIP to connect DOS-based machines (such as that old PS/1 space heater I keep in the workshop).

SLIP is the ancestor of PPP, and although 99.9% of all ISPs will only offer PPP connections, SLIP still has some viable uses. SLIP is an essential ingredient as an intermediary device in the diald demand dialer or to gain a network connection over a telnet session (using SliRP).

Amateur Radio and Wireless Support

Another low-cost Internet solution for impossible remote locations is the Amateur Radio Support. By encoding packets over short-wave radio, Linux systems have been used to provide as much as 64KB of symmetric bandwidth over long distances. For examples of packet radio in action, see the Wireless Papers (http://www.ictp.trieste.it/~radionet/papers) or visit the Packet Radio home page (http://www.tapr.org/tapr/html/pkthome.html).

A related feature of interest to campus and rural development projects is the kernel support for Wireless LAN, AT&T WaveLAN, and DEC RoamAbout DS (see Documentation/ networking/wavelan.txt). There is also support for the MosquitoNet (http://mosquitonet.stanford.edu/) StarMode RadioIP systems used by many laptop owners.

IrDA: Infrared Port Device Drivers

Infrared Data Associations protocols provide wireless infrared communications between laptops and PDAs at speeds up to 4Mbps, and the Linux driver makes supported devices transparent to the networking system. More information on this support, and on the utility programs for IrDA, can be found at the Linux Documentation Project (http://www.linuxdocs.org) or the Linux IrDA home page (http://www.cs.uit.no/linux-irda/).

ISDN Subsystem

To use ISDN, you must obtain the isdn4k-utils utility programs (ftp://ftp.franken.de/pub/isdn4linux/). When the module is loaded, isdn.o can support up to 64 channels (you can add more by changing the isdn.h file directly). Each channel will be given read/write access to the D-Channel messages and ioctl functions, with non-synchronized read/write to B-Channel and 128 tty-devices. Modem emulation provides a standard AT-style command set compatible with most dialup tools, such as minicom, pppd, and mgetty.

The second step in configuring for ISDN is to select your specific ISDN modem card. Some ISDN cards will require initialization before the vendor-independent setup. Details can be found in the appropriate README file under linux/Documentation/isdn.

Old CD-ROM Drivers (Not SCSI or IDE)

Old CD-ROM drivers include the early SoundBlaster Matsushita and Panasonic CD-ROMs included on many 16-bit sound cards. If you have a clone card with a socket for a CD-ROM drive, and it was made before 1994, it is likely one of these interfaces; if it is newer, it could still be an IDE-type CD-ROM.

Character Devices

Character devices communicate with the kernel via a stream of characters. These include terminals, serial ports, printers, cameras, voice synthesizers, and also some virtual devices such as the CMOS memory and the watchdog. If you're working with most desktop installations, this section option will be simply a matter of adding or removing printer support. On the other hand, you'll find this option very interesting if you're working with data acquisition projects.

Terminals and Consoles

Most applications will configure the kernel for at least one console. There are some embedded applications where this code will not be needed, but for most people, having multiple virtual consoles mapped to the Alt+Fn keys is very useful.

Another useful feature is to have console messages sent to a terminal attached to a serial device. This can be used to keep a printed log of system messages or have an emergency terminal port available on an otherwise head-less embedded application. Keep in mind that the serial console will not be enabled by default if you have a VGA card installed, and it must be explicitly enabled using the console=ttyN bootparam.

Serial Ports

In addition to plain old serial ports, Linux also permits IRQ sharing (where supported by the hardware) and systems with more than four serial ports. Many data-acquisition systems and smaller ISPs also use the multiport serial boards that can be included with these options.

Unix98 PTY

Linux now supports the Unix98 standard for the /dev/pts ports. This option requires glib-2.1 and also requires the /dev/pts filesystem, but it is highly recommended. Although it will take you some time to shift habits to the new naming convention, Linux has a clear resolve to move toward this system and obsolesce the old /dev/tty conventions. Under the new rules, pseudo-terminals are created on-the-fly under /dev/pts/N. The old convention of /dev/ttyp2 will become /dev/pts/2 under the Unix98 system.

Parallel Printer

You need this option to add a parallel-port printer, but keep in mind that this module supports the printer, not the port. You will also need to install and configure the parallel port (parport) module. Also, by default, the lp.o module will install itself on all available parports unless specified by bootparams.

I²C Support

This option adds support for the alternate devices on Matrox graphics cards; this is a feature that lets you add multiple independent monitors to the same console.

Mice

These options are for bus mice and PS/2-style mouse connectors, as found in some laptop computers. Note that although some laptops do support PS/2-style mice (such as the ThinkPad 560), the internal pointer may still be a plain COM1-based serial mouse.

Watchdog, NVRAM, and RTC Devices

The watchdog timer enables a character device (mknod c /dev/watchdog c 10 130) used to reboot a locked machine. This feature is most often used with a watchdog daemon that will write to this device within the time limit. Linux includes support for a software watchdog and also for watchdog boards, which are not only more reliable, but several of them can also monitor the temperature inside your machine and force a shutdown/reboot when this rises above the allowed range.

The /dev/nvram option enables a new character device (mknod c /dev/nvram 10 144) for read/write access to the 50-byte CMOS memory.

All computers have a real-time clock; Linux lets you use it. This option will support a new character device (mknod c /dev/rtc 10 135) to generate reliable signals from 2Hz to 8kHz. The clock can also be programmed as a 24-hour alarm to raise IRQ8 when the alarm goes off. The rtc module is controlled by synchronized ioctl calls and is most often used for high-frequency data acquisition where you don't want to burn up CPU cycles polling through the time-of-day calls. Example code for using the rtc module can be found in Documentation/rtc.txt.

DoubleTalk Speech Synthesizer

No surprises here, however users of speech synthesizers may also be interested in the Blinux (distribution for the blind) and Emacspeak. Linux stands alone as the one OS that grants blind users total access to all functions of their computers and full access to all services on the Internet.

Video for Linux (V4L)

Video4Linux (V4L) is a common programming API for audio/video capture or overlay cards, radio tuning sources, teletext, and other TV-related VBI data. V4L support is needed if you plan to use any of the current TV/FM cards, and V4L can be used for videoconferencing cameras such as the Connectix Qcam. To use these services, you will also need v4L-aware applications. A few applications are currently archived at the V4L Archives (ftp://ftp.uk.linux.org/pub/linux/video4linux), and a few more, including capture and Webcam applications, are listed at the Room Three Web site (http://roadrunner.swansea.linux.org.uk/v4l.shtml).

Joystick Support

Linux will now support digital, serial, and some USB joystick controllers. The developers also hope to include support for force-feedback joysticks. A current list of supported devices and applications can be found at the Linux Joystick Web page (http://atrey.karlin.mff.cuni.cz/~vojtech/joystick/).

Ftape, the Floppy Tape Device Driver

This option is for tape drives that are connected to your existing floppy drive controller or that include their own high-performance FDC. With the widespread availability of cheap CD-writers, tape backup systems are becoming rare beasts, but still have a niche use.

Filesystems

Linux is the only operating system to offer a common ground for heterogeneous computer networks. During your first Linux install, one of your tasks was to select from a long list of supported filesystems for your Linux partition. This tradition continues with the kernel filesystem and network filesystem support. When all of this is combined with the capability to launch arbitrary executables transparently through an emulator (see the section Support for Misc Binaries), the degree of inter-OS integration in Linux becomes very clear.

The Filesystems dialog itself has few surprises. If you need floppy disks, CD-ROMs, ZIP drives, or hard drive partitions in any of the supported filesystems, you can include it in the core kernel, or, preferably, build it as a module. The /proc and /dev/pts filesystems are highly recommended unless the kernel is being built for a specialized embedded application; without these features, many standard utilities will not work.

MS-DOS and VFAT (Windows) Filesystems

The MS-DOS and VFAT filesystems are worth some special consideration, if only because they are so ubiquitous. The current kernel support for the MS-DOS/VFAT disks used by DOS, Windows, Windows 95, and Windows NT will only read and write to uncompressed disks and cannot be used on DoubleSpaced disks or partitions. To access DoubleSpaced drives, you will need to use the DOSEMU emulator, or try the dmsdosfs tools (ftp://metalab.unc.edu/pub/linux/system/filesystems/dosfs).

MS-DOS support is not needed if you only plan to access MS-DOS disks through the mtools programs (mdir, mcopy, and so on). MS-DOS support is needed only if you plan to run Linux on a second partition or hard drive and need access to files on the MS-DOS side, or if you want to mount ZIP drives or other shared media to move files between Linux and MS-DOS.

VFAT adds the additional support for long filenames and also provides several options for the DOS codepage and National Language Support for the default behavior in coping with the DOS 11-character filename limit. Details of these translation options can be found in Documentation/filesystems/vfat.txt.

ISO 9660, UDF, and DVD Support

UDF is the new standard CD-ROM format and is intended to replace ISO9660. At this point in time, UDF support means Digital Video Disk (DVD) support. Although the kernel supports the conventional ISO 9660-format CD-ROMs and will also support the Microsoft Joliet extensions for Unicode filesystems, it does not yet offer UDF. A driver for DVD and other UDF peripherals is available through the TryLinux UDF project (http://www.trylinux.com/projects/udf/).

Native Language Support

This section is a bit of a misnomer. These options do support different cultural languages, but they only support reading and displaying these character sets on Microsoft filesystems.

The first section option lists Microsoft codepages and is only an issue if your system needs to read filenames from an MS-DOS or Windows filesystem. Note that codepage support applies to filenames only, and not to the contents of the file. Similarly, to display characters from Microsoft VFAT or Joliet CD-ROM filesystems, you will also need to include at least one of the NLS options. You may select any number of languages for both systems, and any of these can be built as a module to be loaded only when needed.

Network Filesystems

Network filesystems allow you to share disk resources. Although there are obvious applications for this on a large network, even those in a small office/home office setting may want to distribute their resources. For example, our office uses an old salvaged 486/33 machine as a multiuser X-terminal for the smoking lounge. This machine runs Linux 2.2.7 from a 60MB hard drive. 60MB is enough to get the system up and running, and from there, NFS is used to supply software directories and user disk resources from upstairs in the lab.

As with the filesystems and partitions support, Linux provides a common glue for almost any heterogeneous network. Network filesystems are no exception. The 2.4 kernel can create a hub where old and new UNIX filesystems, Windows 95/NT, OS/2, and Novell can all be bound together in one workstation or one server.

CODA Distributed Filesystem

CODA is a new distributed filesystem technology, somewhat like NFS, only more flexible, more secure, and more efficient. CODA includes authentication and encryption features, disk replication, caching, and support for discontinuous connections such as laptops and teleworkers. Current Linux kernel support will allow you to use CODA client programs. Client programs and other information about this filesystem are available from the Coda home page (http://www.coda.cs.cmu.edu). The Venus client support is also described in great detail in Documentation/filesystems/coda.txt.

NFS

NFS, the old workhorse of distributed filesystems, takes a lot of criticism, but it is still the standard. CODA may take over from NFS as time goes on, but for the foreseeable future, NFS is all we have. NFS will also require running portmap with the nfsd and mountd daemons. If you are configuring a kernel for a diskless workstation, NFS cannot be loaded as a module (obviously) and you will need the IP:Kernel Level Autoconfiguration and NFS Root Partition options.

For NFS servers, you have the option of running the nfsd daemon or enabling the kernel-level NFS server. The latter choice has the advantage of being much faster (since it's in kernel space), but is still somewhat experimental.

SMB (Windows Shares) and NCP

If your LAN includes Windows for Workgroups, Windows 95/97, OS/2-LanManager, or NT machines using TCP/IP, this option will enable mounting shared directories from those machines. Note that SMB support is for the client side; exporting directories to Windows machines is done through the Samba daemon.

NCP (NetWare Core Protocol) provides similar facilities for the NetWare (IPX) file sharing used by Novell networks. As with the SMB support, this is used for mounting remote NCP drives on this machine. You do not need this option to be an NCP server.

Partition Types

Linux is unique as the only O/S to offer filesystem compatibility right down to the partition formats. This section option adds support for BSD, SunOS, Solaris, and Macintosh partitions and allows you to directly read and write disks in those proprietary formats. For example, by including foreign partition support, you can access all partitions in a multi-boot machine (such as MacOS versus Linux or BSD versus Linux), or exchange optical disks or ZIP drives with one or more of the other systems.

Console Drivers

The first two options under Console Drivers are very straightforward. The first enables support for the standard VGA graphics card (text mode), and the second adds support for the vga option in /etc/lilo.conf, which sets the VGA text mode during the boot sequence.

The remaining options are more obscure.

Option 3 adds support for using old monochrome display adapters (MDA) as a "second head" to display a text console while the main system runs X on the VGA monitor. The MDA option is only for this configuration and is not for systems using the MDA as the primary display.

Frame Buffer Support

Historically, Linux had no need for a graphical console, at least not until the Motorola 68K port, where there was no concept of a text console. As of the 2.1 kernels, all ports now have the same console code, with a hardware-specific frame buffer supporting a graphical console device (fbcon).

Frame buffers are also an alternative means to control the graphic system via a dedicated device (/dev/fb0). This is mostly an issue when compiling for platforms other than the Intel x86 or when using a Matrox Millenium or similar PC graphics card. To use frame buffers, your X-server must be aware of the feature. Although you can include FB support on an Intel platform (see Documentation/fb/vesafb.txt), be aware that mixing software that talks directly to the hardware with the fbdev method may cause a system crash. For more information, look up the FB-HOWTO (http://www.linuxdoc.org/HOWTO/framebuffer-HOWTO.html) or read Documentation/fb/framebuffer.txt.

Sound

The Linux sound driver was derived from the OSS/Free driver by Hannu Savolainen. The current kernel driver is maintained by Alan Cox and is funded by Red Hat, and this should be taken into consideration when reporting problems. For very new and/or obscure sound card support, you may need to obtain the commercial edition of the OSS drivers from 4Front Technologies (http://www.opensound.com/).

The first option in the sound configuration section is a master switch for enabling sound support. If this option is switched off in a kernel previously configured for sound, all options are preserved in the .config file, but the sound module will not be included in the resulting kernel. This is useful when you're experimenting with sound system options, or when you suspect an IRQ conflict between the sound system and some other device, such as a printer port (IRQ 7) or a network card (often on IRQ 10 or 11).

Most of this section option is what you might expect. You will need the IRQ numbers, DMA channels, and port addresses of your audio hardware. When in doubt, the HELP option will offer some advice on the compatibility of various options. There are a few items that provoke misunderstandings, for example enabling MIDI support versus enabling MIDI emulation in a SoundBlaster card, but all of these issues are explained in the HELP pages.

Linux includes support for a wide array of sound cards, from the legacy 8-bit AdLib cards to the latest high-performance wave-table systems. Since Linux 2.2, OSS/Free now also provides a software wave-table engine to bring realistic MIDI patches to even old 8-bit sound cards. This wave-table support allows for samples between 8kHz and 44kHz and up to 32 simultaneous voices; obviously, the sampling rate and the number of voices your system can handle will depend on RAM and CPU speed, but 22kHz in eight voices runs quite comfortably on a 486/33.

Frequent causes of mishaps in configuring sound cards arise from IRQ or DMA and port conflicts, from configuring a clone card as a "Sound Blaster-compatible" (most mean "SBPro-compatible" although they may run better in MSS mode), or due to plug-and-play problems. Detailed information on compatibility issues and tips on troubleshooting sound support can be found in Documentation/sound/README.OSS.

pnpdump > /etc/isapnp.conf

isapnp -c /etc/isapnp.conf
insmod sound.o

USB Support

The Universal Serial Bus (USB) standard was initiated in 1994 by Compaq, Intel, Microsoft, and NEC, originally as a means to connect the PC to telephones and to allow easily adding many new devices. Today, USB is commonly used for pointers, printers, cameras, and other peripherals that can function in the effective 2Mbit/s transfer rate of USB. USB support was originally developed by Linus Torvalds; this feature is new to the 2.4 kernel but can be grafted on to 2.2.16+ kernels.

Linux USB supports Compaq's Open Host Controller Interface (OHCI) and the Intel Universal Host Controller Interface (UHCI). Both methods have the same capabilities and all USB devices will work with both host controller types. UHCI hardware is simpler and cheaper, but requires a more complex device driver and thus causes slightly more CPU load.

More information on USB can be found at the Linux-USB Project (http://www.linux-usb.org).

Kernel Hacking

As of Linux 2.2, Kernel Hacking contains only one option: to toggle SysRQ support. SysRQ adds several very useful commands binding recovery and diagnostic operations to Ctrl+Alt+SysRq key sequences. For example, if the console or X-server becomes locked because some renegade process is blocking all I/O, you could telnet to the machine, open a superuser shell, and then kill that process or reboot the machine, but a simpler and more convenient path is to use SysRQ commands to kill the errant process, or even sync and umount the filesystems, and to force a reboot. See Table 27.2.

Table 27.2. Kernel SysRQ Commands

Alternate Configurations

The Load/Save options are a convenience for those who need to maintain several alternate configurations, for example on a machine used to compile kernels for other machines, or where you need alternate kernels for different purposes. As you would expect, this option pops up a dialog asking for the filename and then saves .config to the named location.

Saving Your Configuration

Once the kernel is configured, save and exit creates .config, and, if the kernel has been configured for sound, generates linux/include/linux/autoconf.h. The kernel is now primed and ready for building.

CML2: The Next-Generation Configuration Tool

While the configuration scripts that drive the makefile do the job with a fair degree of assurance, this system was never intended to manage a project with close to two million lines of code and hundreds of interdependent options. To ease this situation, Eric Raymond has devoted his air travel and hotel time to creating a next-generation solution, the Configuration Management Language, or CML2.

Although CML2 was not ready for the 2.4 kernel, it will be included in 2.5 as an alternative configuration method and will either become the standard by 2.6 or will be superceded by some other CML. As much pain as this causes in maintaining parallel versions, the payoff for Linux 2.6 and on will be considerable.

The current CML2 will handle all kernel configuration options, and will report and prevent incompatible or inconsistent configurations. The design of this new scripting language may also allow for someday configuring the kernel in reverse, by specifying the hardware on a form and having the CML2 interpreter deduce the correct kernel options, a large step toward someday having kernel configuration proceed automatically from the hardware detection stage.

Using CML2

In most cases, migrating configuration specs to CML2 only involves patching the main rules file kernel-rules.cml, adding the symbol declarations to kernel-symbols.cml, and ensuring the correct entry in kernel-menus.cml. Once your rules have been entered into these files, configuration specs can be tested and debugged using the cmlcompile.py utility to display the menu tree or to run the compiler in interactive mode.

kernel-rules.cml specifies all options with their suboptions and required components. For example, the menu rule for Network File Systems states

unless INET suppress CODA_FS NFS_FS SMB_FS NFSD
unless (IPX!=n or INET!=n) suppress NCP_FS
...
menu nfs # Network file systems
        CODA_FS? NFS_FS? { NFS_V3 ROOT_NFS}  NFSD? { NFSD_V3}
        SMB_FS?
        NCP_FS? { ncpfs}
...
menu ncpfs # NCP filesystem configuration
        NCPFS_PACKET_SIGNING NCPFS_IOCTL_LOCKING
        NCPFS_STRONG NCPFS_NFS_NS NCPFS_OS2_NS NCPFS_SMALLDOS
        NCPFS_MOUNT_SUBDIR NCPFS_NDS_DOMAINS NCPFS_NLS NCPFS_EXTRAS
...
unless NCP_FS!=n suppress ncpfs
...
derive NLS from JOLIET==y or FAT_FS!=n or NTFS_FS!=n or NCPFS_NLS==y

This provides all five different network filesystems when INET is enabled, but only offers the NCP_FS if IPX is set but INET is not. Where NCP_FS is enabled, the configuration will include the related NCPFS_* options. Also, NCP_FS will imply including the NLS code page support.

kernel-symbols.cml defines the pretty-print strings for the kernel symbols and is factored out of the rules file to allow for translations. This file holds no surprises:

NCP_FS          'NCP file system support (to mount NetWare volumes)'
#
# NCP Filesystem configuration
#
NCPFS_PACKET_SIGNING    'Packet signatures'
NCPFS_IOCTL_LOCKING     'Proprietary file locking'
NCPFS_STRONG            'Clear remove/delete inhibit when needed'
NCPFS_NFS_NS            'Use NFS namespace if available'
NCPFS_OS2_NS            'Use LONG (OS/2) namespace if available'
NCPFS_SMALLDOS          'Lowercase DOS filenames'
NCPFS_MOUNT_SUBDIR      'Allow mounting of volume subdirectories'
NCPFS_NDS_DOMAINS       'NDS authentication support'
NCPFS_NLS               'Use Native Language Support'
NCPFS_EXTRAS            'Enable symbolic links and execute flags'

Similarly, kernel-menus.cml simply defines the top-level menus for the kernel configuration process.

Kernel configurations are generated in two stages, first to compile the menu source file with the cmlcompile.py program, and then to run cmlconfigure.py to set kernel options. Like the Makefile rules it replaces, CML2 (shown in Figure 27.3) offers X, curses, and line-oriented interfaces selected by the default mode or with the -c and -t options:

                        cmlcompile.py kernel-rules.cml
                        cmlconfigure.py

Figure 27.3 CML2 v.0.7.1

CML2 is coded in the Python 1.5.2 to ensure portability and to allow direct compilation to a native binary. A complete guide to CML2 and the current source files can be downloaded from Eric Raymond's KBuild Web page (http://www.tuxedo.org/~esr/kbuild/).

Share This