ch11.xml

<!-- fix up the "- -" entries due to commenting out stuff -->

<chapter id="LKN-config">

<title>
Kernel Configuration Option Reference
<footnote>
<para>
This chapter lists the most important configuration options offered
when you run <command>make config</command> 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.
</para>
</footnote>
</title>


<refentry id="CONFIG_EXPERIMENTAL">
<refnamediv>
	<refname>EXPERIMENTAL</refname>
	<refpurpose>Prompt for development and/or incomplete code/drivers</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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
	<filename>README</filename>,
	<filename>MAINTAINERS</filename>,
	<filename>REPORTING-BUGS</filename>,
	<filename>Documentation/BUG-HUNTING</filename>, and
	<filename>Documentation/oops-tracing.txt</filename> in the kernel source).
	</para>

	<para>
	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.
	</para>

	<para>
	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.
	</para>

	<para>
	On it's own, this option does not do anything except allow you
	to select other options.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_LOCALVERSION">
<refnamediv>
	<refname>LOCALVERSION</refname>
	<refpurpose>Local version -- append to kernel release</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	This allows you to append an extra string to the end of your kernel
	version.  This will show up when you enter a
	<command>uname</command> command, for example.  The
	string you set here will be appended after the contents of any files
	with a filename beginning with <filename>localversion</filename> in your object and source tree,
<!--

  AO: Why is order important? I thought you said "any files," the
  order doesn't seem relevant.

  gkh: object directory is used first, followed by the source directory.
  Remember, they can be different directories now in the 2.6 build
  system :)
-->
	in that order.  The string can be a maximum of 64 characters.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_AUDIT">
<refnamediv>
	<refname>AUDIT</refname>
	<refpurpose>Auditing support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	Enable an auditing infrastructure that can be used with another
	kernel subsystem, such as SELinux (which requires this for
	logging of avc messages output).
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_IKCONFIG">
<refnamediv>
	<refname>IKCONFIG</refname>
	<refpurpose>Kernel <filename>.config</filename> support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	This option enables the complete Linux kernel <filename>.config</filename> 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
	<filename>scripts/extract-ikconfig</filename> 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
	<filename>/proc/config.gz</filename>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_EMBEDDED">
<refnamediv>
	<refname>EMBEDDED</refname>
	<refpurpose>Configure standard kernel features (for small systems)</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	On it's own, this option does not do anything except allow you
	to select other options.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_MODULES">
<refnamediv>
	<refname>MODULES</refname>
	<refpurpose>Enable loadable module support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	Kernel modules are small pieces of compiled code that can
	be inserted in the running kernel, rather than being
<!--

  AO: Because the material here is basic and is repeated elsewhere, I
  took out a sentence.

  gkh: that's fine.
-->
	permanently built into the kernel.    If you select this option,
	many parts of the kernel can be built as modules (by
	answering <literal>M</literal> instead of <literal>Y</literal> where
<!--

  AO: It's most useful for drivers!

  gkh: not really only for drivers.  I tend to build in the drivers for
  my systems into the kernel, and only use modules for other things
  (networking odd options for one), and use a module for stuff I am
  currently developing.  So most users will just use them for things
  they use infrequently.

-->
	indicated): this is most useful for infrequently used options that are
	not required for booting.  For more information, see <xref
	linkend="LKN-chapter-building" /> and the manpages for
	<literal>modprobe</literal>,
	<literal>lsmod</literal>,
	<literal>modinfo</literal>,
	<literal>insmod</literal>, and
	<literal>rmmod</literal>.
	</para>

	<para>
	If you say yes here, you will need to run
	<literal>make modules_install</literal> to put the modules under
	<filename>/lib/modules</filename> where the module tools can find
	them.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_IOSCHED_NOOP">
<refnamediv>
	<refname>IOSCHED_NOOP</refname>
	<refpurpose>No-op I/O scheduler</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	The no-op I/O scheduler is a minimal scheduler that does basic merging
	and sorting. Its main uses include non-disk based block devices such as
	memory devices and specialised software or hardware environments
	that do their own scheduling and require only minimal assistance from
	the kernel.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_IOSCHED_AS">
<refnamediv>
	<refname>IOSCHED_AS</refname>
	<refpurpose>Anticipatory I/O scheduler</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	The anticipatory I/O scheduler is the default disk scheduler. It is
	generally a good choice for most environments, but is quite large and
	complex compared to the deadline I/O scheduler. It can also be
	slower in some cases, especially under some database loads.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_IOSCHED_DEADLINE">
<refnamediv>
	<refname>IOSCHED_DEADLINE</refname>
	<refpurpose>Deadline I/O scheduler</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_IOSCHED_CFQ">
<refnamediv>
	<refname>IOSCHED_CFQ</refname>
	<refpurpose>CFQ I/O scheduler</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	The CFQ I/O scheduler tries to distribute bandwidth equally
	among all processes in the system. It should provide a fair
	working environment, suitable for desktop systems.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_SMP">
<refnamediv>
	<refname>SMP</refname>
	<refpurpose>Symmetric multi-processing support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	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.
	</para>

	<para>
	Note that if you say yes here and choose architecture <literal>586</literal> or
	<literal>Pentium</literal> under <literal>Processor family</literal>, the kernel will not work on 486
	architectures. Similarly, multiprocessor kernels for the <literal>PPro</literal>
	architecture may not work on all Pentium based boards.
	</para>

	<para>
	See also
	<filename>Documentation/smp.txt</filename>,
	<filename>Documentation/i386/IO-APIC.txt</filename>,
	<filename>Documentation/nmi_watchdog.txt</filename>, and the
	<filename>SMP-HOWTO</filename> available at
	<systemitem role="url">http://www.tldp.org/docs.html#howto</systemitem>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_M386">
<refnamediv>
	<refname>M386</refname>
	<refpurpose>386</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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
	<literal>386</literal> here.
	</para>

	<para>
	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.
	</para>

	<para>
	Here are the settings recommended for greatest speed:
	<variablelist>

	<varlistentry>
	<term><literal>386</literal></term>
	<listitem>
	<para>
	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 <literal>386</literal> kernels will run
	on a 386 class machine.
	</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><literal>486</literal></term>
	<listitem>
	<para>
	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.
	</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><literal>586</literal></term>
	<listitem>
	<para>
	Choose this if you have a generic Pentium processor lacking the TSC
	(time stamp counter) register.
	</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><literal>Pentium-Classic</literal></term>
	<listitem>
	<para>
	Choose this if you have an Intel Pentium processor.
	</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><literal>Pentium-MMX</literal></term>
	<listitem>
	<para>
	Choose this if you have an Intel Pentium MMX processor.
	</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><literal>Pentium-Pro</literal></term>
	<listitem>
	<para>
	Choose this if you have an Intel Pentium Pro processor.
	</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><literal>Pentium-II</literal></term>
	<listitem>
	<para>
	Choose this if you have an Intel Pentium II or pre-Coppermine Celeron processor.
	</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><literal>Pentium-III</literal></term>
	<listitem>
	<para>
	Choose this if you have an the Intel Pentium III or Coppermine Celeron processor.
	</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><literal>Pentium-4</literal></term>
	<listitem>
	<para>
	Choose this if you have an Intel Pentium 4 or P4-based Celeron processor.
	</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><literal>K6</literal></term>
	<listitem>
	<para>
	Choose this if you have an AMD K6, K6-II or K6-III (aka K6-3D) processor.
	</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><literal>Athlon</literal></term>
	<listitem>
	<para>
	Choose this if you have a AMD K7 family (Athlon/Duron/Thunderbird) processor.
	</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><literal>Crusoe</literal></term>
	<listitem>
	<para>
	Choose this if you have a Transmeta Crusoe series processor.
	</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><literal>Efficeon</literal></term>
	<listitem>
	<para>
	Choose this if you have a Transmeta Efficeon series processor.
	</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><literal>Winchip-C6</literal></term>
	<listitem>
	<para>
	Choose this if you have an original IDT Winchip processor.
	</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><literal>Winchip-2</literal></term>
	<listitem>
	<para>
	Choose this if you have an IDT Winchip 2 processor.
	</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><literal>Winchip-2</literal></term>
	<listitem>
	<para>
	Choose this if you have an IDT Winchip processor with 3dNow! capabilities.
	</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><literal>GeodeGX1</literal></term>
	<listitem>
	<para>
	Choose this if you have a Geode GX1 (Cyrix MediaGX) procssor.
	</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><literal>Geode GX/LX</literal></term>
	<listitem>
	<para>
	Choose this if you have an AMD Geode GX or LX processor.
	</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><literal>CyrixIII/VIA C3</literal></term>
	<listitem>
	<para>
	Choose this if you have a VIA Cyrix III or VIA C3 processor.
	</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><literal>VIA C3-2</literal></term>
	<listitem>
	<para>
	Choose this if you have a VIA C3-2 "Nehemiah" (model 9 and above) processor.
	</para>
	</listitem>
	</varlistentry>

	</variablelist>
	</para>

	<para>
	If you don't know what to do, choose <literal>386</literal>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_X86_GENERIC">
