Kernel Configuration Option Reference: Chapter 11 - Linux Kernel in a Nutshellby Greg Kroah-Hartman
This excerpt is from Linux Kernel in a Nutshell.
Linux Kernel in a Nutshell covers the entire range of kernel tasks, starting with downloading the source and making sure that the kernel is in sync with the versions of the tools you need. In addition to configuration and installation steps, the book offers reference material and discussions of related topics such as control of kernel options at runtime.
EXPERIMENTAL — Prompt for development and/or incomplete code/drivers
Some of the many things that Linux supports (such as network
drivers, file systems, network protocols, etc.) can be in a state of
development where the functionality, stability, or the level of
testing is not yet high enough for general use. This is usually known
as the "alpha-test" phase among developers. If a feature is currently
in alpha-test, the developers usually discourage uninformed widespread
use of this feature by the general public to avoid "Why doesn't this
work?" mail messages. However, active testing and use of these systems
is welcomed. Just be aware that it may not meet the normal level of
reliability or may fail to work in some special cases. Detailed bug
reports from people familiar. with the kernel internals are usually
welcomed by the developers. (But before submitting bug reports, please
read the documents
Documentation/oops-tracing.txt in the
This option also makes obsoleted drivers available. These are drivers that have been replaced by something else, and/or are scheduled to be removed in a future kernel release.
Unless you intend to help test and develop a feature or driver that falls into this category, or you have a situation that requires using these features, you should probably say no here, which will cause the configurator to present you with fewer choices. If you say yes here, you will be offered the choice of using features or drivers that are currently considered to be in the alpha-test phase.
On it's own, this option does not do anything except allow you to select other options.
LOCALVERSION — Local version -- append to kernel release
This allows you to append an extra string to the end of your
kernel version. This will show up when you enter a uname command, for example. The string you
set here will be appended after the contents of any files with a
filename beginning with
localversion in your object and source
tree, in that order. The string can be a maximum of 64 characters.
AUDIT — Auditing support
IKCONFIG — Kernel
This option enables the complete Linux kernel
.config file contents to be saved in the
kernel. It documents which kernel options are used in a running kernel
or an on-disk kernel. This information can be extracted from the
kernel image file with the script
scripts/extract-ikconfig and used as input
to rebuild the current kernel or to build another kernel. It can also
be extracted from a running kernel by reading the file
EMBEDDED — Configure standard kernel features (for small systems)
This option allows certain base kernel options and settings to be disabled or tweaked. This is for specialized environments that can tolerate a "non-standard" kernel. This is recommend only for experts, as it is very easy to change the options to create a kernel that will not even boot properly.
On it's own, this option does not do anything except allow you to select other options.
MODULES — Enable loadable module support
Kernel modules are small pieces of compiled code that can be
inserted in the running kernel, rather than being permanently built into the kernel. If you select this option, many parts
of the kernel can be built as modules (by answering
M instead of
Y where indicated): this is most useful for infrequently used options that are not
required for booting. For more information, see Chapter 4, Configuring and Building and the manpages for
If you say yes here, you will need to run
make modules_install to put the modules
/lib/modules where the
module tools can find them.
IOSCHED_NOOP — No-op I/O scheduler
IOSCHED_AS — Anticipatory I/O scheduler
IOSCHED_DEADLINE — Deadline I/O scheduler
The deadline I/O scheduler is simple and compact. It is often as good as the anticipatory I/O scheduler, and under some database workloads even better. In the case of a single process performing I/O to a disk at any one time, its behaviour is almost identical to the anticipatory I/O scheduler and so is a good choice.
IOSCHED_CFQ — CFQ I/O scheduler
SMP — Symmetric multi-processing support
This enables support for systems with more than one CPU. If you have a system with only one CPU, like most personal computers, say no. If you have a system with more than one CPU, say yes.
If you say no here, the kernel will run on single and multiprocessor machines, but will use only one CPU of a multiprocessor machine. If you say yes here, the kernel will run on many, but not all, singleprocessor machines. On a singleprocessor machine, the kernel will run faster if you say no here.
Note that if you say yes here and choose architecture
Processor family, the kernel will not work
on 486 architectures. Similarly, multiprocessor kernels for the
PPro architecture may not work on
all Pentium based boards.
Documentation/nmi_watchdog.txt, and the
SMP-HOWTO available at http://www.tldp.org/docs.html#howto.
M386 — 386
This is the processor type of your CPU. This information is used
for optimization. In order to compile a kernel that can run on all x86
CPU types (albeit not optimally fast), you can specify
The kernel will not necessarily run on earlier architectures than the one you have chosen; e.g., a Pentium optimized kernel will run on a PPro, but not necessarily on a i486.
Here are the settings recommended for greatest speed:
Choose this if you have a AMD/Cyrix/Intel 386DX/DXL/SL/SLC/SX, Cyrix/TI 486DLC/DLC2, UMC 486SX-S and NexGen Nx586 procesor. Only
386kernels will run on a 386 class machine.
Choose this if you have a AMD/Cyrix/IBM/Intel 486DX/DX2/DX4 or SL/SLC/SLC2/SLC3/SX/SX2 and UMC U5D or U5S processor.
Choose this if you have a generic Pentium processor lacking the TSC (time stamp counter) register.
Choose this if you have an Intel Pentium processor.
Choose this if you have an Intel Pentium MMX processor.
Choose this if you have an Intel Pentium Pro processor.
Choose this if you have an Intel Pentium II or pre-Coppermine Celeron processor.
Choose this if you have an the Intel Pentium III or Coppermine Celeron processor.
Choose this if you have an Intel Pentium 4 or P4-based Celeron processor.
Choose this if you have an AMD K6, K6-II or K6-III (aka K6-3D) processor.
Choose this if you have a AMD K7 family (Athlon/Duron/Thunderbird) processor.
Choose this if you have a Transmeta Crusoe series processor.
Choose this if you have a Transmeta Efficeon series processor.
Choose this if you have an original IDT Winchip processor.
Choose this if you have an IDT Winchip 2 processor.
Choose this if you have an IDT Winchip processor with 3dNow! capabilities.
Choose this if you have a Geode GX1 (Cyrix MediaGX) procssor.
Choose this if you have an AMD Geode GX or LX processor.
Choose this if you have a VIA Cyrix III or VIA C3 processor.
Choose this if you have a VIA C3-2 "Nehemiah" (model 9 and above) processor.
If you don't know what to do, choose
X86_GENERIC — Generic x86 support
Instead of just including optimizations for the selected x86 variant (e.g. PII, Crusoe or Athlon), include some more generic optimizations as well. This will make the kernel perform better on x86 CPUs other than the one selected.
This is really intended for distributors who need more generic optimizations.
NR_CPUS — Maximum number of CPUs (2-255)
SCHED_SMT — SMT (Hyper-Threading) scheduler support
PREEMPT_NONE — No forced preemption (server)
This is the traditional Linux preemption model, geared toward maximizing throughput. It still provides good latency most of the time, occasional longer delays are possible.
Select this option if you are building a kernel for a server or scientific/computation system, or if you want to maximize the raw processing power of the kernel, irrespective of scheduling latencies.
PREEMPT_VOLUNTARY — Voluntary kernel preemption (desktop)
This option reduces the latency of the kernel by adding more "explicit preemption points" to the kernel code. These new preemption points have been selected to reduce the maximum latency of rescheduling, which provides faster response to applications at the cost of slighly lower throughput.
This option speeds up reaction to interactive events by allowing a low-priority process to voluntarily preempt itself even if it is in kernel mode executing a system call. This allows applications to appear to run more smoothly even when the system is under load.
Select this if you are building a kernel for a desktop system.
PREEMPT — Preemptible kernel (low-latency desktop)
This option reduces the latency of the kernel by making all kernel code (except code executing in a critical section) preemptible. This allows reaction to interactive events by permitting a low priority process to be preempted involuntarily even if it is in kernel mode executing a system call and would otherwise not be about to reach a natural preemption point. This allows applications to appear to run more smoothly even when the system is under load, at the cost of slighly lower throughput and a slight runtime overhead to kernel code.
Select this if you are building a kernel for a desktop or embedded system with latency requirements in the milliseconds range.
PREEMPT_BKL — Preempt the Big Kernel Lock
NOHIGHMEM — off
Linux can use up to 64 Gigabytes of physical memory on x86 systems. However, the address space of 32-bit x86 processors is only 4 Gigabytes in size. That means that, if you have a large amount of physical memory, not all of it can be permanently mapped by the kernel. The physical memory that's not permanently mapped is called high memory.
If you are compiling a kernel that will never run on a machine
with more than 1 Gigabyte total physical RAM, answer
off here (the default choice, and suitable
for most users). This will result in a
3GB/1GB split: 3GB are mapped so that each
process sees a 3GB virtual memory space and the remaining part of the
4GB virtual memory space is used by the kernel to permanently map as
much physical memory as possible.
If the machine has between 1 and 4 Gigabytes physical RAM, then
If more than 4 Gigabytes is used, answer
64GB here. This selection turns Intel PAE
(Physical Address Extension) mode on. PAE implements 3-level paging on
IA32 processors. PAE is fully supported by Linux, and PAE mode is
implemented on all recent Intel processors (Pentium Pro and
If you say
64GB here, then
the kernel will not boot on CPUs that don't support PAE!
The actual amount of total physical memory will either be
autodetected or can be forced by using a kernel command line option
mem=256M. (See Chapter 9, Kernel boot command-line parameter reference
for details about how to pass options to
the kernel at boot time, and what options available.)
If unsure, say
HIGHMEM4G — 4GB
HIGHMEM64G — 64GB
FLATMEM_MANUAL — Flat memory
This option allows you to change some of the ways that Linux
manages its memory internally. Most users will see only have one
FLATMEM. This is
normal and a correct option.
Some users of more advanced features, such as NUMA and memory
hotplug, may have different options here.
DISCONTIGMEM is a more mature, better tested
system, but is incompatible with memory hotplug and may suffer
decreased performance over
SPARSEMEM. If unsure between
Sparse Memory and
Discontiguous Memory, choose
If unsure, choose this option,
DISCONTIGMEM_MANUAL — Discontiguous memory
This option provides better support than flat memory for discontiguous memory systems. These systems have holes in their physical address spaces, and this option handles the holes more efficiently. However, the vast majority of hardware has quite flat address spaces, and can experience degraded performance from the extra overhead this option imposes.
Many NUMA configurations will have this as the only option.
If unsure, choose
over this option.
SPARSEMEM_MANUAL — Sparse memory
This will be the only option for some systems, including memory hotplug systems.
For many other systems, this will be an alternative to
Discontiguous Memory. This option provides
some potential performance benefits, along with decreased code
complexity, but it is newer and more experimental.
If you are unsure, choose
SECCOMP — Enable seccomp to safely compute untrusted bytecode
This kernel feature is useful for number-crunching applications
that may need to compute untrusted bytecode during their execution. By
using pipes or other transports made available to the process as file
descriptors supporting the read/write syscalls, it's possible to
isolate those applications in their own address space using seccomp.
Once seccomp is enabled via
/proc/pid/seccomp, it cannot be disabled
and the task is allowed to execute only a few safe syscalls defined by
each seccomp mode.
If you are unsure, say yes. Only embedded systems should be built by answering no.
KEXEC — kexec system call (experimental)
kexec is a system call that implements the ability to shut down your current kernel and start up another. It is like a reboot, but is indepedent of the system firmware. And like a reboot, you can start any kernel with it, not just Linux.
The name comes from the similiarity to the exec system call.
Do not be surprised if this code does not initially work for you. It may help to enable device hotplugging support. As of this writing, the exact hardware interface is strongly in flux, so no good recommendation can be made.
HOTPLUG_CPU — Support for hot-pluggable CPUs (experimental)
PM — Power Management support
Power Management allows parts of your computer to shut off or be put into a power-conserving sleep mode if they are not being used. There are two competing standards for doing this: APM and ACPI. If you want to use either one, say yes here and then also enable one of those two standards.
Power Management is most important for battery-powered laptop computers; if you have a laptop, check out the Linux Laptop home page at http://www.linux-on-laptops.com or Tuxmobil-Linux on Mobile Computers at http://www.tuxmobil.org, and the Battery Powered Linux mini-HOWTO, available from http://www.tldp.org/docs.html#howto.
Note that, even if you say no here, Linux on the x86
architecture will issue the
instruction if nothing is being done, thereby sending the processor to
sleep and saving power.
SOFTWARE_SUSPEND — Software suspend
Enable machine suspension.
When the machine is suspended, an image is saved in your active
swap. Upon next boot, pass the
resume=/dev/swappartition argument to the
kernel to have it detect the saved image, restore memory state from
it, and continue to run as before. If you do not want the previous
state to be reloaded, use the
noresume kernel argument. However, note that
your partitions will be fsck'd and
you must issue mkswap on your swap
partitions again. The procedure does not work with swap files.
Right now you may boot without resuming and then resume later, but in the meantime you cannot use those swap partitions/files which were involved in suspending. In this case, also, there is a risk that buffers on disk won't match with saved ones.
For more information take a look at
ACPI — ACPI Support
Advanced Configuration and Power Interface (ACPI) support for Linux requires ACPI-compliant hardware and firmware, and assumes the presence of OS-directed configuration and power management (OSPM) software. This option will enlarge your kernel by about 70 KB.
Linux ACPI provides a robust functional replacement for several legacy configuration and power management interfaces, including the Plug-and-Play BIOS specification (PnP BIOS), the MultiProcessor Specification (MPS), and the Advanced Power Management (APM) specification. If both ACPI and APM support are configured, whichever is loaded first will be used.
The ACPI SourceForge project at http://sourceforge.net/projects/acpi contains the latest source code, documentation, tools, mailing list subscription, and other information.
Linux support for ACPI is based on Intel Corporation's ACPI Component Architecture (ACPI CA). For more information, see http://developer.intel.com/technology/iapc/acpi.
ACPI is an open industry specification co-developed by Compaq, Intel, Microsoft, Phoenix, and Toshiba. The specification is available at http://www.acpi.info.
CPU_FREQ — CPU frequency scaling
CPU frequency scaling allows you to change the clock speed of CPUs on the fly. This can save power, because the lower the CPU clock speed, the less power the CPU consumes.
Note that this driver doesn't automatically change the CPU clock speed; you need to either enable a dynamic CPUFreq policy governor (described later) after booting or use a userspace tool.
For details, take a look at
CPU_FREQ_DEFAULT_GOV_PERFORMANCE — performance
CPU_FREQ_DEFAULT_GOV_USERSPACE — userspace
CPU_FREQ_GOV_PERFORMANCE — "Performance" CPUFreq policy governor
CPU_FREQ_GOV_POWERSAVE — "Powersave" CPUFreq policy governor
CPU_FREQ_GOV_USERSPACE — "Userspace" CPUFreq policy governor
Enable this CPUFreq policy governor either when you want to set the CPU frequency manually or when a userspace program should be able to set the CPU dynamically, as on LART (http://www.lartmaker.nl).
For details, take a look at
CPU_FREQ_GOV_ONDEMAND — "Ondemand" CPUFreq policy governor
This driver adds a dynamic CPUFreq policy governor. The governor polls the CPU and changes its frequency based on CPU utilization. Support for this governor depends on the CPU's ability to do fast frequency switching (i.e, very low latency frequency transitions).
For details, take a look at
CPU_FREQ_GOV_CONSERVATIVE — "Conservative" CPUFreq policy governor
This driver is similar to the Ondemand governor both in its source code and its purpose. The difference is that the Conservative governor is optimiaed for a battery-powered system. The frequency is gracefully increased and decreased rather than jumping to 100% when speed is required.
If you are using a laptop, a PDA, or an AMD64-based computer (due to the unacceptable step-by-step latency issues between the minimum and maximum frequency transitions in the CPU) you will probably want to use this governor. If you have a desktop machine, consider the Ondemand governor instead.
For details, take a look at
PCI — PCI support
PCCARD — PCCard (PCMCIA/CardBus) support
PCMCIA — 16-bit PCMCIA support
This option enables support for 16-bit PCMCIA cards. Most older PC-cards are such 16-bit PCMCIA cards, so unless you know you're only using 32-bit CardBus cards, say yes here.
To use 16-bit PCMCIA cards, you will need supporting software in
most cases. See the file
Documentation/Changes for location and
CARDBUS — 32-bit CardBus support
CardBus is a bus mastering architecture for PC-cards, which allows for 32-bit PC-cards (the original PCMCIA standard specifies only a 16-bit wide bus). Many newer PC-cards are actually CardBus cards.
To use 32-bit PC-cards, you also need a CardBus compatible host bridge. Virtually all modern PCMCIA bridges do this, and most of them are "yenta-compatible," so enable that option too.
HOTPLUG_PCI — Support for PCI Hotplug (experimental)
NET — Networking support
Say yes here unless you are an expert with a really good reason not o. The reason is that some programs need kernel networking support even when running on a stand-alone machine that isn't connected to any other computer.
If you are upgrading from an older kernel, you should consider
updating your networking tools too, because changes in the kernel and
the tools often go hand in hand. The tools are contained in the
net-tools package, the location and
version number of which are given in
For a general introduction to Linux networking, it is highly recommended that you read the NET-HOWTO, available from http://www.tldp.org/docs.html#howto.
UNIX — Unix domain sockets
If you say yes here, you will include support for Unix domain sockets; sockets are the standard Unix mechanism for establishing and accessing network connections. Many commonly used programs such as the X Window System, syslog, and udev use these sockets even if your machine is not connected to any network. Unless you are working on an embedded system or something similar, you therefore definitely want to say yes here.
INET — TCP/IP networking
These are the protocols used on the Internet and on most local Ethernets. It is highly recommended that you say yes here, since some programs (e.g. the X Window System) use TCP/IP even if your machine is not connected to any other computer. They use the so-called loopback device, which this option sets up. It will enlarge your kernel by about 144 KB.
For an excellent introduction to Linux networking, please read the Linux Networking HOWTO, available from http://www.tldp.org/docs.html#howto.
IP_ADVANCED_ROUTER — IP: advanced router
If you intend to run your Linux box mostly as a router, i.e. as a computer that forwards and redistributes network packets, say yes here. You will then be presented with several options that allow more precise control about the routing process.
The answer to this question won't directly affect the kernel: answering no will just cause the configurator to skip all the questions about advanced routing.
Note that your box can act as a router only if you enable IP
forwarding in your kernel; you can do that by saying yes to the
/proc file system support and
Sysctl support options and
executing the line:
echo "1" > /proc/sys/net/ipv4/ip_forward
at boot time after the
system has been mounted.
If you turn on IP forwarding, you will also get the rp_filter, which automatically rejects incoming packets if the routing table entry for their source address doesn't match the network interface they're arriving on. This has security advantages because it prevents IP spoofing; however, it can pose problems if you use asymmetric routing (packets from you to a host take a different path from packets that go from that host to you) or if you operate a non-routing host that has several IP addresses on different interfaces. To turn rp_filter off, enter:
echo 0 > /proc/sys/net/ipv4/conf/
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
NETFILTER — Network packet filtering
Netfilter is a framework for filtering and mangling network packets that pass through your Linux box.
The most common use of packet filtering is to run your Linux box as a firewall protecting a local network from the Internet. The type of firewall provided by this kernel support is called a packet filter, which means that it can reject individual network packets based on type, source, destination etc. The other kind of firewall, a proxy-based one, is more secure but more intrusive and more bothersome to set up; it inspects the network traffic much more closely, modifies it, and has knowledge about the higher level protocols, which a packet filter lacks. Moreover, proxy-based firewalls often require changes to the programs running on the local clients. Proxy-based firewalls don't need support by the kernel, but they are often combined with a packet filter, which works only if you say yes here.
You should also say yes here if you intend to use your Linux box as the gateway to the Internet for a local network of machines without globally valid IP addresses. This is called masquerading. If one of the computers on your local network wants to send something to the outside, your box can "masquerade" as that computer, i.e., it forwards the traffic to the intended outside destination, but modifies the packets to make it look like they came from the firewall box itself. Masquerading works both ways: if the outside host replies, the Linux box will silently forward the traffic to the correct local computer. This way, the computers on your local net are completely invisible to the outside world, even though they can reach the outside and can receive replies. It is even possible to run globally visible servers from within a masqueraded local network using a mechanism called port forwarding. Masquerading is also often called NAT (Network Address Translation). Other operating systems often call this term PAT (Port Address Translation).
Another use of Netfilter is in transparent proxying: if a machine on the local network tries to connect to an outside host, your Linux box can transparently forward the traffic to a local server, typically a caching proxy server.
Yet another use of Netfilter is building a bridging firewall. Using a bridge with Network packet filtering enabled makes iptables "see" the bridged traffic. For filtering on the lower network and Ethernet protocols over the bridge, use ebtables (located under bridge Netfilter configuration).
Various modules exist for Netfilter that replace the previous
proxying, and portforwarding mechanisms. Please see
iptables for the location of these
Chances are that you should say yes here if you compile a kernel which will run as a router and no for regular hosts.
NET_SCHED — QoS and/or fair queueing
When the kernel has several packets to send out over a network device, it has to decide which ones to send first, which ones to delay, and which ones to drop. This is the job of queueing disciplines. Several different algorithms for how to do this "fairly" have been proposed.
If you say no here, you will get the standard packet scheduler, which is a FIFO (first come, first served) scheduler. If you say yes here, you will be able to choose from among several alternative algorithms that can then be attached to different network devices. This is useful, for example, if some of your network devices are real-time devices that need a certain minimum data flow rate, or if you need to limit the maximum data flow rate for traffic that matches specified criteria.
To administer these schedulers, you'll need the user-level utilities from the package iproute2+tc at http://linux-net.osdl.org/index.php/Iproute2.
This Quality of Service (QoS) support will enable you to use Differentiated Services (diffserv) and Resource Reservation Protocol (RSVP) on your Linux router if you also say yes to the corresponding options. Documentation and software is at http://diffserv.sourceforge.net.
IRDA — IrDA (infrared) subsystem support
Say yes here if you want to build support for the IrDA protocols. The Infrared Data Association specifies standards for wireless infrared communication and is supported by most laptops and PDAs.
To use Linux support for the IrDA protocols, you will also need
some user-space utilities such as irattach. For more information, see the file
Documentation/networking/irda.txt. You also
want to read the IR-HOWTO, available at http://www.tldp.org/docs.html#howto.
If you want to exchange bits of data (vCal, vCard) with a PDA, you will need to install an OBEX application, such as OpenObex from http://sourceforge.net/projects/openobex.
IRLAN — IrLAN protocol
Say yes here if you want to build support for the IrLAN protocol. IrLAN emulates an Ethernet and makes it possible to put up a wireless LAN using infrared beams.
The IrLAN protocol can be used to talk with infrared access points such as the HP NetbeamIR, or the ESI JetEye NET. You can also connect to another Linux machine running the IrLAN protocol for ad-hoc networking.
IRNET — IrNET protocol
Say yes here if you want to build support for the IrNET protocol. IrNET is a PPP driver, so you will also need a working PPP subsystem (driver, daemon, and configuration).
IrNET is an alternate way to transfer TCP/IP traffic over IrDA. It uses synchronous PPP over a set of point to point IrDA sockets. You can use it between Linux machines or with Windows.
IRCOMM — IrCOMM protocol
IRDA_ULTRA — Ultra (connectionless) protocol
Say yes here to support the connectionless Ultra IRDA protocol.
Ultra allows to exchange data over IrDA with really simple devices
(watch, beacon) without the overhead of the IrDA protocol (no
handshaking, no management frames, simple fixed header). Ultra is
available as a special socket:
socket(AF_IRDA, SOCK_DGRAM, 1);
BT — Bluetooth subsystem support
Bluetooth is low-cost, low-power, short-range wireless technology. It was designed as a replacement for cables and other short-range technologies such as IrDA. Bluetooth operates in personal area range that typically extends up to 10 meters. More information about Bluetooth can be found at http://www.bluetooth.com.
The Linux Bluetooth subsystem consist of several layers:
- Bluetooth Core
HCI device and connection manager, scheduler
- HCI Device drivers
Interface to the hardware
- SCO Module
SCO audio links
- L2CAP Module
Logical Link Control and Adaptation Protocol
- RFCOMM Module
- BNEP Module
Bluetooth Network Encapsulation Protocol
- CMTP Module
CAPI Message Transport Protocol
- HIDP Module
Human Interface Device Protocol
To use the Linux Bluetooth subsystem, you will need several user-space utilities such as hciconfig and hcid. These utilities and updates to Bluetooth kernel modules are provided in the BlueZ packages at http://www.bluez.org.
IEEE80211 — Generic IEEE 802.11 Networking Stack
MTD — Memory Technology Device (MTD) support
Memory Technology Devices are flash, RAM, and similar chips, often used for solid-state file systems on embedded devices. This option provides the generic support for MTD drivers to register themselves with the kernel and for potential users of MTD devices to enumerate the devices present and obtain a handle on them. It also allows you to select individual drivers for particular hardware and users of MTD devices.
PARPORT — Parallel port support
If you want to use devices connected to your machine's parallel port (the connector at the computer with 25 holes), e.g. a printer, ZIP drive, or Parallel Line Internet Protocol (PLIP) link, you need to say yes here.
drivers/parport/BUGS-parport for more
information. For extensive information about drivers for many devices
attaching to the parallel port, see http://www.torque.net/linux-pp.html.
It is possible to share a single parallel port among several
devices and it is safe to compile all the corresponding drivers into
the kernel. If you have more than one parallel port and want to
specify which port and IRQ will be used by this driver at module load
time, take a look at
PNP — Plug and Play support
Plug and Play (PnP) is a standard for peripherals that allows them to be configured by software, e.g. to assign IRQs or other parameters. No jumpers on the cards are needed; instead, the values are provided to the cards from the BIOS, from the operating system, or using a user-space utility.
Say yes here if you would like Linux to configure your Plug and Play devices. You should then also say yes to all of the protocols needed. Alternatively, you can say no here and configure your Plug and Play devices using user space utilities such as the isapnptools package.
ISAPNP — ISA Plug and Play support
Say yes here if you would like support for ISA Plug and Play
devices. Some information is available in
If you use have ISA Plug and Play devices, please use the ISA PnP tools found at http://www.roestock.demon.co.uk/isapnptools to configure them properly.
PNPBIOS — Plug and Play BIOS support (experimental)
Linux uses the PNPBIOS defined in "Plug and Play BIOS Specification Version 1.0A May 5, 1994" to autodetect built-in mainboard resources (e.g., parallel port resources).
If you would like the kernel to detect and allocate resources to your mainboard devices (on some systems they are disabled by the BIOS) say yes here. The PNPBIOS can also help prevent resource conflicts between mainboard devices and other bus devices.
ACPI is expected to supersede PNPBIOS some day. Currently they co-exist nicely. If you have a non-ISA system that supports ACPI, you probably don't need PNPBIOS support.
IDE — ATA/ATAPI/MFM/RLL support
If you say yes here, your kernel will be able to manage low cost mass storage units such as ATA/(E)IDE and ATAPI units. The most common such devices are IDE hard drives and ATAPI CD-ROM drives.
If your system is pure SCSI and doesn't use these interfaces, you can say no here.
Integrated Disk Electronics (IDE, also known as ATA-1) is a connecting standard for mass storage units such as hard disks. It was designed by Western Digital and Compaq Computer in 1984. It was then named ST506. Quite a number of disks use the IDE interface.
AT Attachment (ATA) is the superset of the IDE specifications. ST506 is also called ATA-1.
Fast-IDE is ATA-2 (also named Fast ATA).
Enhanced IDE (EIDE) is ATA-3. It provides support for larger disks (up to 8.4GB by means of the LBA standard), more disks (4 instead of 2) and for other mass storage units such as tapes and cdrom.
UDMA/33 (also known as UltraDMA/33) is ATA-4. By using fast DMA controllers, It provides faster transfer modes (with less load on the CPU) than previous PIO (Programmed processor Input/Output) from previous ATA/IDE standards.
ATA Packet Interface (ATAPI) is a protocol used by EIDE tape and CD-ROM drives, similar in many respects to the SCSI protocol.
SMART IDE (self-monitoring, analysis, and reporting technology) was designed in order to prevent data corruption and disk crashes by detecting pre hardware failure conditions (heat, access time, and the like). Disks built after June 1995 may follow this standard. The kernel itself doesn't manage this; however there are quite a number of user programs such as smart that can query the status of SMART parameters from disk drives.
For further information, please read
BLK_DEV_IDE — Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support
If you say yes here, you will use the full-featured IDE driver to control up to ten ATA/IDE interfaces, each one able to serve a "master" and a "slave" device, for a total of up to twenty ATA/IDE disk/cdrom/tape/floppy drives.
Useful information about large (540 MB) IDE disks, multiple
interfaces, what to do if ATA/IDE devices are not automatically
detected, sound card ATA/IDE ports, module support, and other topics,
is contained in
Documentation/ide.txt. For detailed
information about hard drives, consult the Disk-HOWTO and the
Multi-Disk-HOWTO, available from http://www.tldp.org/docs.html#howto.
To fine-tune ATA/IDE drive/interface parameters for improved
performance, look for the
package at ftp://ibiblio.org/pub/Linux/system/hardware.
Do not compile this driver as a module if your root file system
(the one containing the directory
/) is located on an IDE device.
If you have one or more IDE drives, enable this option. If your
system has no IDE drives, or if memory requirements are really tight,
you could say no here, and select the
hard disk driver option instead to save about 13 KB of
memory in the kernel.
BLK_DEV_IDEDISK — Include IDE/ATA-2 DISK support
This will include enhanced support for MFM/RLL/IDE hard disks. If you have a MFM/RLL/IDE disk, and there is no special reason to use the old hard disk driver instead, say yes. If you have an SCSI-only system, you can say no here.
Do not compile this driver as a module if your root file system
(the one containing the directory
/) is located on the IDE disk.
BLK_DEV_IDECD — Include IDE/ATAPI CDROM support
If you have a CD-ROM drive using the ATAPI protocol, say yes here. ATAPI is a newer protocol used by IDE CD-ROM and TAPE drives, similar to the SCSI protocol. Most new CD-ROM drives use ATAPI, including the NEC-260, Mitsumi FX400, Sony 55E, and just about all non-SCSI double(2X) or better speed drives.
If you say yes here, the CD-ROM drive will be identified at boot
time along with other IDE devices, as something such as
hdc (check the boot messages using the
dmesg command). If this is your
only CD-ROM drive, you can say no to all other CD-ROM options, but be
sure to also enable the
ISO 9660 CD-ROM file
system support option.
Note that older versions of LILO (LInux LOader) cannot properly deal with IDE/ATAPI CD-ROMs, so install LILO 16 or higher, available from http://lilo.go.dyndns.org.
BLK_DEV_IDEFLOPPY — Include IDE/ATAPI FLOPPY support
If you have an IDE floppy drive that uses the ATAPI protocol, answer yes. ATAPI is a newer protocol used by IDE CD-ROM/tape/floppy drives, similar to the SCSI protocol.
The LS-120 and the IDE/ATAPI Iomega ZIP drive are also supported
by this driver. For information about jumper settings and the question
of when a ZIP drive uses a partition table, see http://www.win.tue.nl/~aeb/linux/zip/zip-1.html. (ATAPI
PD-CD/CDR drives are not supported by this driver; support for
PD-CD/CDR drives is available if you answer yes to
SCSI emulation support).
If you say yes here, the FLOPPY drive will be identified along
with other IDE devices, with a name such as
hdc (check the boot messages using the
SCSI — SCSI device support
If you want to use a SCSI hard disk, SCSI tape drive, SCSI CD-ROM, or any other SCSI device under Linux, say yes and make sure that you know the name of your SCSI host adapter (the card inside your computer that "speaks" the SCSI protocol, also called SCSI controller), because you will be asked for it.
You also need to say yes here if you have a device that speaks the SCSI protocol. Examples of these include the parallel port version of the IOMEGA ZIP drive, USB storage devices, Fibre Channel, FireWire storage, and the IDE-SCSI emulation driver.
Do not compile this as a module if your root file system (the
one containing the directory
is located on a SCSI device.
BLK_DEV_SD — SCSI disk support
If you want to use SCSI hard disks, Fibre Channel disks, USB storage, or the SCSI or parallel port version of the IOMEGA ZIP drive, say yes and read the SCSI-HOWTO, the Disk-HOWTO, and the Multi-Disk-HOWTO, available from http://www.tldp.org/docs.html#howto. This is not for SCSI CD-ROMs.
Do not compile this driver as a module if your root file system
(the one containing the directory
/) is located on a SCSI disk. In this case,
do not compile the driver for your SCSI host adapter as a module
CHR_DEV_ST — SCSI tape support
If you want to use a SCSI tape drive under Linux, say yes and
read the SCSI-HOWTO, available from http://www.tldp.org/docs.html#howto, and
Documentation/scsi/st.txt in the kernel
source. This is not for SCSI CD-ROMs.
BLK_DEV_SR — SCSI CDROM support
If you want to use a SCSI or FireWire CD-ROM under Linux, say
yes and read the SCSI-HOWTO and the CDROM-HOWTO at http://www.tldp.org/docs.html#howto for more
directions. Also make sure to enable the
9660 CD-ROM file system support option.
CHR_DEV_SG — SCSI generic support
If you want to use SCSI scanners, synthesizers, or CD-writers, or just about anything having "SCSI" in its name other than hard disks, CD-ROMs, or tapes, say yes here. These won't be supported by the kernel directly, so you need some additional software that knows how to talk to these devices using the SCSI protocol:
For scanners, look at SANE http://www.sane-project.org. For CD writer software
look at Cdrtools http://cdrecord.berlios.de/old/private/cdrecord.html,
and for burning a "disk at once," check out CDRDAO http://cdrdao.sourceforge.net. Cdparanoia is a high
quality digital reader of audio CDs (http://www.xiph.org/paranoia). For other devices, it's
possible that you'll have to write the driver software yourself.
Please read the file
CHR_DEV_SCH — SCSI media changer support
This is a driver for SCSI media changers. The most common such
devices are tape libraries and MOD/CDROM jukeboxes. This option is for
real jukeboxes; you don't need it for tiny 6-slot CD-ROM changers.
Media changers are listed as "Type: Medium Changer" in
SCSI_MULTI_LUN — Probe all LUNs on each SCSI device
If you have a SCSI device, such as a CD jukebox, that supports
more than one LUN (Logical Unit Number), and only one LUN is detected,
you can say yes here to force the SCSI driver to probe for multiple
LUNs. A SCSI device with multiple LUNs acts logically like multiple
SCSI devices. The vast majority of SCSI devices have only one LUN, and
so most people can say no here. The
max_luns boot/module parameter allows you to
override this setting.
SCSI_SATA — Serial ATA (SATA) support
MD — Multiple devices driver support (RAID and LVM)
BLK_DEV_MD — RAID support
This driver lets you combine several hard disk partitions into one logical block device. This can be used to simply append one partition to another one or to combine several redundant hard disks into a RAID 1, RAID 4, or RAID 5 device to provide protection against hard disk failures. This is called software RAID because the combining of the partitions is done by the kernel. Hardware RAID means that the combining is done by a dedicated controller; if you have such a controller, you do not need to say yes here.
More information about software RAID on Linux is n the Software RAID mini-HOWTO, available from http://www.tldp.org/docs.html#howto. There you will also learn where to get the supporting userspace raidtools utilities.
BLK_DEV_DM — Device mapper support
Device-mapper is a low level volume manager. It works by allowing people to specify mappings for ranges of logical sectors. Various mapping types are available, in addition to which people may write their own modules containing custom mappings.
Higher level volume managers such as LVM2 use this driver.
IEEE1394 — IEEE 1394 (FireWire) support
IEEE 1394 describes a high performance serial bus, which is also known as FireWire or i.Link and is used for connecting all sorts of devices (most notably, digital video cameras) to your computer.
If you have FireWire hardware and want to use it, say yes here. This is the core support only. You will also need to select a driver for your IEEE 1394 adapter.
I2O — I2O support
The Intelligent Input/Output (I2O) architecture allows hardware drivers to be split into two parts: an operating-system-specific module called the OSM and an hardware-specific module called the HDM. The OSM can talk to a whole range of HDM's, and ideally the HDM's are not OS-dependent. This allows for the same HDM driver to be used under different operating systems if the relevant OSM is in place. In order for this to work, you need to have an I2O interface adapter card in your computer. This card contains a special I/O processor (IOP), allowing high speeds because the CPU does not have to deal with I/O.
If you say yes here, you will get a choice of interface adapter drivers and OSMs and will have to enable the correct ones.
NETDEVICES — Network device support
You can say no here if you do not intend to connect your Linux box to any other computer.
You'll have to say yes if your computer contains a network card that you want to use under Linux. If you are going to run SLIP or PPP over a telephone line or null modem cable you need say yes here. Connecting two machines with parallel ports using PLIP needs this, as well as AX.25/KISS for sending Internet traffic over amateur radio links.
See also the Linux Network Administrator's Guide (O'Reilly) available at http://www.tldp.org/guides.html.
NET_ETHERNET — Ethernet (10 or 100Mbit)
Ethernet (also called IEEE 802.3 or ISO 8802-2) is the most common type of Local Area Network (LAN) in universities and companies.
Common varieties of Ethernet are: 10BASE-2 or Thinnet (10 Mbps over coaxial cable, linking computers in a chain), 10BASE-T or twisted pair (10 Mbps over twisted pair cable, linking computers to central hubs), 10BASE-F (10 Mbps over optical fiber links, using hubs), 100BASE-TX (100 Mbps over two twisted pair cables, using hubs), 100BASE-T4 (100 Mbps over 4 standard voice-grade twisted pair cables, using hubs), 100BASE-FX (100 Mbps over optical fiber links), and Gigabit Ethernet (1 Gbps over optical fiber or short copper links). The 100BASE varieties are also known as Fast Ethernet.
If your Linux machine will be connected to an Ethernet and you have an Ethernet network interface card (NIC) installed in your computer, say yes here and read the Ethernet-HOWTO, available from http://www.tldp.org/docs.html#howto. You will then also have to say yes to the driver for your particular NIC.
Note that the answer to this question won't directly affect the kernel: saying no will just cause the configurator to skip all the questions about Ethernet network cards.
NET_RADIO — Wireless LAN drivers (non-hamradio) and Wireless Extensions
Support for wireless LANs and everything having to do with packet radio, but not with amateur radio or FM broadcasting.
Saying yes here also enables the Wireless Extensions, creating
/proc/net/wireless and enabling
iwconfig access). The Wireless
Extensions are a generic API that allows a driver to expose
configuration and statistics for common wireless LANs to userspace.
Wireless Extensions provide a single set of tools that can support all
the variations of wireless LANs, regardless of their type (as long as
the driver supports Wireless Extensions). Another advantage is that
these parameters may be changed on the fly without restarting the
driver or operating system. If you wish to use Wireless Extensions
with wireless PCMCIA cards (PC-cards), you need to say yes here. You
can fetch the tools from http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html.
PPP — PPP (point-to-point protocol) support
PPP (Point to Point Protocol) sends Internet traffic over telephone (and other serial) lines. Ask your access provider if they support it, because otherwise you can't use it. An older protocol with the same purpose is called SLIP. Most Internet access providers these days support PPP rather than SLIP.
To use PPP, you need an additional program called pppd as described in the PPP-HOWTO,
available at http://www.tldp.org/docs.html#howto. Make sure that you
have the version of pppd
Documentation/Changes. The PPP option
enlarges your kernel by about 16 KB.
There are actually two versions of PPP: the traditional PPP for
asynchronous lines, such as regular analog phone lines, and
synchronous PPP, which can be used over digital ISDN lines for
example. If you want to use PPP over phone lines or other asynchronous
serial lines, you need to enable the
support for async serial ports option.
PPPOE — PPP over Ethernet (experimental)
Support for PPP over Ethernet.
This driver requires the latest version of pppd from the CVS repository at cvs.samba.org. Alternatively, see the RoaringPenguin package http://www.roaringpenguin.com/pppoe, which contains instruction on hows to use this driver under the heading "Kernel mode PPPoE."
ISDN — ISDN support
ISDN ("Integrated Services Digital Networks", called RNIS in France) is a special type of fully digital telephone service; it's mostly used to connect to your Internet service provider (with SLIP or PPP). The main advantage of ISDN is that the speed is higher than ordinary modem/telephone connections, and that you can have voice conversations while downloading stuff. It works only if your computer is equipped with an ISDN card and both you and your service provider purchased an ISDN line from the phone company. For details, read http://www.alumni.caltech.edu/~dank/isdn.
Select this option if you want your kernel to support ISDN.
PHONE — Linux telephony support
INPUT — Generic input layer (needed for keyboard, mouse, ...)
Say yes here if you have any input device (mouse, keyboard, tablet, joystick, steering wheel ...) connected to your system and want it to be available to applications. This includes a standard PS/2 keyboard and mouse.
Say no here if you have a headless (no monitor, no keyboard) system.
More information is available in the file
VT — Virtual terminal
Say yes here to get support for terminal devices with display and keyboard devices. These are called "virtual" because you can run several virtual terminals (also called virtual consoles) on one physical terminal.
You need at least one virtual terminal device in order to make use of your keyboard and monitor. Therefore, only people configuring an embedded system would want to say no here in order to save some memory; the only way to log into such a system is then via a serial or network connection.
Virtual terminals are useful because, for example, one virtual terminal can display system messages and warnings, another one can be used for a text-mode user session, and a third could run an X session, all in parallel. Switching between virtual terminals is done with certain key combinations, usually Alt-function key.
If you are unsure, say yes, or else you won't be able to do much with your Linux system.
VT_CONSOLE — Support for console on virtual terminal
The system console is the device that receives all kernel
messages and warnings and allows logins in single user mode. If you
answer yes here, a virtual terminal (the device used to interact with
a physical terminal) can be used as system console. This is the most
common mode of operations, so you should say yes unless you want the
kernel messages be output only to a serial port (in which case you
should also enable the
Console on 8250/16550
and compatible serial port option).
If you say yes here, by default, the currently visible virtual
/dev/tty0) will be used
as system console. You can change that with a kernel command line
option such as
specified the third virtual terminal as the system console. (See Chapter 9, Kernel boot command-line parameter reference
for details about how to pass options to
the kernel at boot time, and what options available.)
SERIAL_8250 — 8250/16550 and compatible serial support
This selects whether you want to include the driver for the standard serial ports. The standard answer is yes. People who might say no here are those setting up dedicated Ethernet WWW/FTP servers, or users that have one of the various bus mice instead of a serial mouse and don't intend to use their machine's standard serial port for anything. In addition, the Cyclades and Stallion multi serial port drivers do not need this driver.
Do not compile this driver as a module if you are using non-standard serial ports, because the configuration information will be lost when the driver is unloaded. This limitation may be lifted in the future.
Most people will say yes here, so that they can use serial mice, modems, and similar devices connected to the standard serial ports.
AGP — /dev/agpgart (AGP Support)
AGP (Accelerated Graphics Port) is a bus system used mainly to connect graphics cards to the rest of the system.
If you have an AGP system and you say yes here, it will be possible to use the AGP features of your 3D rendering video card. This code acts as a sort of "AGP driver" for the motherboard's chipset.
If you need more texture memory than you can get with the AGP GART (theoretically up to 256 MB, but in practice usually 64 or 128 MB due to kernel allocation issues), you could use PCI accesses and have up to a couple gigs of texture space.
Note that this is the only way to have X and GLX use write-combining with MTRR support on the AGP bus. Without this option, OpenGL direct rendering will be a lot slower, but still faster than PIO.
You should say yes here if you want to use GLX or DRI.
DRM — Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)
Kernel-level support for the Direct Rendering Infrastructure
(DRI) was introduced in XFree86 4.0. If you say yes here, you need to
select the module that's right for your graphics card from the list.
These modules provide support for synchronization, security, and DMA
transfers. Please see http://dri.sourceforge.net
for details. You should also select and configure AGP (
I2C — I2C support
I2C (pronounced "I-square-C") is a slow serial bus protocol
developed by Philips and used in many micro controller applications.
SMBus, or System Management Bus, is a subset of the I2C protocol. More
information is contained in the directory
Documentation/i2c, especially in the file
Both I2C and SMBus are supported by this option. You will need it for hardware sensors support and Video For Linux support.
If you want I2C support, in addition to saying yes here, you must also select the specific drivers for your bus adapters.
SPI — SPI support
The Serial Peripheral Interface (SPI) is a low level synchronous protocol. Chips that support SPI can have data transfer rates up to several tens of Mbps. Chips are addressed with a controller and a chipselect. Most SPI slaves don't support dynamic device discovery; some are even write-only or read-only.
SPI is widely used by microcontrollers to talk with sensors, EEPROM and flash memory, codecs and various other controller chips, analog-to-digital and digital-to-analog converters, and more. MMC and SD cards can be accessed using SPI protocol; and for DataFlash cards used in MMC sockets, SPI must always be used.
SPI is one of a family of similar protocols using a four-wire interface (select, clock, data in, and data out), including Microwire (half duplex), SSP, SSI, and PSP. This driver framework should work with most such devices and controllers.
HWMON — Hardware monitoring support
Hardware monitoring devices let you monitor the hardware health of a system. Most modern motherboards include such a device. It can include temperature sensors, voltage sensors, fan speed sensors, and various additional features such as the ability to control the speed of the fans. If you want this support you should say yes here and also to the specific driver for your sensor chip.
VIDEO_DEV — Video For Linux
This option enables support for audio/video capture and overlay devices and FM radio cards. The exact capabilities of each device vary.
The kernel includes support for the new Video for Linux Two API, (V4L2) as well as the original system. Drivers and applications need to be rewritten to use V4L2, but drivers for popular cards and applications for most video capture functions already exist.
DVB — DVB For Linux
This option enables support for Digital Video Broadcasting hardware. Enable this if you own a DVB adapter and want to use it or if you are compiling Linux for a digital set-top box.
API specs and user tools are available from http://www.linuxtv.org.
FB — Support for frame buffer devices
The frame buffer device provides an abstraction for the graphics hardware. It represents the frame buffer of some video hardware and allows application software to access the graphics hardware through a well-defined interface, so the software doesn't need to know anything about the low-level (hardware register) stuff.
Frame buffer devices work identically across the different architectures supported by Linux and make the implementation of application programs easier and more portable; at this point, an X server exists which uses the frame buffer device exclusively. On several non-X86 architectures, the frame buffer device is the only way to use the graphics hardware.
You need a program called fbset to make full use of frame buffer
devices. Please read
Documentation/fb/framebuffer.txt and the
Framebuffer-HOWTO at http://www.tldp.org/HOWTO/Framebuffer-HOWTO.html for
Say yes here and to the driver for your graphics board if you are compiling a kernel for a non-x86 architecture. If you are compiling for the x86 architecture, you can say yes if you want to use the frame buffer, but it is not essential.
Please note that running graphical applications that directly touch the hardware (e.g. an accelerated X server) and that are not attuned to the frame buffer device may cause unexpected results.
VGA_CONSOLE — VGA text console
Saying yes here will allow you to use Linux in text mode through a display that complies with the generic VGA standard. Virtually everyone wants that.
The program SVGATextMode can be used to utilize SVGA video cards to their full potential in text mode. Download it from ftp://ibiblio.org/pub/Linux/utils/console.
LOGO — Bootup logo
SOUND — Sound card support
If you have a sound card in your computer, i.e. if it can say more than an isolated beep, say yes. Be sure to have all the information about your sound card and its configuration down (I/O port, interrupt and DMA channel), because you will be asked for it.
Read the Sound-HOWTO, available from http://www.tldp.org/docs.html#howto. General
information about the modular sound system is contained in the file
some slightly outdated but still useful information as well. Newer
sound driver documentation can be found in files in the
If you have a PnP sound card and you want to configure it at
boot time using the ISA PnP tools (read http://www.roestock.demon.co.uk/isapnptools), you need
to compile sound card support as a module and load that module after
the PnP configuration is finished. To do this properly, read
I'm told that even without a sound card, you can make your
computer say more than an occasional beep by programming the PC
speaker. Kernel patches and supporting utilities to do that are in the
pcsp package, available at ftp://ftp.infradead.org/pub/pcsp.
SND — Advanced Linux sound architecture
Say yes to enable ALSA (Advanced Linux Sound Architecture), the standard Linux sound system.
For more information, see http://www.alsa-project.org.
SND_USB_AUDIO — USB Audio/MIDI driver
USB — Support for Host-side USB
Universal Serial Bus (USB) is a specification for a serial bus subsystem that offers higher speeds and more features than the traditional PC serial port. The bus supplies power to peripherals and allows for hot swapping. Up to 127 USB peripherals can be connected to a single USB host in a tree structure.
The USB host is the root of the tree, the peripherals are the leaves, and the inner nodes are special USB devices called hubs. Most PCs now have USB host ports, used to connect peripherals such as scanners, keyboards, mice, modems, cameras, disks, flash memory, network links, and printers to the PC.
Say yes here if your computer has a host-side USB port and you
want to use USB devices. You then need to say yes to at least one of
the Host Controller Driver (HCD) options that follow. Choose a USB 1.1
controller, such as
EHCI HCD (USB 2.0)
support except for older systems that do not have USB 2.0
support. It does not hurt to select them all if you are not
If your system has a device-side USB port, used in the
peripheral side of the USB protocol, see the
USB Gadget option instead.
After choosing your HCD, select drivers for the USB peripherals
you'll be using. You may want to check out the information provided in
Documentation/usb and especially
the links given in
USB_EHCI_HCD — EHCI HCD (USB 2.0) support
The Enhanced Host Controller Interface (EHCI) is standard for USB 2.0 "high speed" (480 Mbit/sec, 60 Mbyte/sec) host controller hardware. If your USB host controller supports USB 2.0, you will likely want to configure this Host Controller Driver. At the time of this writing, the primary implementation of EHCI is a chip from NEC, widely available in add-on PCI cards, but implementations are in the works from other vendors, including Intel and Philips. Motherboard support is emerging.
EHCI controllers are packaged with "companion" host controllers (OHCI or UHCI) to handle USB 1.1 devices connected to root hub ports. Ports will connect to EHCI if the device is high speed, otherwise they connect to a companion controller. If you configure EHCI, you should probably configure the OHCI (for NEC and some other vendors) USB Host Controller Driver or UHCI (for Via motherboards) Host Controller Driver too.
You may want to read
Documentation/usb/ehci.txt for more
information on this driver.
USB_OHCI_HCD — OHCI HCD support
The Open Host Controller Interface (OHCI) is a standard for
accessing USB 1.1 host controller hardware. It does more in hardware
than Intel's UHCI specification. If your USB host controller follows
the OHCI spec, say yes. On most non-x86 systems, and on x86 hardware
that's not using a USB controller from Intel or VIA, this is
appropriate. If your host controller doesn't use PCI, this is probably
appropriate. For a PCI based system where you're not sure, the
lspci -v command will list the
prog-if for your USB
controller(s): EHCI, OHCI, or UHCI.
USB_UHCI_HCD — UHCI HCD (most Intel and VIA) support
The Universal Host Controller Interface is a standard created by Intel for accessing the USB hardware in the PC (which is also called the USB host controller). If your USB host controller conforms to this standard, you may want to say yes. All recent boards with Intel PCI chipsets (such as intel 430TX, 440FX, 440LX, 440BX, i810, i820) conform to this standard. All VIA PCI chipsets (like VIA VP2, VP3, MVP3, Apollo Pro, Apollo Pro II or Apollo Pro 133) also use the standard.
USB_STORAGE — USB mass storage support
Say yes here if you want to connect USB mass storage devices to your computer's USB port. This is the driver you need for USB floppy drives, USB hard disks, USB tape drives, USB CD-ROMs, USB flash devices, and memory sticks, along with similar devices. This driver may also be used for some cameras and card readers.
This option enables the
option, but you probably also need
device support: SCSI disk support for most USB storage
devices to work properly.
USB_SERIAL — USB serial converter support
USB_GADGET — Support for USB Gadgets
USB is a master/slave protocol, organized with one master host (such as a PC) controlling up to 127 peripheral devices. The USB hardware is asymmetric, which makes it easier to set up: you can't connect a "to-the-host" connector to a peripheral.
Linux can run in the host or in the peripheral. In both cases you need a low level bus controller driver, and some software that talks to it. Peripheral controllers can be either discrete silicon or integrated with the CPU in a microcontroller. The more familiar host side controllers have names like such as EHCI, OHCI, or UHCI, and are usually integrated into southbridges on PC motherboards.
Enable this configuration option if you want to run Linux inside a USB peripheral device. Configure one hardware driver for your peripheral/device side bus controller, and a "gadget driver" for your peripheral protocol. (If you use modular gadget drivers, you may configure more than one.)
If in doubt, say no and don't enable these drivers; most people don't have this kind of hardware (except maybe inside Linux PDAs).
For more information, see http://www.linux-usb.org/gadget and the kernel DocBook documentation for this API.
MMC — MMC support
INFINIBAND — InfiniBand support
EDAC — EDAC core system error reporting (experimental)
EDAC is designed to report errors in the core system. These are low-level errors that are reported by the CPU or supporting chipset: memory errors, cache errors, PCI errors, thermal throttling, etc.
EXT2_FS — Second extended filesystem support
ext2 is a standard Linux file
system for hard disks. Most systems use the upgrade,
Note that the file system of your root partition (the one
containing the directory
cannot be compiled as a module without using a special boot process,
so building it as a module could be dangerous.
EXT3_FS — Third extended file system support
This is the journaling version (called
ext3) of the second extended file system,
the de facto standard Linux file system for hard disks.
The journaling code included in this driver means you do not have to run fsck (file system checker) on your file systems after a crash. The journal keeps track of any changes that were being made at the time the system crashed, and can ensure that your file system is consistent without the need for a lengthy check.
Other than adding the journal to the file system, the on-disk
ext3 is identical to
ext2. It is possible to freely
switch between using the
driver and the
ext2 driver, as long
as the file system has been cleanly unmounted, or fsck is run on the file system before the switch.
To add a journal on an existing
ext2 file system or change the behavior of
ext3 file systems, you can use the
tune2fs utility. To modify
attributes of files and directories on
ext3 file systems, use chattr. You need
e2fsprogs version 1.20 or later in order to
ext3 journals (available at
REISERFS_FS — ReiserFS support
This is a journaled filesystem that stores not just filenames but the files themselves in a balanced tree. Balanced trees can be more efficient than traditional file system architectural foundations.
In general, ReiserFS is as fast as
ext2, but is more efficient with large
directories and small files.
JFS_FS — JFS filesystem support
XFS_FS — XFS filesystem support
XFS is a high performance journaling filesystem that originated on the SGI IRIX platform. It is completely multi-threaded, can support large files and large filesystems, extended attributes, and variable block sizes, is extent based, makes extensive use of B-trees, and uses directories, extents, and free space to aid both performance and scalability.
Refer to the documentation at http://oss.sgi.com/projects/xfs for complete details. This implementation is on-disk compatible with the IRIX version of XFS.
OCFS2_FS — OCFS2 file system support (experimental)
OCFS2 is a general-purpose, extent-based, shared-disk cluster
file system with many similarities to
ext3. It supports 64 bit inode numbers, and
has automatically extending metadata groups, which may also make it
attractive for non-clustered use.
You'll want to install the ocfs2-tools package in order to at least get the mount.ocfs2 program.
The project web page is http://oss.oracle.com/projects/ocfs2 and the tools web page is http://oss.oracle.com/projects/ocfs2-tools. OCFS2 mailing lists can be found at http://oss.oracle.com/projects/ocfs2/mailman.
INOTIFY — inotify file change notification support
Say yes here to enable inotify support and the associated system
calls. inotify is a file change notification system and a replacement
for dnotify. inotify fixes numerous shortcomings in dnotify and
introduces several new features. It allows monitoring of both files
and directories via a single open
fd object. Other features include multiple
file events, one-shot support, and unmount notification.
For more information, see
QUOTA — Quota support
If you say yes here, you will be able to set per-user limits for
disk usage (also called disk quotas). Currently, it works for the
ext3, and ReiserFS file system.
ext3 also supports journalled quotas, for
which you don't need to run quotacheck after an unclean shutdown. For
further details, read the Quota mini-HOWTO, available from http://www.tldp.org/docs.html#howto, or the
documentation provided with the quota tools. Quota support is probably
useful only for multi-user systems.
AUTOFS_FS — Kernel automounter support
The automounter is a tool that automatically mounts remote file systems on
demand. This implementation is partially kernel-based to reduce
overhead when a system is already mounted; this is unlike the BSD
amd), which is a pure
user space daemon.
To use the automounter, you need the user-space tools from the
autofs package; you can find the
Documentation/Changes. You also want to
answer yes to the
NFS file system
If you want to use the newer version of the automounter with
more features, say no here and say yes to the
Kernel automounter v4 support option.
If you are not a part of a fairly large, distributed network, you probably do not need an automounter, and can say no here.
FUSE_FS — Filesystem in Userspace support
With FUSE it is possible to implement a fully functional filesystem in a userspace program.
There's also companion library named libfuse. This library, along with utilities, is available from the FUSE homepage: http://fuse.sourceforge.net.
Documentation/filesystems/fuse.txt for more
Documentation/Changes for library/utility
version you need.
If you want to develop a userspace filesystem, or if you want to use a filesystem based on FUSE, answer yes here.
SMB_FS — SMB file system support (to mount Windows shares etc.)
SMB (Server Message Block) is the protocol Windows for
Workgroups (WfW), Windows 95/98, Windows NT and later variants, and
OS/2 Lan Manager use to share files and printers over local networks.
Saying yes here allows you to mount their file systems (often called
"shares" in this context) and access them just like any other Unix
directory. Currently, this works only if the Windows machines use
TCP/IP as the underlying transport protocol, not NetBEUI. For details,
Documentation/filesystems/smbfs.txt and the
SMB-HOWTO, available from http://www.tldp.org/docs.html#howto.
If you just want your box to act as an SMB server and make files and printing services available to Windows clients (which need to have a TCP/IP stack), you don't need to say yes here; you can use the Samba set of daemons and programs (available from ftp://ftp.samba.org/pub/samba).
CIFS — CIFS support (advanced network filesystem for Samba, Window and other CIFS compliant servers)
This is the client VFS module for the Common Internet File
System (CIFS) protocol, which is the successor to the Server Message
Block (SMB) protocol, the native file sharing mechanism for most early
PC operating systems. The CIFS protocol is fully supported by file
servers such as Windows 2000 (including Windows 2003, NT 4 and Windows
XP) as well by Samba (which provides excellent CIFS server support for
Linux and many other operating systems). Limited support for Windows
ME and similar servers is provided as well. You must use the
smbfs client filesystem to access older SMB
servers such as OS/2 and DOS.
The intent of the
is to provide an advanced network file system client for mounting
local filesystems to CIFS compliant servers, including support for DFS
(hierarchical name space), secure per-user session establishment, safe
distributed caching (oplock), optional packet signing, Unicode and
other internationalization improvements, and optional Winbind
(nsswitch) integration. You do not need to enable
cifs if you are
running only a server (Samba). It is possible to enable both
cifs (e.g. if you are using CIFS for
accessing Windows 2003 and Samba 3 servers, and
smbfs for accessing old servers). If you
need to mount to Samba or Windows from this machine, say yes to this
PROFILING — Profiling support (experimental)
OPROFILE — OProfile system profiling (experimental)
OProfile is a profiling system capable of profiling the whole system, include the kernel, kernel modules, libraries, and applications.
For more information, and links to the userspace tools needed to use OProfile properly, see the main project page at http://oprofile.sourceforge.net/news.
KPROBES — Kprobes (experimental)
PRINTK_TIME — Show timing information on printks
MAGIC_SYSRQ — Magic SysRq key
If you say yes here, you will have some control over the system
even if the system crashes for example during kernel debugging (e.g.,
you will be able to flush the buffer cache to disk, reboot the system
immediately, or dump some status information). This is accomplished by
pressing various keys while holding down the SysRq (Alt+PrintScreen)
key. It also works on a serial console (on PC hardware at least), if
you send a BREAK and then within 5 seconds a command keypress. The
keys are documented in
Documentation/sysrq.txt. Don't say yes
unless you really know what this hack does.
DEBUG_KERNEL — Kernel debugging
DEBUG_FS — Debug filesystem
SECURITY — Enable different security models
SECURITY_SELINUX — NSA SELinux Support
This selects NSA Security-Enhanced Linux (SELinux). You will also need a policy configuration and a labeled filesystem. You can obtain the policy compiler (checkpolicy), the utility for labeling filesystems (setfiles), and an example policy configuration from http://www.nsa.gov/selinux.
 This chapter lists the most important configuration options offered when you run make config or one of its graphical interfaces. The majority of the chapter is based on the in-kernel documentation for the different kernel configuration options, which were written by the kernel developers and released under the GPL.
If you enjoyed this excerpt, buy a copy of Linux Kernel in a Nutshell