<refnamediv>
	<refname>X86_GENERIC</refname>
	<refpurpose>Generic x86 support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	This is really intended for distributors who need more
	generic optimizations.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_NR_CPUS">
<refnamediv>
	<refname>NR_CPUS</refname>
	<refpurpose>Maximum number of CPUs (2-255)</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	This allows you to specify the maximum number of CPUs that this
	kernel will support.  The maximum supported value is 255 and the
	minimum value that makes sense is 2.
	</para>

	<para>
	This option is purely to save memory; each supported CPU adds
	approximately eight kilobytes to the kernel image.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_SCHED_SMT">
<refnamediv>
	<refname>SCHED_SMT</refname>
	<refpurpose>SMT (Hyper-Threading) scheduler support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	SMT scheduler support improves the CPU scheduler's decision-making
	on Intel Pentium 4 chips with Hyper-Threading, at a
	cost of slightly increased overhead in some places.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_PREEMPT_NONE">
<refnamediv>
	<refname>PREEMPT_NONE</refname>
	<refpurpose>No forced preemption (server)</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	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.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_PREEMPT_VOLUNTARY">
<refnamediv>
	<refname>PREEMPT_VOLUNTARY</refname>
	<refpurpose>Voluntary kernel preemption (desktop)</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	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.
	</para>

	<para>
	Select this if you are building a kernel for a desktop system.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_PREEMPT">
<refnamediv>
	<refname>PREEMPT</refname>
	<refpurpose>Preemptible kernel (low-latency desktop)</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	Select this if you are building a kernel for a desktop or
	embedded system with latency requirements in the milliseconds
	range.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_PREEMPT_BKL">
<refnamediv>
	<refname>PREEMPT_BKL</refname>
	<refpurpose>Preempt the Big Kernel Lock</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	This option reduces the latency of the kernel by making the
	Big Kernel Lock preemptible.
	</para>

	<para>
	Say yes here if you are building a kernel for a desktop system.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_NOHIGHMEM">
<refnamediv>
	<refname>NOHIGHMEM</refname>
	<refpurpose>off</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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
	<firstterm>high memory</firstterm>.
	</para>

	<para>
	If you are compiling a kernel that will never run on a machine with
	more than 1 Gigabyte total physical RAM, answer <literal>off</literal>
	here (the default choice, and suitable for most users). This will result in
	a <literal>3GB/1GB</literal> 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.
	</para>

	<para>
	If the machine has between 1 and 4 Gigabytes physical RAM, then
	answer <literal>4GB</literal> here.
	</para>

	<para>
	If more than 4 Gigabytes is used, answer <literal>64GB</literal>
	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 better).
	</para>
	<note>
	<para>
If you say
	<literal>64GB</literal> here, then the kernel will not boot on CPUs
	that don't support PAE!
	</para>
	</note>
	<para>
	The actual amount of total physical memory will either be
	autodetected or can be forced by using a kernel command line option
	such as <literal>mem=256M</literal>. (See <xref
	linkend="LKN-command-line" /> for details about how to pass
	options to the kernel at boot time, and what options available.)
<!--

  AO: Actually, I think the parenthesized phrase should be replaced
  with a reference to a section in this book. Don't you have something
  on this subject?

  gkh: I have a whole chapter, cross reference is now added.

-->
	</para>

	<para>
	If unsure, say <literal>off</literal>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_HIGHMEM4G">
<refnamediv>
	<refname>HIGHMEM4G</refname>
	<refpurpose>4GB</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	Select this if you have a 32-bit processor and between 1 and 4
	gigabytes of physical RAM.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_HIGHMEM64G">
<refnamediv>
	<refname>HIGHMEM64G</refname>
	<refpurpose>64GB</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	Select this if you have a 32-bit processor and more than 4
	gigabytes of physical RAM.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_FLATMEM_MANUAL">
<refnamediv>
	<refname>FLATMEM_MANUAL</refname>
	<refpurpose>Flat memory</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	This option allows you to change some of the ways that
	Linux manages its memory internally.  Most users will see
	only have one option here: <literal>FLATMEM</literal>.  This is normal
	and a correct option.
	</para>

	<para>
	Some users of more advanced features, such as NUMA and
	memory hotplug, may have different options here.
	<literal>DISCONTIGMEM</literal> is a more mature, better tested
	system, but is incompatible with memory hotplug and may suffer
	decreased performance over <literal>SPARSEMEM</literal>.  If unsure
	between <literal>Sparse Memory</literal> and <literal>Discontiguous
	Memory</literal>, choose <literal>Discontiguous Memory</literal>.
	</para>

	<para>
	If unsure, choose this option, <literal>Flat Memory</literal>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_DISCONTIGMEM_MANUAL">
<refnamediv>
	<refname>DISCONTIGMEM_MANUAL</refname>
	<refpurpose>Discontiguous memory</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	Many NUMA configurations will have this as the only option.
	</para>

	<para>
	If unsure, choose <literal>Flat Memory</literal> over this option.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_SPARSEMEM_MANUAL">
<refnamediv>
	<refname>SPARSEMEM_MANUAL</refname>
	<refpurpose>Sparse memory</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	This will be the only option for some systems, including
	memory hotplug systems.
	</para>

	<para>
	For many other systems, this will be an alternative to
	<literal>Discontiguous Memory</literal>.  This option provides some potential
	performance benefits, along with decreased code complexity,
	but it is newer and more experimental.
	</para>

	<para>
	If you are unsure, choose <literal>Discontiguous Memory</literal> or
	<literal>Flat Memory</literal>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_SECCOMP">
<refnamediv>
	<refname>SECCOMP</refname>
	<refpurpose>Enable seccomp to safely compute untrusted bytecode</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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 <filename>/proc/pid/seccomp</filename>, it cannot be disabled
	and the task is allowed to execute only a few safe syscalls
	defined by each seccomp mode.
	</para>

	<para>
	If you are unsure, say yes. Only embedded systems should be
	built by answering no.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_KEXEC">
<refnamediv>
	<refname>KEXEC</refname>
	<refpurpose>kexec system call (experimental)</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	The name comes from the similiarity to the exec system call.
	</para>

	<para>
	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.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_HOTPLUG_CPU">
<refnamediv>
	<refname>HOTPLUG_CPU</refname>
	<refpurpose>Support for hot-pluggable CPUs (experimental)</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	Say yes here to experiment with turning CPUs off and on, and to
	enable suspend on SMP systems. CPUs can be controlled through the
	<filename>/sys/devices/system/cpu</filename> interface.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_PM">
<refnamediv>
	<refname>PM</refname>
	<refpurpose>Power Management support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	Power Management is most important for battery-powered laptop
	computers; if you have a laptop, check out the Linux Laptop home
	page at
	<systemitem role="url">http://www.linux-on-laptops.com</systemitem> or
	Tuxmobil-Linux on Mobile Computers at
	<systemitem role="url">http://www.tuxmobil.org</systemitem>,
	and the Battery Powered Linux mini-HOWTO, available from
	<systemitem role="url">http://www.tldp.org/docs.html#howto</systemitem>.
	</para>

	<para>
	Note that, even if you say no here, Linux on the x86 architecture
	will issue the <literal>hlt</literal> instruction if nothing is being
	done, thereby sending the processor to sleep and saving power.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_SOFTWARE_SUSPEND">
<refnamediv>
	<refname>SOFTWARE_SUSPEND</refname>
	<refpurpose>Software suspend</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	Enable machine suspension.
	</para>
<!--

  AO: There is really no explanation of the option here. Instead,
  there is just a rather mysterious procedure that must be executed at
  reboot. But why reboot?

  gkh: that is when resume happens (resume is the hard part, suspending
  is easy...)
-->

	<para>
	When the machine is suspended, an image is saved in your active swap.
	Upon next boot, pass the <literal>resume=/dev/swappartition</literal>
	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
	<literal>noresume</literal> kernel argument. However, note that your
	partitions will be <command>fsck</command>'d and you must
	issue <command>mkswap</command> on your swap partitions again.
	The procedure does not work with swap files.
	</para>

	<para>
	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.
	</para>

	<para>
	For more information take a look at
	<filename>Documentation/power/swsusp.txt</filename>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_ACPI">
<refnamediv>
	<refname>ACPI</refname>
	<refpurpose>ACPI Support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	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.
	</para>

	<para>
	The ACPI SourceForge project at
	<systemitem role="url">http://sourceforge.net/projects/acpi</systemitem> contains the latest source code,
	documentation, tools, mailing list subscription, and other information.
	</para>

	<para>
	Linux support for ACPI is based on Intel Corporation's ACPI Component
	Architecture (ACPI CA).  For more information, see
	<systemitem role="url">http://developer.intel.com/technology/iapc/acpi</systemitem>.
	</para>

	<para>
	ACPI is an open industry specification co-developed by Compaq, Intel,
	Microsoft, Phoenix, and Toshiba.  The specification is available at
	<systemitem role="url">http://www.acpi.info</systemitem>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_CPU_FREQ">
<refnamediv>
	<refname>CPU_FREQ</refname>
	<refpurpose>CPU frequency scaling</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	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.
	</para>

	<para>
	For details, take a look at
	<filename>Documentation/cpu-freq</filename>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE">
<refnamediv>
	<refname>CPU_FREQ_DEFAULT_GOV_PERFORMANCE</refname>
	<refpurpose>performance</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	Use the CPUFreq <literal>performance</literal> governor.
	This sets the frequency statically to the highest frequency supported
	by the CPU.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE">
<refnamediv>
	<refname>CPU_FREQ_DEFAULT_GOV_USERSPACE</refname>
	<refpurpose>userspace</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	Use the CPUFreq <literal>userspace</literal> governor. This
	allows you to set the CPU frequency manually, and allows a userspace
	program to set the CPU dynamically without requiring you to first
	enable the userspace governor manually.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_CPU_FREQ_GOV_PERFORMANCE">
<refnamediv>
	<refname>CPU_FREQ_GOV_PERFORMANCE</refname>
	<refpurpose>"Performance" CPUFreq policy governor</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	This CPUFreq policy governor sets the frequency statically to the
	highest available CPU frequency.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_CPU_FREQ_GOV_POWERSAVE">
<refnamediv>
	<refname>CPU_FREQ_GOV_POWERSAVE</refname>
	<refpurpose>"Powersave" CPUFreq policy governor</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	This sets the frequency statically to the lowest
	available CPU frequency.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_CPU_FREQ_GOV_USERSPACE">
<refnamediv>
	<refname>CPU_FREQ_GOV_USERSPACE</refname>
	<refpurpose>"Userspace" CPUFreq policy governor</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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
	(<systemitem role="url">http://www.lartmaker.nl</systemitem>).
	</para>

	<para>
	For details, take a look at
	<filename>Documentation/cpu-freq</filename>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_CPU_FREQ_GOV_ONDEMAND">
<refnamediv>
	<refname>CPU_FREQ_GOV_ONDEMAND</refname>
	<refpurpose>"Ondemand" CPUFreq policy governor</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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).
	</para>

	<para>
	For details, take a look at <filename>Documentation/cpu-freq</filename>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_CPU_FREQ_GOV_CONSERVATIVE">
<refnamediv>
	<refname>CPU_FREQ_GOV_CONSERVATIVE</refname>
	<refpurpose>"Conservative" CPUFreq policy governor</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	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. 
	</para>

	<para>
	For details, take a look at <filename>Documentation/cpu-freq</filename>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_PCI">
<refnamediv>
	<refname>PCI</refname>
	<refpurpose>PCI support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	PCI is a bus system used by the processor to talk to internal devices
	and add-on cards.  It is extremely common and found in almost all
	modern computers.
	</para>

	<para>
	Say yes to this option unless you have a special reason not to.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_PCCARD">
<refnamediv>
	<refname>PCCARD</refname>
	<refpurpose>PCCard (PCMCIA/CardBus) support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	Say yes here if you want to attach PCMCIA- or PC-cards to your Linux
	computer.  These are credit-card size devices such as network cards,
	modems, or hard drives often used with laptops computers.  There are
	actually two varieties of these cards: 16-bit PCMCIA and 32-bit CardBus
	cards.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_PCMCIA">
<refnamediv>
	<refname>PCMCIA</refname>
	<refpurpose>16-bit PCMCIA support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	To use 16-bit PCMCIA cards, you will need supporting software in most
	cases. See the file
	<filename>Documentation/Changes</filename> for
	location and details.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_CARDBUS">
<refnamediv>
	<refname>CARDBUS</refname>
	<refpurpose>32-bit CardBus support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	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.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_HOTPLUG_PCI">
<refnamediv>
	<refname>HOTPLUG_PCI</refname>
	<refpurpose>Support for PCI Hotplug (experimental)</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	Say yes here if you have a motherboard with a PCI Hotplug controller.
	This allows you to add and remove PCI cards while the machine is
	powered up and running.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_NET">
<refnamediv>
	<refname>NET</refname>
	<refpurpose>Networking support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	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
	<literal>net-tools</literal> package, the location and version number of which are given in
	<filename>Documentation/Changes</filename>.
	</para>

	<para>
	For a general introduction to Linux networking, it is highly
	recommended that you read the NET-HOWTO, available from
	<systemitem role="url">http://www.tldp.org/docs.html#howto</systemitem>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_UNIX">
<refnamediv>
	<refname>UNIX</refname>
	<refpurpose>Unix domain sockets</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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
<!--

  AO: Unix domain sockets are not inet sockets, so being connected to
  another machine isn't even related to using Unix domain sockets.

  gkh: ah, true.  But for some reason, people disable this option
  without really realizing that it is needed (udev for one uses it.)
  Added udev reference.

-->
	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.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_INET">
<refnamediv>
	<refname>INET</refname>
	<refpurpose>TCP/IP networking</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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 <emphasis>loopback
	device</emphasis>, which this option sets up. It will enlarge
	your kernel by about 144 KB.
	</para>

	<para>
	For an excellent introduction to Linux networking, please read the
	Linux Networking HOWTO, available from
	<systemitem role="url">http://www.tldp.org/docs.html#howto</systemitem>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_IP_ADVANCED_ROUTER">
<refnamediv>
	<refname>IP_ADVANCED_ROUTER</refname>
	<refpurpose>IP: advanced router</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	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.
	</para>

	<para>
	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
	<literal>/proc file system support</literal> and
	<literal>Sysctl support</literal> options and executing the
	line:
	<screen>
	echo "1" &gt; /proc/sys/net/ipv4/ip_forward
	</screen>
	at boot time after the <filename>/proc</filename> file system has been
	mounted.
	</para>

	<para>
	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:
	<screen>
	echo 0 &gt; /proc/sys/net/ipv4/conf/<replaceable>device</replaceable>/rp_filter
	</screen>
	or
	<screen>
	echo 0 &gt; /proc/sys/net/ipv4/conf/all/rp_filter
	</screen>
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_NETFILTER">
<refnamediv>
	<refname>NETFILTER</refname>
	<refpurpose>Network packet filtering</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	Netfilter is a framework for filtering and mangling network packets
	that pass through your Linux box.
	</para>

	<para>
	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 <firstterm>packet
	filter</firstterm>, which means that it can reject individual network packets
	based on type, source, destination etc. The other kind of firewall,
	a <firstterm>proxy-based</firstterm> 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.
	</para>

	<para>
<!--

  AO: The following explanation is probably well known and
  unnecessary, but I'll leave it up to you to decide whether to cut it
  down.

  gkh: I say leave it for now.

-->
	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 <firstterm>masquerading</firstterm>. 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).
	</para>

	<para>
	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.
	</para>

	<para>
	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).
	</para>

	<para>
	Various modules exist for Netfilter that replace the previous
	masquerading (<literal>ipmasqadm</literal>), packet filtering
	(<literal>ipchains</literal>), transparent proxying, and portforwarding
	mechanisms. Please see <filename>Documentation/Changes</filename> under
	<literal>iptables</literal> for the location of these packages.
	</para>

	<para>
	Chances are that you should say yes here if you compile a kernel which
	will run as a router and no for regular hosts.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_NET_SCHED">
<refnamediv>
	<refname>NET_SCHED</refname>
	<refpurpose>QoS and/or fair queueing</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	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.
	</para>

	<para>
	To administer these schedulers, you'll need the user-level utilities
	from the package iproute2+tc at
	<systemitem role="url">http://linux-net.osdl.org/index.php/Iproute2</systemitem>.
	</para>

	<para>
	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
	<systemitem role="url">http://diffserv.sourceforge.net</systemitem>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_IRDA">
<refnamediv>
	<refname>IRDA</refname>
	<refpurpose>IrDA (infrared) subsystem support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	To use Linux support for the IrDA protocols, you will also need
	some user-space utilities such as <command>irattach</command>.  For more information, see
	the file <filename>Documentation/networking/irda.txt</filename>.
	You also want to read the IR-HOWTO, available at
	<systemitem role="url">http://www.tldp.org/docs.html#howto</systemitem>.
	</para>

	<para>
	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
	<systemitem role="url">http://sourceforge.net/projects/openobex</systemitem>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_IRLAN">
<refnamediv>
	<refname>IRLAN</refname>
	<refpurpose>IrLAN protocol</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	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.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_IRNET">
<refnamediv>
	<refname>IRNET</refname>
	<refpurpose>IrNET protocol</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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).
	</para>

	<para>
	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.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_IRCOMM">
<refnamediv>
	<refname>IRCOMM</refname>
	<refpurpose>IrCOMM protocol</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	Say yes here if you want to build support for the IrCOMM protocol.
	IrCOMM implements serial port emulation, and makes it possible to use
	all existing applications that understand ttys with infrared links.
	Thus, you should be able to use applications such as PPP and <command>minicom</command>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_IRDA_ULTRA">
<refnamediv>
	<refname>IRDA_ULTRA</refname>
	<refpurpose>Ultra (connectionless) protocol</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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: <literal>socket(AF_IRDA, SOCK_DGRAM, 1);</literal>
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_BT">
<refnamediv>
	<refname>BT</refname>
	<refpurpose>Bluetooth subsystem support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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
	<systemitem role="url">http://www.bluetooth.com</systemitem>.
	</para>

	<para>
	The Linux Bluetooth subsystem consist of several layers:
	</para>
	<variablelist>
	   <varlistentry>
           <term>
	   Bluetooth Core
	   </term>
           <listitem><para>
	   HCI device and connection manager, scheduler
           </para></listitem>
	   </varlistentry>
	   <varlistentry>
           <term>
	   HCI Device drivers
	   </term>
           <listitem><para>
	   Interface to the hardware
           </para></listitem>
	   </varlistentry>
	   <varlistentry>
           <term>
	   SCO Module
	   </term>
           <listitem><para>
	   SCO audio links
           </para></listitem>
	   </varlistentry>
	   <varlistentry>
           <term>
	   L2CAP Module
	   </term>
           <listitem><para>
	   Logical Link Control and Adaptation Protocol
           </para></listitem>
	   </varlistentry>
	   <varlistentry>
           <term>
	   RFCOMM Module
	   </term>
           <listitem><para>
	   RFCOMM Protocol
           </para></listitem>
	   </varlistentry>
	   <varlistentry>
           <term>
	   BNEP Module
	   </term>
           <listitem><para>
	   Bluetooth Network Encapsulation Protocol
           </para></listitem>
	   </varlistentry>
	   <varlistentry>
           <term>
	   CMTP Module
	   </term>
           <listitem><para>
	   CAPI Message Transport Protocol
           </para></listitem>
	   </varlistentry>
	   <varlistentry>
           <term>
	   HIDP Module
	   </term>
           <listitem><para>
	   Human Interface Device Protocol
           </para></listitem>
	   </varlistentry>
	</variablelist>
	<para>
	To use the Linux Bluetooth subsystem, you will need several user-space
	utilities such as <command>hciconfig</command> and <command>hcid</command>.  These utilities and updates to
	Bluetooth kernel modules are provided in the BlueZ packages at
	<systemitem role="url">http://www.bluez.org</systemitem>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_IEEE80211">
<refnamediv>
	<refname>IEEE80211</refname>
	<refpurpose>Generic IEEE 802.11 Networking Stack</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	This option enables the hardware-independent IEEE 802.11
	networking stack.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_MTD">
<refnamediv>
	<refname>MTD</refname>
	<refpurpose>Memory Technology Device (MTD) support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_PARPORT">
<refnamediv>
	<refname>PARPORT</refname>
	<refpurpose>Parallel port support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	Please read
	<filename>Documentation/parport.txt</filename> and
	<filename>drivers/parport/BUGS-parport</filename> for more information.	For extensive information about drivers for many devices attaching
	to the parallel port, see <systemitem role="url">http://www.torque.net/linux-pp.html</systemitem>.
	</para>

	<para>
	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 <filename>Documentation/parport.txt</filename>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_PNP">
<refnamediv>
	<refname>PNP</refname>
	<refpurpose>Plug and Play support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	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 <command>isapnptools</command> package.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_ISAPNP">
<refnamediv>
	<refname>ISAPNP</refname>
	<refpurpose>ISA Plug and Play support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	Say yes here if you would like support for ISA Plug and Play devices.
	Some information is available in <filename>Documentation/isapnp.txt</filename>.
	</para>

	<para>
	If you use have ISA Plug and Play devices, please use the ISA PnP
	tools found at
	<systemitem role="url">http://www.roestock.demon.co.uk/isapnptools</systemitem>
	to configure them properly.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_PNPBIOS">
<refnamediv>
	<refname>PNPBIOS</refname>
	<refpurpose>Plug and Play BIOS support (experimental)</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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).
	</para>

	<para>
	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.
	</para>

	<para>
	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.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_IDE">
<refnamediv>
	<refname>IDE</refname>
	<refpurpose>ATA/ATAPI/MFM/RLL support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	If your system is pure SCSI and doesn't use these interfaces, you
	can say no here.
	</para>

	<para>
	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.
	</para>

	<para>
	AT Attachment (ATA) is the superset of the IDE specifications.
	ST506 is also called ATA-1.
	</para>

	<para>
	Fast-IDE is ATA-2 (also named Fast ATA).
	</para>

	<para>
	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.
	</para>

	<para>

	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.
	</para>

	<para>
	ATA Packet Interface (ATAPI) is a protocol used by EIDE tape and
	CD-ROM drives, similar in many respects to the SCSI protocol.
	</para>

	<para>
	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 <command>smart</command> that can query the status of
	SMART parameters from disk drives.
	</para>

	<para>
	For further information, please read <filename>Documentation/ide.txt</filename>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_BLK_DEV_IDE">
<refnamediv>
	<refname>BLK_DEV_IDE</refname>
	<refpurpose>Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	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 <filename>Documentation/ide.txt</filename>. For detailed
	information about hard drives, consult the Disk-HOWTO and the
	Multi-Disk-HOWTO, available from
	<systemitem role="url">http://www.tldp.org/docs.html#howto</systemitem>.
	</para>

	<para>
	To fine-tune ATA/IDE drive/interface parameters for improved
	performance, look for the <literal>hdparm</literal> package at
	<systemitem role="url">ftp://ibiblio.org/pub/Linux/system/hardware</systemitem>.
	</para>

	<para>
	Do not compile this driver as a module if your root file system (the
	one containing the directory <filename>/</filename>) is located on an
	IDE device.
	</para>

	<para>
	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 <literal>Old hard disk
	driver</literal> option instead to save about 13 KB of memory in
	the kernel.
	</para>

</refsect1>
</refentry>


<refentry id="CONFIG_BLK_DEV_IDEDISK">
<refnamediv>
	<refname>BLK_DEV_IDEDISK</refname>
	<refpurpose>Include IDE/ATA-2 DISK support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	Do not compile this driver as a module if your root file system
	(the one containing the directory <filename>/</filename>) is
	located on the IDE disk.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_BLK_DEV_IDECD">
<refnamediv>
	<refname>BLK_DEV_IDECD</refname>
	<refpurpose>Include IDE/ATAPI CDROM support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	If you say yes here, the CD-ROM drive will be identified at boot
	time along with other IDE devices, as something such as <literal>hdb</literal> or
	<literal>hdc</literal> (check the boot
	messages using the <command>dmesg</command> 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
	<literal>ISO 9660 CD-ROM file system support</literal> option.
	</para>

	<para>
	Note that older versions of LILO (LInux LOader) cannot properly deal
	with IDE/ATAPI CD-ROMs, so install LILO 16 or higher, available from
	<systemitem role="url">http://lilo.go.dyndns.org</systemitem>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_BLK_DEV_IDEFLOPPY">
<refnamediv>
	<refname>BLK_DEV_IDEFLOPPY</refname>
	<refpurpose>Include IDE/ATAPI FLOPPY support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	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
	<systemitem role="url">http://www.win.tue.nl/~aeb/linux/zip/zip-1.html</systemitem>.
	(ATAPI PD-CD/CDR drives are not supported by this driver; support
	for PD-CD/CDR drives is available if you answer yes to
	<literal>SCSI emulation support</literal>).
	</para>

	<para>
	If you say yes here, the FLOPPY drive will be identified along with
	other IDE devices, with a name such as <literal>hdb</literal> or
	<literal>hdc</literal> (check the boot
	messages using the <command>dmesg</command> command).
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_SCSI">
<refnamediv>
	<refname>SCSI</refname>
	<refpurpose>SCSI device support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	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.
	</para>

	<para>
	Do not compile this as a module if your root file system (the one
	containing the directory <filename>/</filename>) is located on a
	SCSI device.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_BLK_DEV_SD">
<refnamediv>
	<refname>BLK_DEV_SD</refname>
	<refpurpose>SCSI disk support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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
	<systemitem role="url">http://www.tldp.org/docs.html#howto</systemitem>.
	This is <emphasis>not</emphasis> for SCSI CD-ROMs.
	</para>

	<para>
	Do not compile this driver as a module if your root file system
	(the one containing the directory <filename>/</filename>) is
	located on a SCSI disk.  In this case, do not compile the driver
	for your SCSI host adapter as a module either.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_CHR_DEV_ST">
<refnamediv>
	<refname>CHR_DEV_ST</refname>
	<refpurpose>SCSI tape support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	If you want to use a SCSI tape drive under Linux, say yes and read the
	SCSI-HOWTO, available from
	<systemitem role="url">http://www.tldp.org/docs.html#howto</systemitem>, and
	<filename>Documentation/scsi/st.txt</filename> in the kernel source.  This is <emphasis>not</emphasis>
	for SCSI CD-ROMs.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_BLK_DEV_SR">
<refnamediv>
	<refname>BLK_DEV_SR</refname>
	<refpurpose>SCSI CDROM support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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
	<systemitem
	role="url">http://www.tldp.org/docs.html#howto</systemitem>
	for more directions.
	Also make sure to enable the <literal>ISO 9660 CD-ROM file system
	support</literal> option.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_CHR_DEV_SG">
<refnamediv>
	<refname>CHR_DEV_SG</refname>
	<refpurpose>SCSI generic support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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:
	</para>

	<para>
	For scanners, look at SANE
	<systemitem role="url">http://www.sane-project.org</systemitem>.
	For CD writer software look at Cdrtools
	<systemitem role="url">http://cdrecord.berlios.de/old/private/cdrecord.html</systemitem>,
	and for burning a "disk at once," check out CDRDAO
	<systemitem role="url">http://cdrdao.sourceforge.net</systemitem>.
	Cdparanoia is a high quality digital reader of audio CDs
	(<systemitem role="url">http://www.xiph.org/paranoia</systemitem>).
	For other devices, it's possible that you'll have to write the
	driver software yourself. Please read the file
	<filename>Documentation/scsi/scsi-generic.txt</filename> for more information.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_CHR_DEV_SCH">
<refnamediv>
	<refname>CHR_DEV_SCH</refname>
	<refpurpose>SCSI media changer support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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
	<filename>/proc/scsi/scsi</filename>.
	Check <filename>Documentation/scsi/scsi-changer.txt</filename>
	for details.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_SCSI_MULTI_LUN">
<refnamediv>
	<refname>SCSI_MULTI_LUN</refname>
	<refpurpose>Probe all LUNs on each SCSI device</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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 <literal>max_luns</literal>
	boot/module parameter allows you to override this setting.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_SCSI_SATA">
<refnamediv>
	<refname>SCSI_SATA</refname>
	<refpurpose>Serial ATA (SATA) support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	This driver family supports Serial ATA host controllers
	and devices.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_MD">
<refnamediv>
	<refname>MD</refname>
	<refpurpose>Multiple devices driver support (RAID and LVM)</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	This option supports multiple physical spindles through a
	single logical device, and is required for RAID and logical volume management.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_BLK_DEV_MD">
<refnamediv>
	<refname>BLK_DEV_MD</refname>
	<refpurpose>RAID support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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 <firstterm>software RAID</firstterm> because the combining of
	the partitions is done by the kernel. <firstterm>Hardware RAID</firstterm> means that the
	combining is done by a dedicated controller; if you have such a
	controller, you do not need to say yes here.
	</para>

	<para>
	More information about software RAID on Linux is n the
	Software RAID mini-HOWTO, available from
	<systemitem role="url">http://www.tldp.org/docs.html#howto</systemitem>.
	There you will also learn where to get the supporting userspace raidtools
	utilities.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_BLK_DEV_DM">
<refnamediv>
	<refname>BLK_DEV_DM</refname>
	<refpurpose>Device mapper support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	Higher level volume managers such as LVM2 use this driver.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_IEEE1394">
<refnamediv>
	<refname>IEEE1394</refname>
	<refpurpose>IEEE 1394 (FireWire) support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	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.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_I2O">
<refnamediv>
	<refname>I2O</refname>
	<refpurpose>I2O support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	If you say yes here, you will get a choice of interface adapter
	drivers and OSMs and will have to enable the correct ones.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_NETDEVICES">
<refnamediv>
	<refname>NETDEVICES</refname>
	<refpurpose>Network device support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	You can say no here if you do not intend to connect your Linux box to
	any other computer.
	</para>

	<para>
	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.
	</para>

	<para>
	See also the <emphasis>Linux Network Administrator's
	Guide</emphasis> (O'Reilly) available at
	<systemitem role="url">http://www.tldp.org/guides.html</systemitem>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_NET_ETHERNET">
<refnamediv>
	<refname>NET_ETHERNET</refname>
	<refpurpose>Ethernet (10 or 100Mbit)</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	Ethernet (also called IEEE 802.3 or ISO 8802-2) is the most common
	type of Local Area Network (LAN) in universities and companies.
	</para>

	<para>
	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.
	</para>

	<para>
	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
	<systemitem role="url">http://www.tldp.org/docs.html#howto</systemitem>.
	You will then also have to say yes to the driver for your
	particular NIC.
	</para>

	<para>
	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.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_NET_RADIO">
<refnamediv>
	<refname>NET_RADIO</refname>
	<refpurpose>Wireless LAN drivers (non-hamradio) and Wireless Extensions</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	Support for wireless LANs and everything having to do with
<!--

  AO: I hope the added word below is correct.

  gkh: yes it is.

-->
	packet radio,
	but not with amateur radio or FM broadcasting.
	</para>

	<para>
	Saying yes here also enables the Wireless Extensions, creating
	<filename>/proc/net/wireless</filename> and enabling <command>iwconfig</command> 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
	<systemitem role="url">http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html</systemitem>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_PPP">
<refnamediv>
	<refname>PPP</refname>
	<refpurpose>PPP (point-to-point protocol) support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	To use PPP, you need an additional program called <command>pppd</command> as described
	in the PPP-HOWTO, available at
	<systemitem role="url">http://www.tldp.org/docs.html#howto</systemitem>.
	Make sure that you have the version of <command>pppd</command> recommended in
	<filename>Documentation/Changes</filename>.  The PPP option
	enlarges your kernel by about 16 KB.
	</para>

	<para>
	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 <literal>PPP
	support for async serial ports</literal> option.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_PPPOE">
<refnamediv>
	<refname>PPPOE</refname>
	<refpurpose>PPP over Ethernet (experimental)</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	Support for PPP over Ethernet.
	</para>

	<para>
	This driver requires the latest version of <command>pppd</command> from the CVS
	repository at <emphasis>cvs.samba.org</emphasis>.  Alternatively, see the
	RoaringPenguin package
	<systemitem role="url">http://www.roaringpenguin.com/pppoe</systemitem>,
	which contains instruction on hows to use this driver under the
	heading "Kernel mode PPPoE."
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_ISDN">
<refnamediv>
	<refname>ISDN</refname>
	<refpurpose>ISDN support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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
	<systemitem role="url">http://www.alumni.caltech.edu/~dank/isdn</systemitem>.
	</para>

	<para>
	Select this option if you want your kernel to support ISDN.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_PHONE">
<refnamediv>
	<refname>PHONE</refname>
	<refpurpose>Linux telephony support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	Say yes here if you have a telephony card, which for example allows
	you to use a regular phone for voice-over-IP applications.
	</para>

	<note>
	<para>
	This option has nothing to do with modems.  You do not need to say
	yes here in order to be able to use a modem under Linux.
	</para>
	</note>

</refsect1>
</refentry>

<refentry id="CONFIG_INPUT">
<refnamediv>
	<refname>INPUT</refname>
	<refpurpose>Generic input layer (needed for keyboard, mouse, ...)</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	Say no here if you have a headless (no monitor, no keyboard) system.
	</para>

	<para>
	More information is available in the file
	<filename>Documentation/input/input.txt</filename>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_VT">
<refnamediv>
	<refname>VT</refname>
	<refpurpose>Virtual terminal</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	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.
	</para>

	<para>
	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.
	</para>

<!--

  AO: I actually think the following paragraph is outside the scope of
  the book.

  gkh: good point, now deleted.

-->

	<para>
	If you are unsure, say yes, or else you won't be able to do much with your
	Linux system.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_VT_CONSOLE">
<refnamediv>
	<refname>VT_CONSOLE</refname>
	<refpurpose>Support for console on virtual terminal</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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 <literal>Console on 8250/16550 and compatible serial
	port</literal> option).
	</para>

	<para>
	If you say yes here, by default, the currently visible virtual
	terminal (<filename>/dev/tty0</filename>) will be used as system console. You can change
	that with a kernel command line option such as
	<literal>console=tty3</literal>, which specified the third virtual
	terminal as the system console. (See <xref
	linkend="LKN-command-line" /> for details about how to pass
	options to the kernel at boot time, and what options available.)
<!--

  AO: See what I said earlier about bootparam.

  gkh: same cross reference added here

-->
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_SERIAL_8250">
<refnamediv>
	<refname>SERIAL_8250</refname>
	<refpurpose>8250/16550 and compatible serial support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<note>
	<para>
	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.
	</para>
	</note>

	<para>
	Most people will say yes here, so that they can use serial mice,
	modems, and similar devices connected to the standard serial ports.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_AGP">
<refnamediv>
	<refname>AGP</refname>
	<refpurpose>/dev/agpgart (AGP Support)</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	AGP (Accelerated Graphics Port) is a bus system used mainly to
	connect graphics cards to the rest of the system.
	</para>

	<para>
	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.
	</para>

	<para>
	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.
	</para>

	<para>
	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.
	</para>

	<para>
	You should say yes here if you want to use GLX or DRI.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_DRM">
<refnamediv>
	<refname>DRM</refname>
	<refpurpose>Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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
	<systemitem role="url">http://dri.sourceforge.net</systemitem>
	for details.  You should also select and configure AGP
	(<filename>/dev/agpgart</filename>) support.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_I2C">
<refnamediv>
	<refname>I2C</refname>
	<refpurpose>I2C support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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
	<filename>Documentation/i2c</filename>,
	especially in the file there called <filename>summary</filename>.
	</para>

	<para>
	Both I2C and SMBus are supported by this option. You will need it for
	hardware sensors support and Video For Linux support.
	</para>

	<para>
	If you want I2C support, in addition to saying yes here, you
	must also select the
	specific drivers for your bus adapters.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_SPI">
<refnamediv>
	<refname>SPI</refname>
	<refpurpose>SPI support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	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.
	</para>

	<para>
	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.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_HWMON">
<refnamediv>
	<refname>HWMON</refname>
	<refpurpose>Hardware monitoring support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_VIDEO_DEV">
<refnamediv>
	<refname>VIDEO_DEV</refname>
	<refpurpose>Video For Linux</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	This option enables support for audio/video capture and overlay devices and FM radio
	cards. The exact capabilities of each device vary.
	</para>

	<para>
	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.
	</para>

	<para>
	Additional info and docs are available at
	<systemitem role="url">http://linuxtv.org</systemitem>.
	Documentation for V4L2 is also available at
	<systemitem role="url">http://bytesex.org/v4l</systemitem>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_DVB">
<refnamediv>
	<refname>DVB</refname>
	<refpurpose>DVB For Linux</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	API specs and user tools are available from
	<systemitem role="url">http://www.linuxtv.org</systemitem>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_FB">
<refnamediv>
	<refname>FB</refname>
	<refpurpose>Support for frame buffer devices</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	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.
	</para>

	<para>
	You need a program called <command>fbset</command> to make full use of frame
	buffer devices. Please read <filename>Documentation/fb/framebuffer.txt</filename>
	and the Framebuffer-HOWTO at
	<systemitem role="url">http://www.tldp.org/HOWTO/Framebuffer-HOWTO.html</systemitem>
	for more information.
	</para>

	<para>
	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
<!--

  AO: What does it mean to play with something?

  gkh:  heh, ok, now changed :)

-->
	want to use the frame buffer, but it is not essential.
	</para>

	<para>
	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.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_VGA_CONSOLE">
<refnamediv>
	<refname>VGA_CONSOLE</refname>
	<refpurpose>VGA text console</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	The program SVGATextMode can be used to utilize SVGA video cards to
	their full potential in text mode. Download it from
	<systemitem role="url">ftp://ibiblio.org/pub/Linux/utils/console</systemitem>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_LOGO">
<refnamediv>
	<refname>LOGO</refname>
	<refpurpose>Bootup logo</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	This option enables the pretty penguin logo at boot time.  It will
	show up on the frame buffer while the kernel is booting.  The
	number of penguins shows the number of processors that the kernel
	has found.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_SOUND">
<refnamediv>
	<refname>SOUND</refname>
	<refpurpose>Sound card support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	Read the Sound-HOWTO, available from
	<systemitem role="url">http://www.tldp.org/docs.html#howto</systemitem>. General information about
	the modular sound system is contained in the file
	<filename>Documentation/sound/oss/Introduction</filename>.  The file
	<filename>Documentation/sound/oss/README.OSS</filename> contains some slightly
	outdated but still useful information as well.  Newer sound
	driver documentation can be found in files in the
	<filename>Documentation/sound/alsa</filename> directory.
	</para>

	<para>
	If you have a PnP sound card and you want to configure it at boot
	time using the ISA PnP tools (read
	<systemitem role="url">http://www.roestock.demon.co.uk/isapnptools</systemitem>),
	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
	<filename>Documentation/sound/oss/README.modules</filename>
	</para>

	<para>
	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 <literal>pcsp</literal>
	package, available at
	<systemitem role="url">ftp://ftp.infradead.org/pub/pcsp</systemitem>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_SND">
<refnamediv>
	<refname>SND</refname>
	<refpurpose>Advanced Linux sound architecture</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	Say yes to enable ALSA (Advanced Linux Sound Architecture), the
	standard Linux sound system.
	</para>

	<para>
	For more information, see <systemitem role="url">http://www.alsa-project.org</systemitem>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_SND_USB_AUDIO">
<refnamediv>
	<refname>SND_USB_AUDIO</refname>
	<refpurpose>USB Audio/MIDI driver</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	Say yes here to include support for USB audio and USB MIDI
	devices.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_USB">
<refnamediv>
	<refname>USB</refname>
	<refpurpose>Support for Host-side USB</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	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.
	</para>

	<para>
	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 <literal>UHCI HCD support</literal> or
	<literal>OHCI HCD support</literal>, and
	<literal>EHCI HCD (USB 2.0) support</literal> except for older
	systems that do not have USB 2.0 support.  It does not hurt to
	select them all if you are not certain.
	</para>

	<para>
	If your system has a device-side USB port, used in the peripheral
	side of the USB protocol, see the <literal>USB Gadget</literal>
	option instead.
	</para>

	<para>
	After choosing your HCD, select drivers for the USB peripherals
	you'll be using.  You may want to check out the information provided
	in <filename>Documentation/usb</filename> and especially the links given in
	<filename>Documentation/usb/usb-help.txt</filename>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_USB_EHCI_HCD">
<refnamediv>
	<refname>USB_EHCI_HCD</refname>
	<refpurpose>EHCI HCD (USB 2.0) support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	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.
	</para>

	<para>
	You may want to read
	<filename>Documentation/usb/ehci.txt</filename> for more
	information on this driver.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_USB_OHCI_HCD">
<refnamediv>
	<refname>USB_OHCI_HCD</refname>
	<refpurpose>OHCI HCD support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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 <command>lspci -v</command> command
	will list the right <literal>prog-if</literal> for your USB
	controller(s):  EHCI, OHCI, or UHCI.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_USB_UHCI_HCD">
<refnamediv>
	<refname>USB_UHCI_HCD</refname>
	<refpurpose>UHCI HCD (most Intel and VIA) support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_USB_STORAGE">
<refnamediv>
	<refname>USB_STORAGE</refname>
	<refpurpose>USB mass storage support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	This option enables the
	<literal>SCSI</literal> option, but you probably also need
	<literal>SCSI device support: SCSI disk support</literal> for most
	USB storage devices to work properly.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_USB_SERIAL">
<refnamediv>
	<refname>USB_SERIAL</refname>
	<refpurpose>USB serial converter support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	Say yes here if you have a USB device that provides normal serial
	ports, or acts like a serial device, and you want to connect it to
	your USB bus.
	</para>

	<para>
	Please read <filename>Documentation/usb/usb-serial.txt</filename>
	for more information on the specifics of the different devices that
	are supported, and on how to use them.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_USB_GADGET">
<refnamediv>
	<refname>USB_GADGET</refname>
	<refpurpose>Support for USB Gadgets</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	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.
	</para>

	<para>
	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.)
	</para>

	<para>
	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).
	</para>

	<para>
	For more information, see
	<systemitem role="url">http://www.linux-usb.org/gadget</systemitem>
	and the kernel DocBook documentation for this API.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_MMC">
<refnamediv>
	<refname>MMC</refname>
	<refpurpose>MMC support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	MMC is the "multi-media card" bus protocol.
	</para>

	<para>
	If you want MMC support, you should say yes here and also
	to the specific driver for your MMC interface.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_INFINIBAND">
<refnamediv>
	<refname>INFINIBAND</refname>
	<refpurpose>InfiniBand support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	Core support for InfiniBand (IB).  Make sure to also select
	any protocols you wish to use as well as drivers for your
	InfiniBand hardware.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_EDAC">
<refnamediv>
	<refname>EDAC</refname>
	<refpurpose>EDAC core system error reporting (experimental)</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	If this code is reporting problems on your system, please
	see the EDAC project web pages for more information:
	<systemitem role="url">http://bluesmoke.sourceforge.net</systemitem>
	and
	<systemitem role="url">http://buttersideup.com/edacwiki</systemitem>
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_EXT2_FS">
<refnamediv>
	<refname>EXT2_FS</refname>
	<refpurpose>Second extended filesystem support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	<literal>ext2</literal> is a standard Linux file system for
	hard disks. Most systems use the upgrade,
	<literal>ext3</literal>, instead.
	</para>

<!--

  AO: One instance of this is enough, particularly if we call it out
  as a note.

  gkh: are you sure?  It's an important thing that if you are just
  flipping through and are only looking for one filesystem reference.  I
  vote to leave it.

-->
	<note>
	<para>
	Note that the file system of your root partition (the
	one containing the directory <filename>/</filename>) cannot be
	compiled as a module without using a special boot process, so
	building it as a module could be dangerous.
	</para>
	</note>

</refsect1>
</refentry>

<refentry id="CONFIG_EXT3_FS">
<refnamediv>
	<refname>EXT3_FS</refname>
	<refpurpose>Third extended file system support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	This is the journaling version (called <literal>ext3</literal>) of the second extended file system, the de facto standard Linux file system for hard disks.
	</para>

	<para>
	The journaling code included in this driver means you do not have
	to run <command>fsck</command> (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.
	</para>

	<para>
	Other than adding the journal to the file system, the on-disk format
	of <literal>ext3</literal> is identical to <literal>ext2</literal>.  It is possible to freely switch
	between using the <literal>ext3</literal> driver and the <literal>ext2</literal> driver, as long as the
	file system has been cleanly unmounted, or <command>fsck</command> is run on the file
<!--

  AO: Or after the switch?

  gkh: no, I think "before" is correct.

-->
	system before the switch.
	</para>

	<para>
	To add a journal on an existing <literal>ext2</literal> file system or change the
	behavior of <literal>ext3</literal> file systems, you can use the <command>tune2fs</command> utility.  To modify attributes of
	files and directories on <literal>ext3</literal> file systems, use <command>chattr</command>.  You need
	<literal>e2fsprogs</literal> version 1.20 or later in order to
	create <literal>ext3</literal> journals (available at
	<systemitem role="url">http://sourceforge.net/projects/e2fsprogs</systemitem>).
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_REISERFS_FS">
<refnamediv>
	<refname>REISERFS_FS</refname>
	<refpurpose>ReiserFS support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	In general, ReiserFS is as fast as <literal>ext2</literal>, but is more efficient with
	large directories and small files.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_JFS_FS">
<refnamediv>
	<refname>JFS_FS</refname>
	<refpurpose>JFS filesystem support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	This is a port of IBM's Journaled Filesystem .  More information is
	available in the file <filename>Documentation/filesystems/jfs.txt</filename>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_XFS_FS">
<refnamediv>
	<refname>XFS_FS</refname>
	<refpurpose>XFS filesystem support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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.
	</para>

	<para>
	Refer to the documentation at <systemitem role="url">http://oss.sgi.com/projects/xfs</systemitem>
	for complete details.  This implementation is on-disk compatible
	with the IRIX version of XFS.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_OCFS2_FS">
<refnamediv>
	<refname>OCFS2_FS</refname>
	<refpurpose>OCFS2 file system support (experimental)</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	OCFS2 is a general-purpose, extent-based, shared-disk cluster file
	system with many similarities to <literal>ext3</literal>. It supports 64 bit inode
	numbers, and has automatically extending metadata groups, which may
	also make it attractive for non-clustered use.
	</para>

	<para>
	You'll want to install the ocfs2-tools package in order to at least
	get the <command>mount.ocfs2</command> program.
	</para>

	<para>
	The project web page is <systemitem
	role="url">http://oss.oracle.com/projects/ocfs2</systemitem>
	and the
	tools web page is <systemitem
	role="url">http://oss.oracle.com/projects/ocfs2-tools</systemitem>. 
	OCFS2 mailing lists can be found at <systemitem role="url">http://oss.oracle.com/projects/ocfs2/mailman</systemitem>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_INOTIFY">
<refnamediv>
	<refname>INOTIFY</refname>
	<refpurpose>inotify file change notification support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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 <literal>fd</literal> object.  Other features
	include multiple file events, one-shot support, and unmount
	notification.
	</para>

	<para>
	For more information, see
	<filename>Documentation/filesystems/inotify.txt</filename>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_QUOTA">
<refnamediv>
	<refname>QUOTA</refname>
	<refpurpose>Quota support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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
	<literal>ext2</literal>, <literal>ext3</literal>, and ReiserFS file system. <literal>ext3</literal> also supports journalled
	quotas, for which you don't need to run <command>quotacheck</command> after an unclean
	shutdown.
	For further details, read the Quota mini-HOWTO, available from
	<systemitem role="url">http://www.tldp.org/docs.html#howto</systemitem>,
	or the documentation provided with the quota tools. 
	Quota support is probably useful only for multi-user systems.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_AUTOFS_FS">
<refnamediv>
	<refname>AUTOFS_FS</refname>
	<refpurpose>Kernel automounter support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
<!--

  AO: Also local file systems, such as CDs, right?

  gkh: not anymore, HAL handles this from userspace without using autofs
  anymore.

-->
	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
	automounter (<literal>amd</literal>), which is a pure user space daemon.
	</para>

	<para>
	To use the automounter, you need the user-space tools from the
	<literal>autofs</literal> package; you can find the location in
	<filename>Documentation/Changes</filename>.  You also want to
	answer yes to the <literal>NFS file system support</literal>
	option.
	</para>

	<para>
	If you want to use the newer version of the automounter with more
	features, say no here and say yes to the <literal>Kernel
	automounter v4 support</literal> option.
	</para>

	<para>
	If you are not a part of a fairly large, distributed network, you
	probably do not need an automounter, and can say no here.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_FUSE_FS">
<refnamediv>
	<refname>FUSE_FS</refname>
	<refpurpose>Filesystem in Userspace support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	With FUSE it is possible to implement a fully functional filesystem
	in a userspace program.
	</para>

	<para>
	There's also companion library named <emphasis>libfuse</emphasis>.  This library, along with
	utilities, is available from the FUSE homepage:
	<systemitem role="url">http://fuse.sourceforge.net</systemitem>.
	</para>

	<para>
	See <filename>Documentation/filesystems/fuse.txt</filename> for more information.
	See <filename>Documentation/Changes</filename> for
	library/utility version you need.
	</para>

	<para>
	If you want to develop a userspace filesystem, or if you want to use a
	filesystem based on FUSE, answer yes here.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_SMB_FS">
<refnamediv>
	<refname>SMB_FS</refname>
	<refpurpose>SMB file system support (to mount Windows shares etc.)</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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, read
	<filename>Documentation/filesystems/smbfs.txt</filename> and the
	SMB-HOWTO, available from
	<systemitem role="url">http://www.tldp.org/docs.html#howto</systemitem>.
	</para>

	<para>
	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
	<systemitem role="url">ftp://ftp.samba.org/pub/samba</systemitem>).
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_CIFS">
<refnamediv>
	<refname>CIFS</refname>
	<refpurpose>CIFS support (advanced network filesystem for Samba, Window and other CIFS compliant servers)</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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 <literal>smbfs</literal> client filesystem to access older SMB
	servers such as OS/2 and DOS.
	</para>

	<para>
	The intent of the <literal>cifs</literal> module 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
<!--

  AO: I don't understand this paragraph because the phrase "mount to"
  is ambiguous. Clients mount directories from servers. Servers export
  directories to clients.

  gkh: cifs is used to mount to servers running either Samba or windows.
  So its use here is correct.

-->
	not need to enable <literal>cifs</literal> if you are running only a server (Samba). It is
	possible to enable both <literal>smbfs</literal> and <literal>cifs</literal> (e.g. if you are using CIFS
	for accessing Windows 2003 and Samba 3 servers, and <literal>smbfs</literal> for
	accessing old servers). If you need to mount to Samba or Windows
	from this machine, say yes to this option.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_PROFILING">
<refnamediv>
	<refname>PROFILING</refname>
	<refpurpose>Profiling support (experimental)</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	Say yes here to enable the extended profiling support mechanisms
	used by profilers such as OProfile.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_OPROFILE">
<refnamediv>
	<refname>OPROFILE</refname>
	<refpurpose>OProfile system profiling (experimental)</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	OProfile is a profiling system capable of profiling the whole
	system, include the kernel, kernel modules, libraries, and
	applications.
	</para>

	<para>
	For more information, and links to the userspace tools needed to
	use OProfile properly, see the main project page at
	<systemitem
	role="url">http://oprofile.sourceforge.net/news</systemitem>.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_KPROBES">
<refnamediv>
	<refname>KPROBES</refname>
	<refpurpose>Kprobes (experimental)</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	Kprobes allows you to trap the CPU at almost any kernel address and execute
	a callback function.  <literal>register_kprobe()</literal> establishes a probepoint
	and specifies the callback.  Kprobes is useful for kernel
	debugging, non-intrusive instrumentation, and testing.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_PRINTK_TIME">
<refnamediv>
	<refname>PRINTK_TIME</refname>
	<refpurpose>Show timing information on printks</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	Selecting this option causes timing information to be included in
	<literal>printk</literal> (kernel message) output.  This allows you to measure the interval between
	kernel operations, including bootup operations.  This is useful for
	identifying long delays in kernel startup.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_MAGIC_SYSRQ">
<refnamediv>
	<refname>MAGIC_SYSRQ</refname>
	<refpurpose>Magic SysRq key</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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
	<filename>Documentation/sysrq.txt</filename>. Don't say yes unless
	you really know what this hack does.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_DEBUG_KERNEL">
<refnamediv>
	<refname>DEBUG_KERNEL</refname>
	<refpurpose>Kernel debugging</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	Say yes here if you are developing drivers or trying to debug and
	identify kernel problems.
	</para>

	<para>
	On it's own, this option does not do anything except allow you to
	chance to select other options.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_DEBUG_FS">
<refnamediv>
	<refname>DEBUG_FS</refname>
	<refpurpose>Debug filesystem</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	debugfs is a virtual file system where kernel developers put
	debugging files.  Enable this option to be able to read and
	write to these files.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_SECURITY">
<refnamediv>
	<refname>SECURITY</refname>
	<refpurpose>Enable different security models</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	This allows you to configure different security modules into your kernel.
	</para>

	<para>
	If this option is not selected, the default Linux security
	model will be used.
	</para>

</refsect1>
</refentry>

<refentry id="CONFIG_SECURITY_SELINUX">
<refnamediv>
	<refname>SECURITY_SELINUX</refname>
	<refpurpose>NSA SELinux Support</refpurpose>
</refnamediv>
<refsect1>
	<title>Description</title>
	<para>
	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 <systemitem role="url">http://www.nsa.gov/selinux</systemitem>.
	</para>

</refsect1>
</refentry>

</chapter>
<!-- vim: set ai tw=72 : -->