10.Device Drivers

kevinislinuxer

       
       
       
       
       
       
       
       

Device
        Drivers
       
       

Generic
                Driver Options
               
               

Select
                        only drivers that don't need compile-time external firmware
               
       
Select
this option if you don't have magic firmware for drivers that
need
it.
If
unsure, say Y.

Prevent
                        firmware from being built
                       
               
Say
yes to avoid building firmware. Firmware is usually shipped
with
the driver, and only when updating the firmware a rebuild
should
be made.
If
unsure say Y here.

Userspace
                        firmware loading support
               
This
option is provided for the case where no in-kernel-tree modules
require
userspace firmware loading support, but a module built outside
the
kernel tree does.

Driver
                        Core verbose debug messages
               
Say
Y here if you want the Driver core to produce a bunch of
debug
messages to the system log. Select this if you are having a
problem
with the driver core and want to see more of what is
going
on.
If
you are unsure about this, say N here.

Connector
                - unified userspace  kernelspace linker
               
               

Connector
                        - unified userspace  kernelspace linker
               
       
This
is unified userspace  kernelspace connector working on top
of
the netlink socket protocol.
Connector
support can also be built as a module.  If so, the module
will
be called cn.ko.

Memory
                Technology Devices (MTD)
               
               

Memory
                        Technology Device (MTD) support
               
       
Memory
Technology Devices are flash, RAM and similar chips, often
used
for solid state file systems on embedded devices. This option
will
provide the generic support for MTD drivers to register
themselves
with the kernel and for potential users of MTD devices
to
enumerate the devices which are present and obtain a handle on
them.
It will also allow you to select individual drivers for
particular
hardware and users of MTD devices. If unsure, say N.

Debugging
                       
This
turns on low-level debugging for the entire MTD sub-system.
Normally,
you should say 'N'.

MTD
                                concatenating support
                       
Support
for concatenating several MTD devices into a single
(virtual)
one. This allows you to have -for example- a JFFS(2)
file
system spanning multiple physical flash chips. If unsure,
say
'Y'.

MTD
                                partitioning support
                       
If
you have a device which needs to divide its flash chip(s) up
into
multiple 'partitions', each of which appears to the user as
a
separate MTD device, you require this option to be enabled. If
unsure,
say 'Y'.
Note,
however, that you don't need this option for the DiskOnChip
devices.
Partitioning on NFTL 'devices' is a different - that's the
'normal'
form of partitioning used on a block device.

RedBoot
                                        partition table parsing
                               
RedBoot
is a ROM monitor and bootloader which deals with multiple
'images'
in flash devices by putting a table one of the erase
blocks
on the device, similar to a partition table, which gives
the
offsets, lengths and names of all the images stored in the
[color="#008080"]flash.
If
you need code which can detect and parse this table, and register
MTD
'partitions' corresponding to each image in the table, enable
this
option.
You
will still need the parsing functions to be called by the driver
for
your particular device. It won't happen automatically. The
SA1100
map driver (CONFIG_MTD_SA1100) has an option for this, for
[color="#008080"]example.

Location
                                                of RedBoot partition table
                                               
                                       
This
option is the Linux counterpart to the
CYGNUM_REDBOOT_FIS_DIRECTORY_BLOCK
RedBoot compile time
[color="#008080"]option.
The
option specifies which Flash sectors holds the RedBoot
partition
table.  A zero or positive value gives an absolete
erase
block number. A negative value specifies a number of
sectors
before the end of the device.
For
example "2" means block number 2, "-1" means the
last
block
and "-2" means the penultimate block.

Include
                                                unallocated flash regions
                                       
If
you need to register each unallocated flash region as a MTD
'partition',
enable this option.

Force
                                                read-only for RedBoot system images
                                       
If
you need to force read-only for 'RedBoot', 'RedBoot Config' and
'FIS
directory' images, enable this option.

Command
                                        line partition table parsing
                               
Allow
generic configuration of the MTD paritition tables via the kernel
command
line. Multiple flash resources are supported for hardware where
different
kinds of flash memory are available.
You
will still need the parsing functions to be called by the driver
for
your particular device. It won't happen automatically. The
SA1100
map driver (CONFIG_MTD_SA1100) has an option for this, for
[color="#008080"]example.
The
format for the command line is as follows:
[color="#008080"]mtdparts=[;
:= :[,]
:= [@offset][][ro]
:= unique id used in mapping driver/device
   := standard linux memsize OR "-" to denote all
remaining
space
   := (NAME)
Due
to the way Linux handles the command line, no spaces are
allowed
in the partition definition, including mtd id's and partition
[color="#008080"]names.
[color="#008080"]Examples:
1
flash resource (mtd-id "sa1100"), with 1 single writable
partition:
[color="#008080"]mtdparts=sa1100:-
Same
flash, but 2 named partitions, the first one being read-only:
[color="#008080"]mtdparts=sa1100:256k(ARMboot)ro,-(root)
If
unsure, say 'N'.

User
                                Modules And Translation Layers
                               
                               

Direct
                                char device access to MTD devices
                       
This
provides a character device for each MTD device present in
the
system, allowing the user to read and write directly to the
memory
chips, and also use ioctl() to obtain information about
the
device, or to erase parts of it.

Caching
                                block device access to MTD devices
                       
Although
most flash chips have an erase size too large to be useful
as
block devices, it is possible to use MTD devices which are based
on
RAM chips in this manner. This block device is a user of MTD
devices
performing that function.
At
the moment, it is also required for the Journalling Flash File
System(s)
to obtain a handle on the MTD device when it's mounted
(although
JFFS and JFFS2 don't actually use any of the functionality
of
the mtdblock device).
Later,
it may be extended to perform read/erase/modify/write cycles
on
flash chips to emulate a smaller block size. Needless to say,
this
is very unsafe, but could be useful for file systems which are
almost
never written to.
You
do not need this option for use with the DiskOnChip devices. For
those,
enable NFTL support (CONFIG_NFTL) instead.

Readonly
                                        block device access to MTD devices
                               
This
allows you to mount read-only file systems (such as cramfs)
from
an MTD device, without the overhead (and danger) of the caching
[color="#008080"]driver.
You
do not need this option for use with the DiskOnChip devices. For
those,
enable NFTL support (CONFIG_NFTL) instead.

FTL
                                (Flash Translation Layer) support
                               
                       
This
provides support for the original Flash Translation Layer which
is
part of the PCMCIA specification. It uses a kind of pseudo-
file
system on a flash device to emulate a block device with
512-byte
sectors, on top of which you put a 'normal' file system.
You
may find that the algorithms used in this code are patented
unless
you live in the Free World where software patents aren't
legal
- in the USA you are only permitted to use this on PCMCIA
hardware,
although under the terms of the GPL you're obviously
permitted
to copy, modify and distribute the code as you wish. Just
not
use it.

NFTL
                                (NAND Flash Translation Layer) support
                               
                       
This
provides support for the NAND Flash Translation Layer which is
used
on M-Systems' DiskOnChip devices. It uses a kind of pseudo-
file
system on a flash device to emulate a block device with
512-byte
sectors, on top of which you put a 'normal' file system.
You
may find that the algorithms used in this code are patented
unless
you live in the Free World where software patents aren't
legal
- in the USA you are only permitted to use this on DiskOnChip
hardware,
although under the terms of the GPL you're obviously
permitted
to copy, modify and distribute the code as you wish. Just
not
use it.

Write
                                        support for NFTL
                               
Support
for writing to the NAND Flash Translation Layer, as used
on
the DiskOnChip.

INFTL
                                (Inverse NAND Flash Translation Layer) support
                       
This
provides support for the Inverse NAND Flash Translation
Layer
which is used on M-Systems' newer DiskOnChip devices. It
uses
a kind of pseudo-file system on a flash device to emulate
a
block device with 512-byte sectors, on top of which you put
a
'normal' file system.
You
may find that the algorithms used in this code are patented
unless
you live in the Free World where software patents aren't
legal
- in the USA you are only permitted to use this on DiskOnChip
hardware,
although under the terms of the GPL you're obviously
permitted
to copy, modify and distribute the code as you wish. Just
not
use it.

Resident
                                Flash Disk (Flash Translation Layer) support
                               
                       
This
provides support for the flash translation layer known
as
the Resident Flash Disk (RFD), as used by the Embedded BIOS
of
General Software. There is a blurb at:
     
http://www.gensw.com/pages/prod/bios/rfd.htm

RAM/ROM/Flash
                                chip drivers
                               
                               

Detect
                                        flash chips by Common Flash Interface (CFI) probe
                               
                       
The
Common Flash Interface specification was developed by Intel,
AMD
and other flash manufactures that provides a universal method
for
probing the capabilities of flash devices. If you wish to
support
any device that is CFI-compliant, you need to enable this
option.
Visit
for
more information on CFI.

Detect
                                        non-CFI AMD/JEDEC-compatible flash chips
                                       
                               
This
option enables JEDEC-style probing of flash chips which are not
compatible
with the Common Flash Interface, but will use the common
CFI-targetted
flash drivers for any chips which are identified which
are
in fact compatible in all but the probe method. This actually
covers
most AMD/Fujitsu-compatible chips, and will shortly cover also
non-CFI
Intel chips (that code is in MTD CVS and should shortly be sent
for
inclusion in Linus' tree)

Flash
                                        chip driver advanced configuration options
                                       
                               
If
you need to specify a specific endianness for access to flash
chips,
or if you wish to reduce the size of the kernel by including
support
for only specific arrangements of flash chips, say 'Y'. This
option
does not directly affect the code, but will enable other
configuration
options which allow you to do so.
If
unsure, say 'N'.

Support
                                        for Intel/Sharp flash chips
                               
The
Common Flash Interface defines a number of different command
sets
which a CFI-compliant chip may claim to implement. This code
provides
support for one of those command sets, used on Intel
StrataFlash
and other parts.

Support
                                        for AMD/Fujitsu flash chips
                               
The
Common Flash Interface defines a number of different command
sets
which a CFI-compliant chip may claim to implement. This code
provides
support for one of those command sets, used on chips
including
the AMD Am29LV320.

Retry
                                                failed commands (erase/program)
                                       
Some
chips, when attached to a shared bus, don't properly filter
bus
traffic that is destined to other devices.  This broken
behavior
causes erase and program sequences to be aborted when
the
sequences are mixed with traffic for other devices.
SST49LF040
(and related) chips are know to be broken.

Support
                                        for ST (Advanced Architecture) flash chips
                                       
                               
The
Common Flash Interface defines a number of different command
sets
which a CFI-compliant chip may claim to implement. This code
provides
support for one of those command sets.

Support
                                        for RAM chips in bus mapping
                               
This
option enables basic support for RAM chips accessed through
a
bus mapping driver.

Support
                                        for ROM chips in bus mapping
                               
This
option enables basic support for ROM chips accessed through
a
bus mapping driver.

Support
                                        for absent chips in bus mapping
                               
This
option enables support for a dummy probing driver used to
allocated
placeholder MTD devices on systems that have socketed
or
removable media.  Use of this driver as a fallback chip probe
preserves
the expected registration order of MTD device nodes on
the
system regardless of media presence.  Device nodes created
with
this driver will return -ENODEV upon access.

Older
                                        (theoretically obsoleted now) drivers for non-CFI chips
                               
This
option does not enable any code directly, but will allow you to
select
some other chip drivers which are now considered obsolete,
because
the generic CONFIG_JEDECPROBE code above should now detect
the
chips which are supported by these drivers, and allow the generic
CFI-compatible
drivers to drive the chips. Say 'N' here unless you have
already
tried the CONFIG_JEDECPROBE method and reported its failure
to
the MTD mailing list at
[color="#008080"]linux-mtd@lists.infradead.org
[color="#008080"]>

Mapping
                                drivers for chip access
                               
                               

Support
                                        non-linear mappings of flash chips
                               
                       
This
causes the chip drivers to allow for complicated
paged
mappings of flash chips.

CFI
                                        Flash device in physical memory map
                                       
                               
This
provides a 'mapping' driver which allows the CFI probe and
command
set driver code to communicate with flash chips which
are
mapped physically into the CPU's memory. You will need to
configure
the physical address and size of the flash chips on
your
particular board as well as the bus width, either statically
with
config options or at run-time.

CFI
                                        Flash device mapped on Photron PNC-2000
                               
PNC-2000
is the name of Network Camera product from PHOTRON
Ltd.
in Japan. It uses CFI-compliant flash.

CFI
                                        Flash device mapped on AMD SC520 CDP
                               
The
SC520 CDP board has two banks of CFI-compliant chips and one
Dual-in-line
JEDEC chip. This 'mapping' driver supports that
arrangement,
implementing three MTD devices.

CFI
                                        Flash device mapped on AMD NetSc520
                                       
                               
This
enables access routines for the flash chips on the AMD NetSc520
demonstration
board. If you have one of these boards and would like
to
use the flash chips on it, say 'Y'.

JEDEC
                                        Flash device mapped on Technologic Systems TS-5500
                               
This
provides a driver for the on-board flash of the Technologic
System's
TS-5500 board. The 2MB flash is split into 3 partitions
which
are accessed as separate MTD devices.
mtd0
and mtd2 are the two BIOS drives, which use the resident
flash
disk (RFD) flash translation layer.
mtd1
allows you to reprogram your BIOS. BE VERY CAREFUL.
Note
that jumper 3 ("Write Enable Drive A") must be set
otherwise
detection won't succeeed.

CFI
                                        Flash device mapped on Arcom SBC-GXx boards
                               
This
provides a driver for the on-board flash of Arcom Control
Systems'
SBC-GXn family of boards, formerly known as SBC-MediaGX.
By
default the flash is split into 3 partitions which are accessed
as
separate MTD devices. This board utilizes Intel StrataFlash.
More
info at
[color="#008080"].

BIOS
                                        flash chip on AMD76x southbridge
                                       
                               
Support
for treating the BIOS flash chip on AMD76x motherboards
as
an MTD device - with this you can reprogram your BIOS.
BE
VERY CAREFUL.

BIOS
                                        flash chip on Intel Controller Hub 2/3/4/5
                               
Support
for treating the BIOS flash chip on ICHX motherboards
as
an MTD device - with this you can reprogram your BIOS.
BE
VERY CAREFUL.

BIOS
                                        flash chip on Intel SCB2 boards
                                       
                               
Support
for treating the BIOS flash chip on Intel SCB2 boards
as
an MTD device - with this you can reprogram your BIOS.
BE
VERY CAREFUL.

CFI
                                        flash device on SnapGear/SecureEdge
                               
Support
for flash chips on NETtel/SecureEdge/SnapGear boards.

CFI
                                        Flash device mapped on DIL/Net PC
                                       
                               
MTD
map driver for SSV DIL/Net PC Boards "DNP" and "ADNP".
For
details, see
and
[color="#008080"]http://www.ssv-embedded.de/ssv/pc104/p170.htm
[color="#008080"]>

BIOS
                                        flash chip on Intel L440GX boards
                                       
                               
Support
for treating the BIOS flash chip on Intel L440GX motherboards
as
an MTD device - with this you can reprogram your BIOS.
BE
VERY CAREFUL.

PCI
                                        MTD driver
                               
Mapping
for accessing flash devices on add-in cards like the Intel XScale
IQ80310
card, and the Intel EBSA285 card in blank ROM programming mode
(please
see the manual for the link settings).
If
you are not sure, say N.

Map
                                        driver for platform device RAM (mtd-ram)
                                       
                               
Map
driver for RAM areas described via the platform device
[color="#008080"]system.
This
selection automatically selects the map_ram driver.

Self-contained
                                MTD device drivers
                               

Ramix
                                        PMC551 PCI Mezzanine RAM card support
                               
                       
This
provides a MTD device driver for the Ramix PMC551 RAM PCI card
from
Ramix Inc. .
These
devices come in memory configurations from 32M - 1G.  If you
have
one, you probably want to enable this.
If
this driver is compiled as a module you get the ability to select
the
size of the aperture window pointing into the devices memory.
What
this means is that if you have a 1G card, normally the kernel
will
use a 1G memory map as its view of the device.  As a module,
you
can select a 1M window into the memory and the driver will
"slide"
the window around the PMC551's memory.  This was
particularly
useful on the 2.2 kernels on PPC architectures as there
was
limited kernel space to deal with.

PMC551
                                                256M DRAM Bugfix
                                               
                                       
Some
of Ramix's PMC551 boards with 256M configurations have invalid
column
and row mux values.  This option will fix them, but will
break
other memory configurations.  If unsure say N.

PMC551
                                                Debugging
                                       
This
option makes the PMC551 more verbose during its operation and
is
only really useful if you are developing on this driver or
suspect
a possible hardware or driver bug.  If unsure say N.

Uncached
                                        system RAM
                               
If
your CPU cannot cache all of the physical memory in your machine,
you
can still use it for storage or swap by using this driver to
present
it to the system as a Memory Technology Device.

Physical
                                        system RAM
                               
This
is a re-implementation of the slram driver above.
Use
this driver to access physical memory that the kernel proper
doesn't
have access to, memory beyond the mem=xxx limit, nvram,
memory
on the video card, etc...

Test
                                        driver using RAM
                               
This
enables a test MTD device driver which uses vmalloc() to
provide
storage.  You probably want to say 'N' unless you're
testing
stuff.

MTDRAM
                                                device size in KiB
                                       
This
allows you to configure the total size of the MTD device
emulated
by the MTDRAM driver.  If the MTDRAM driver is built
as
a module, it is also possible to specify this as a parameter when
loading
the module.

MTDRAM
                                                erase block size in KiB
                                       
This
allows you to configure the size of the erase blocks in the
device
emulated by the MTDRAM driver.  If the MTDRAM driver is built
as
a module, it is also possible to specify this as a parameter when
loading
the module.

MTD
                                        emulation using block device
                                       
                               
This
driver allows a block device to appear as an MTD. It would
generally
be used in the following cases:
Using
Compact Flash as an MTD, these usually present themselves to
the
system as an ATA drive.
Testing
MTD users (eg JFFS2) on large media and media that might
be
removed during a write (using the floppy drive).

MTD
                                        using block device (rewrite)
                                       
                               
This
driver is basically the same at MTD_BLKMTD above, but
experienced
some interface changes plus serious speedups.  In
the
long term, it should replace MTD_BLKMTD.  Right now, you
shouldn't
entrust important data to it yet.

Disk-On-Chip
                                        Device Drivers
                                       
                               

M-Systems
                                        Disk-On-Chip 2000 and Millennium (DEPRECATED)
                               
This
provides an MTD device driver for the M-Systems DiskOnChip
2000
and Millennium devices.  Originally designed for the DiskOnChip
2000,
it also now includes support for the DiskOnChip Millennium.
If
you have problems with this driver and the DiskOnChip Millennium,
you
may wish to try the alternative Millennium driver below. To use
the
alternative driver, you will need to undefine DOC_SINGLE_DRIVER
in
the  source code.
If
you use this device, you probably also want to enable the NFTL
'NAND
Flash Translation Layer' option below, which is used to
emulate
a block device by using a kind of file system on the flash
[color="#008080"]chips.
NOTE:
This driver is deprecated and will probably be removed soon.
Please
try the new DiskOnChip driver under "NAND Flash Device
[color="#008080"]Drivers".

M-Systems
                                        Disk-On-Chip Millennium-only alternative driver (DEPRECATED)
                               
This
provides an alternative MTD device driver for the M-Systems
DiskOnChip
Millennium devices.  Use this if you have problems with
the
combined DiskOnChip 2000 and Millennium driver above.  To get
the
DiskOnChip probe code to load and use this driver instead of
the
other one, you will need to undefine DOC_SINGLE_DRIVER near
the
beginning of .
If
you use this device, you probably also want to enable the NFTL
'NAND
Flash Translation Layer' option below, which is used to
emulate
a block device by using a kind of file system on the flash
[color="#008080"]chips.
NOTE:
This driver is deprecated and will probably be removed soon.
Please
try the new DiskOnChip driver under "NAND Flash Device
[color="#008080"]Drivers".

M-Systems
                                        Disk-On-Chip Millennium Plus
                               
This
provides an MTD device driver for the M-Systems DiskOnChip
Millennium
Plus devices.
If
you use this device, you probably also want to enable the INFTL
'Inverse
NAND Flash Translation Layer' option below, which is used
to
emulate a block device by using a kind of file system on the
flash
chips.
NOTE:
This driver will soon be replaced by the new DiskOnChip driver
under
"NAND Flash Device Drivers" (currently that driver does not
support
all Millennium Plus devices).

Advanced
                                        detection options for DiskOnChip
                               
This
option allows you to specify nonstandard address at which to
probe
for a DiskOnChip, or to change the detection options.  You
are
unlikely to need any of this unless you are using LinuxBIOS.
Say
'N'.

NAND
                                Flash Device Drivers
                               
                               

NAND
                                        Device Support
                                       
                               
                       
This
enables support for accessing all type of NAND flash
devices.
For further information see
[color="#008080"].

Verify
                                                NAND page writes
                                       
This
adds an extra check when data is written to the flash. The
NAND
flash device internally checks only bits transitioning
from
1 to 0. There is a rare possibility that even though the
device
thinks the write was successful, a bit could have been
flipped
accidentaly due to device wear or something else.

DiskOnChip
                                        2000, Millennium and Millennium Plus (NAND reimplementation)
                                        (EXPERIMENTAL)
                                       
                               
This
is a reimplementation of M-Systems DiskOnChip 2000,
Millennium
and Millennium Plus as a standard NAND device driver,
as
opposed to the earlier self-contained MTD device drivers.
This
should enable, among other things, proper JFFS2 operation on
these
devices.

Support
                                        for NAND Flash Simulator
                               

OneNAND
                                Flash Device Drivers
                               
                               

OneNAND
                                        Device Support
                                       
                               
                       
This
enables support for accessing all type of OneNAND flash
devices.
For further information see
[color="#008080"].

Parallel
                port support
               
               

Parallel
                        port support
                       
               
       
If
you want to use devices connected to your machine's parallel port
(the
connector at the computer with 25 holes), e.g. printer, ZIP
drive,
PLIP link (Parallel Line Internet Protocol is mainly used to
create
a mini network by connecting the parallel ports of two local
machines)
etc., then you need to say Y here; please read
and
[color="#008080"].
For
extensive information about drivers for many devices attaching
to
the parallel port see  on
the
WWW.
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.
To compile parallel port support as a module, choose M here:
the
module will be called parport.
If
you have more than one parallel port and want to specify which
port
and IRQ to be used by this driver at module load time, take a
look
at .
If
unsure, say Y.

PC-style
                                hardware
                               
                       
You
should say Y here if you have a PC-style parallel port. All
IBM
PC compatible computers and some Alphas have PC-style
parallel
ports.  PA-RISC owners should only say Y here if they
have
a SuperIO parallel port.
To
compile this driver as a module, choose M here: the
module
will be called parport_pc.
If
unsure, say Y.

Multi-IO
                                        cards (parallel and serial)
                               
This
adds support for multi-IO PCI cards that have parallel and
serial
ports.  You should say Y or M here.  If you say M, the module
will
be called parport_serial.

Use
                                        FIFO/DMA if available (EXPERIMENTAL)
                                       
                               
Many
parallel port chipsets provide hardware that can speed up
printing.
Say Y here if you want to take advantage of that.
As
well as actually having a FIFO, or DMA capability, the kernel
will
need to know which IRQ the parallel port has.  By default,
parallel
port interrupts will not be used, and so neither will the
FIFO.
See  to find out how to
specify
which IRQ/DMA to use.

SuperIO
                                        chipset support (EXPERIMENTAL)
                                       
                               
Saying
Y here enables some probes for Super-IO chipsets in order to
find
out things like base addresses, IRQ lines and DMA channels.  It
is
safe to say N.

Support
                                        for PCMCIA management for PC-style ports
                               
Say
Y here if you need PCMCIA support for your PC-style parallel
ports.
If unsure, say N.

IEEE
                        1284 transfer modes
               
If
you have a printer that supports status readback or device ID, or
want
to use a device that uses enhanced parallel port transfer modes
such
as EPP and ECP, say Y here to enable advanced IEEE 1284
transfer
modes. Also say Y if you want device ID information to
appear
in /proc/sys/dev/parport/*/autoprobe*. It is safe to say N.

Plug
                and Play support
               

Plug
                        and Play support PNP
               
       
Plug
and Play (PnP) is a standard for peripherals which allows those
peripherals
to be configured by software, e.g. assign IRQ's or other
parameters.
No jumpers on the cards are needed, instead the values
are
provided to the cards from the BIOS, from the operating system,
or
using a user-space utility.
Say
Y here if you would like Linux to configure your Plug and Play
devices.
You should then also say Y to all of the protocols below.
Alternatively,
you can say N here and configure your PnP devices
using
user space utilities such as the isapnptools package.
If
unsure, say Y.

PnP
                                Debug Messages
                       
Say
Y if you want the Plug and Play Layer to print debug messages.
This
is useful if you are developing a PnP driver or troubleshooting.

Protocols
                               
                               
                               

ISA
                                        Plug and Play support
                               
                       
Say
Y here if you would like support for ISA Plug and Play devices.
Some
information is in .
If
unsure, say Y.

Plug
                                        and Play BIOS support (EXPERIMENTAL)
                                       
                               
Linux
uses the PNPBIOS as defined in "Plug and Play BIOS
Specification
Version 1.0A May 5, 1994" to autodetect built-in
mainboard
resources (e.g. parallel port resources).
Some
features (e.g. event notification, docking station information,
ISAPNP
services) are not currently implemented.
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 Y here.  Also the PNPBIOS can help prevent resource
conflicts
between mainboard devices and other bus devices.
Note:
ACPI is expected to supersede PNPBIOS some day, currently it
co-exists
nicely.  If you have a non-ISA system that supports ACPI,
you
probably don't need PNPBIOS support.

Plug
                                                and Play BIOS /proc interface
                                       
If
you say Y here and to "/proc file system support", you will
be
able
to directly access the PNPBIOS.  This includes resource
allocation,
ESCD, and other PNPBIOS services.  Using this
interface
is potentially dangerous because the PNPBIOS driver will
not
be notified of any resource changes made by writing directly.
Also
some buggy systems will fault when accessing certain features
in
the PNPBIOS /proc interface (e.g. "boot" configs).
See
the latest pcmcia-cs (stand-alone package) for a nice set of
PNPBIOS
/proc interface tools (lspnp and setpnp).
Unless
you are debugging or have other specific reasons, it is
recommended
that you say N here.

Plug
                                        and Play ACPI support (EXPERIMENTAL)
                               
Linux
uses the PNPACPI to autodetect built-in
mainboard
resources (e.g. parallel port resources).
Some
features (e.g. real hotplug) are not currently
[color="#008080"]implemented.
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 Y here.  Also the PNPACPI can help prevent resource
conflicts
between mainboard devices and other bus devices.

Block
                devices
               
               

Normal
                        floppy disk support
               
       
If
you want to use the floppy disk drive(s) of your PC under Linux,
say
Y. Information about this driver, especially important for IBM
Thinkpad
users, is contained in .
That
file also contains the location of the Floppy driver FAQ as
well
as location of the fdutils package used to configure additional
parameters
of the driver at run time.
To
compile this driver as a module, choose M here: the
module
will be called floppy.

XT
                        hard disk support
               
Very
old 8 bit hard disk controllers used in the IBM XT computer
will
be supported if you say Y here.
To
compile this driver as a module, choose M here: the
module
will be called xd.
It's
pretty unlikely that you have one of these: say N.

Parallel
                        port IDE device support
               
There
are many external CD-ROM and disk devices that connect through
your
computer's parallel port. Most of them are actually IDE devices
using
a parallel port IDE adapter. This option enables the PARIDE
subsystem
which contains drivers for many of these external drives.
Read
for more information.
If
you have said Y to the "Parallel-port support"
configuration
option,
you may share a single port between your printer and other
parallel
port devices. Answer Y to build PARIDE support into your
kernel,
or M if you would like to build it as a loadable module. If
your
parallel port support is in a loadable module, you must build
PARIDE
as a module. If you built PARIDE support into your kernel,
you
may still build the individual protocol modules and high-level
drivers
as loadable modules. If you build this support as a module,
it
will be called paride.
To
use the PARIDE support, you must say Y or M here and also to at
least
one high-level driver (e.g. "Parallel port IDE disks",
"Parallel
port ATAPI CD-ROMs", "Parallel port ATAPI disks" etc.)
and
to
at least one protocol driver (e.g. "ATEN EH-100 protocol",
"MicroSolutions
backpack protocol", "DataStor Commuter protocol"
[color="#008080"]etc.).

Compaq
                        SMART2 support
                       
               
This
is the driver for Compaq Smart Array controllers.  Everyone
using
these boards should say Y here.  See the file
for the current list of boards
supported
by this driver, and for further information on the use of
this
driver.

Compaq
                        Smart Array 5xxx support
               
This
is the driver for Compaq Smart Array 5xxx controllers.
Everyone
using these boards should say Y here.
See
for the current list of
boards
supported by this driver, and for further information
on
the use of this driver.

SCSI
                                tape drive support for Smart Array 5xxx
                       
When
enabled (Y), this option allows SCSI tape drives and SCSI medium
changers
(tape robots) to be accessed via a Compaq 5xxx array
controller.
(See  for more details.)
"SCSI
support" and "SCSI tape support" must also be enabled
for this
option
to work.
When
this option is disabled (N), the SCSI portion of the driver
is
not compiled.

Mylex
                        DAC960/DAC1100 PCI RAID Controller support
               
This
driver adds support for the Mylex DAC960, AcceleRAID, and
eXtremeRAID
PCI RAID controllers.  See the file
for further information about
this
driver.
To
compile this driver as a module, choose M here: the
module
will be called DAC960.

Micro
                        Memory MM5415 Battery Backed RAM support (EXPERIMENTAL)
               
Saying
Y here will include support for the MM5415 family of
battery
backed (Non-volatile) RAM cards.
[color="#008080"]
The
cards appear as block devices that can be partitioned into
as
many as 15 partitions.
To
compile this driver as a module, choose M here: the
module
will be called umem.
The
umem driver has not yet been allocated a MAJOR number, so
one
is chosen dynamically.  Use "devfs" or look in
/proc/devices
for
the device number

Loopback
                        device support
                       
               
Saying
Y here will allow you to use a regular file as a block
device;
you can then create a file system on that block device and
mount
it just as you would mount other block devices such as hard
drive
partitions, CD-ROM drives or floppy drives. The loop devices
are
block special device files with major number 7 and typically
called
/dev/loop0, /dev/loop1 etc.
This
is useful if you want to check an ISO 9660 file system before
burning
the CD, or if you want to use floppy images without first
writing
them to floppy. Furthermore, some Linux distributions avoid
the
need for a dedicated Linux partition by keeping their complete
root
file system inside a DOS FAT file using this loop device
[color="#008080"]driver.
To
use the loop device, you need the losetup utility, found in the
util-linux
package, see
[color="#008080"].
The
loop device driver can also be used to "hide" a file system
in
a
disk partition, floppy, or regular file, either using encryption
(scrambling
the data) or steganography (hiding the data in the low
bits
of, say, a sound file). This is also safe if the file resides
on
a remote file server.
There
are several ways of encrypting disks. Some of these require
kernel
patches. The vanilla kernel offers the cryptoloop option
and
a Device Mapper target (which is superior, as it supports all
file
systems). If you want to use the cryptoloop, say Y to both
LOOP
and CRYPTOLOOP, and make sure you have a recent (version 2.12
or
later) version of util-linux. Additionally, be aware that
the
cryptoloop is not safe for storing journaled filesystems.
Note
that this loop device has nothing to do with the loopback
device
used for network connections from the machine to itself.
To
compile this driver as a module, choose M here: the
module
will be called loop.
Most
users will answer N here.

Cryptoloop
                                Support
                       
Say
Y here if you want to be able to use the ciphers that are
provided
by the CryptoAPI as loop transformation. This might be
used
as hard disk encryption.
WARNING:
This device is not safe for journaled file systems like
ext3
or Reiserfs. Please use the Device Mapper crypto module
instead,
which can be configured to be on-disk compatible with the
cryptoloop
device.

Network
                        block device support
               
Saying
Y here will allow your computer to be a client for network
block
devices, i.e. it will be able to use block devices exported by
servers
(mount file systems on them etc.). Communication between
client
and server works over TCP/IP networking, but to the client
program
this is hidden: it looks like a regular local file access to
a
block device special file such as /dev/nd0.
Network
block devices also allows you to run a block-device in
userland
(making server and client physically the same computer,
communicating
using the loopback network device).
Read
for more information, especially
about
where to find the server code, which runs in user space and
does
not need special kernel support.
Note
that this has nothing to do with the network file systems NFS
or
Coda; you can say N here even if you intend to use NFS or Coda.
To
compile this driver as a module, choose M here: the
module
will be called nbd.
If
unsure, say N.

Promise
                        SATA SX8 support
               
Saying
Y or M here will enable support for the
Promise
SATA SX8 controllers.
Use
devices /dev/sx8/$N and /dev/sx8/$Np$M.

Low
                        Performance USB Block driver
               
This
driver supports certain USB attached storage devices
such
as flash keys.
If
you enable this driver, it is recommended to avoid conflicts
with
usb-storage by enabling USB_LIBUSUAL.
If
unsure, say N.

RAM
                        disk support
               
Saying
Y here will allow you to use a portion of your RAM memory as
a
block device, so that you can make file systems on it, read and
write
to it and do all the other things that you can do with normal
block
devices (such as hard drives). It is usually used to load and
store
a copy of a minimal root file system off of a floppy into RAM
during
the initial install of Linux.
Note
that the kernel command line option "ramdisk=XX" is now
obsolete.
For details, read .
To
compile this driver as a module, choose M here: the
module
will be called rd.
Most
normal users won't need the RAM disk functionality, and can
thus
say N here.

Default
                                number of RAM disks
                       
The
default value is 16 RAM disks. Change this if you know what
are
doing. If you boot from a filesystem that needs to be extracted
in
memory, you will need at least one RAM disk (e.g. root on cramfs).

Default
                                RAM disk size (kbytes)
                       
The
default value is 4096 kilobytes. Only change this if you know
what
are you doing. If you are using IBM S/390, then set this to
[color="#008080"]8192.

Initial
                                RAM disk (initrd) support
                               
                       
The
initial RAM disk is a RAM disk that is loaded by the boot loader
(loadlin
or lilo) and that is mounted as root before the normal boot
procedure.
It is typically used to load modules needed to mount the
"real"
root file system, etc. See
for
details.

Packet
                        writing on CD/DVD media
               
If
you have a CDROM drive that supports packet writing, say Y to
include
preliminary support. It should work with any MMC/Mt Fuji
compliant
ATAPI or SCSI drive, which is just about any newer CD
[color="#008080"]writer.
Currently
only writing to CD-RW, DVD-RW and DVD+RW discs is possible.
DVD-RW
disks must be in restricted overwrite mode.
To
compile this driver as a module, choose M here: the
module
will be called pktcdvd.

Free
                                buffers for data gathering
                               
                       
This
controls the maximum number of active concurrent packets. More
concurrent
packets can increase write performance, but also require
more
memory. Each concurrent packet will require approximately 64Kb
of
non-swappable kernel memory, memory which will be allocated when
a
disc is opened for writing.

Enable
                                write caching (EXPERIMENTAL)
                       
If
enabled, write caching will be set for the CD-R/W device. For now
this
option is dangerous unless the CD-RW media is known good, as we
don't
do deferred write error handling yet.

ATA
                        over Ethernet support
               
This
driver provides Support for ATA over Ethernet block
devices
like the Coraid EtherDrive (R) Storage Blade.

ATA/ATAPI/MFM/RLL
                support
               
               

ATA/ATAPI/MFM/RLL
                        support
               
       
If
you say Y here, your kernel will be able to manage low cost mass
storage
units such as ATA/(E)IDE and ATAPI units. The most common
cases
are IDE hard drives and ATAPI CD-ROM drives.
If
your system is pure SCSI and doesn't use these interfaces, you
can
say N here.
Integrated
Disk Electronics (IDE aka ATA-1) is a connecting standard
for
mass storage units such as hard disks. It was designed by
Western
Digital and Compaq Computer in 1984. It was then named
ST506.
Quite a number of disks use the IDE interface.
AT
Attachment (ATA) is the superset of the IDE specifications.
ST506
was also called ATA-1.
Fast-IDE
is ATA-2 (also named Fast ATA), Enhanced IDE (EIDE) is
ATA-3.
It provides support for larger disks (up to 8.4GB by means of
the
LBA standard), more disks (4 instead of 2) and for other mass
storage
units such as tapes and cdrom. UDMA/33 (aka UltraDMA/33) is
ATA-4
and provides faster (and more CPU friendly) transfer modes
than
previous PIO (Programmed processor Input/Output) from previous
ATA/IDE
standards by means of fast DMA controllers.
ATA
Packet Interface (ATAPI) is a protocol used by EIDE tape and
CD-ROM
drives, similar in many respects to the SCSI protocol.
SMART
IDE (Self Monitoring, Analysis and Reporting Technology) was
designed
in order to prevent data corruption and disk crash by
detecting
pre hardware failure conditions (heat, access time, and
the
like...). Disks built since June 1995 may follow this standard.
The
kernel itself doesn't manage this; however there are quite a
number
of user programs such as smart that can query the status of
SMART
parameters from disk drives.
To
compile this driver as a module, choose M here: the
module
will be called ide.
For
further information, please read .
If
unsure, say Y.

Enhanced
                                IDE/MFM/RLL disk/cdrom/tape/floppy support
                       
If
you say Y here, you will use the full-featured IDE driver to
control
up to ten ATA/IDE interfaces, each being able to serve a
"master"
and a "slave" device, for a total of up to twenty ATA/IDE
disk/cdrom/tape/floppy
drives.
Useful
information about large (>540 MB) IDE disks, multiple
interfaces,
what to do if ATA/IDE devices are not automatically
detected,
sound card ATA/IDE ports, module support, and other
topics,
is contained in . For detailed
information
about hard drives, consult the Disk-HOWTO and the
Multi-Disk-HOWTO,
available from
[color="#008080"].
To
fine-tune ATA/IDE drive/interface parameters for improved
performance,
look for the hdparm package at
[color="#008080"].
To
compile this driver as a module, choose M here and read
.
The module will be called ide-mod.
Do
not compile this driver as a module if your root file system (the
one
containing the directory /) is located on an IDE device.
If
you have one or more IDE drives, say Y or M here. If your system
has
no IDE drives, or if memory requirements are really tight, you
could
say N here, and select the "Old hard disk driver" below
instead
to save about 13 KB of memory in the kernel.

Please
                                        see Documentation/ide.txt for help/info on IDE drives
                                       
                               

Support
                                        for SATA (deprecated; conflicts with libata SATA driver)
                               
There
are two drivers for Serial ATA controllers.
The
main driver, "libata", exists inside the SCSI subsystem
and
supports most modern SATA controllers.
The
IDE driver (which you are currently configuring) supports
a
few first-generation SATA controllers.
In
order to eliminate conflicts between the two subsystems,
this
config option enables the IDE driver's SATA support.
Normally
this is disabled, as it is preferred that libata
supports
SATA controllers, and this (IDE) driver supports
PATA
controllers.
If
unsure, say N.

Use
                                        old disk-only driver on primary interface
                               
There
are two drivers for MFM/RLL/IDE disks.  Most people use just
the
new enhanced driver by itself.  This option however installs the
old
hard disk driver to control the primary IDE/disk interface in
the
system, leaving the new enhanced IDE driver to take care of only
the
2nd/3rd/4th IDE interfaces.  Doing this will prevent you from
having
an IDE/ATAPI CD-ROM or tape drive connected to the primary
IDE
interface.  Choosing this option may be useful for older systems
which
have MFM/RLL/ESDI controller+drives at the primary port
address
(0x1f0), along with IDE drives at the secondary/3rd/4th port
[color="#008080"]addresses.
Normally,
just say N here; you will then use the new driver for all
4
interfaces.

Include
                                        IDE/ATA-2 DISK support
                               
This
will include enhanced support for MFM/RLL/IDE hard disks.  If
you
have a MFM/RLL/IDE disk, and there is no special reason to use
the
old hard disk driver instead, say Y.  If you have an SCSI-only
system,
you can say N here.
To
compile this driver as a module, choose M here: the
module
will be called ide-disk.
Do
not compile this driver as a module if your root file system
(the
one containing the directory /) is located on the IDE disk.
If
unsure, say Y.

Use
                                        multi-mode by default
                               
If
you get this error, try to say Y here:
hda:
set_multmode: status=0x51 { DriveReady SeekComplete Error }
hda:
set_multmode: error=0x04 { DriveStatusError }
If
in doubt, say N.

PCMCIA
                                        IDE support
                               
Support
for Compact Flash cards, outboard IDE disks, tape drives,
and
CD-ROM drives connected through a PCMCIA card.

Include
                                        IDE/ATAPI CDROM support
                               
If
you have a CD-ROM drive using the ATAPI protocol, say Y. ATAPI is
a
newer protocol used by IDE CD-ROM and TAPE drives, similar to the
SCSI
protocol. Most new CD-ROM drives use ATAPI, including the
NEC-260,
Mitsumi FX400, Sony 55E, and just about all non-SCSI
double(2X)
or better speed drives.
If
you say Y here, the CD-ROM drive will be identified at boot time
along
with other IDE devices, as "hdb" or "hdc", or
something
similar
(check the boot messages with dmesg). If this is your only
CD-ROM
drive, you can say N to all other CD-ROM options, but be sure
to
say Y or M to "ISO 9660 CD-ROM file system support".
Note
that older versions of LILO (LInux LOader) cannot properly deal
with
IDE/ATAPI CD-ROMs, so install LILO 16 or higher, available from
[color="#008080"].
To
compile this driver as a module, choose M here: the
module
will be called ide-cd.

Include
                                        IDE/ATAPI TAPE support (EXPERIMENTAL)
                               
If
you have an IDE tape drive using the ATAPI protocol, say Y.
ATAPI
is a newer protocol used by IDE tape and CD-ROM drives,
similar
to the SCSI protocol.  If you have an SCSI tape drive
however,
you can say N here.
You
should also say Y if you have an OnStream DI-30 tape drive; this
will
not work with the SCSI protocol, until there is support for the
SC-30
and SC-50 versions.
If
you say Y here, the tape drive will be identified at boot time
along
with other IDE devices, as "hdb" or "hdc", or
something
similar,
and will be mapped to a character device such as "ht0"
(check
the boot messages with dmesg).  Be sure to consult the
and  files
for
usage information.
To
compile this driver as a module, choose M here: the
module
will be called ide-tape.

Include
                                        IDE/ATAPI FLOPPY support
                                       
                               
If
you have an IDE floppy drive which uses the ATAPI protocol,
answer
Y.  ATAPI is a newer protocol used by IDE CD-ROM/tape/floppy
drives,
similar to the SCSI protocol.
The
LS-120 and the IDE/ATAPI Iomega ZIP drive are also supported by
this
driver. For information about jumper settings and the question
of
when a ZIP drive uses a partition table, see
[color="#008080"].
(ATAPI
PD-CD/CDR drives are not supported by this driver; support
for
PD-CD/CDR drives is available if you answer Y to
"SCSI
emulation support", below).
If
you say Y here, the FLOPPY drive will be identified along with
other
IDE devices, as "hdb" or "hdc", or something
similar (check
the
boot messages with dmesg).
To
compile this driver as a module, choose M here: the
module
will be called ide-floppy.

SCSI
                                        emulation support
                               
WARNING:
ide-scsi is no longer needed for cd writing applications!
The
2.6 kernel supports direct writing to ide-cd, which eliminates
the
need for ide-scsi + the entire scsi stack just for writing a
cd.
The new method is more efficient in every way.
This
will provide SCSI host adapter emulation for IDE ATAPI devices,
and
will allow you to use a SCSI device driver instead of a native
ATAPI
driver.
This
is useful if you have an ATAPI device for which no native
driver
has been written (for example, an ATAPI PD-CD drive);
you
can then use this emulation together with an appropriate SCSI
device
driver. In order to do this, say Y here and to "SCSI support"
and
"SCSI generic support", below. You must then provide the
kernel
command
line "hdx=ide-scsi" (try "man bootparam" or see
the
documentation
of your boot loader (lilo or loadlin) about how to
pass
options to the kernel at boot time) for devices if you want the
native
EIDE sub-drivers to skip over the native support, so that
this
SCSI emulation can be used instead.
Note
that this option does NOT allow you to attach SCSI devices to a
box
that doesn't have a SCSI host adapter installed.
If
both this SCSI emulation and native ATAPI support are compiled
into
the kernel, the native support will be used.

IDE
                                        Taskfile Access
                                       
                               
This
is a direct raw access to the media.  It is a complex but
elegant
solution to test and validate the domain of the hardware and
perform
below the driver data recovery if needed.  This is the most
basic
form of media-forensics.
If
you are unsure, say N here.

IDE
                                        chipset support/bugfixes
                                       
                               

generic/default
                                        IDE chipset support
                               
If
unsure, say Y.

CMD640
                                        chipset bugfix/support
                               
The
CMD-Technologies CMD640 IDE chip is used on many common 486 and
Pentium
motherboards, usually in combination with a "Neptune" or
"SiS"
chipset. Unfortunately, it has a number of rather nasty
design
flaws that can cause severe data corruption under many common
conditions.
Say Y here to include code which tries to automatically
detect
and correct the problems under Linux. This option also
enables
access to the secondary IDE ports in some CMD640 based
[color="#008080"]systems.
This
driver will work automatically in PCI based systems (most new
systems
have PCI slots). But if your system uses VESA local bus
(VLB)
instead of PCI, you must also supply a kernel boot parameter
to
enable the CMD640 bugfix/support: "ide0=cmd640_vlb". (Try
"man
bootparam"
or see the documentation of your boot loader about how to
pass
options to the kernel.)
The
CMD640 chip is also used on add-in cards by Acculogic, and on
the
"CSA-6400E PCI to IDE controller" that some people have.
For
details,
read .

CMD640
                                                enhanced support
                                               
                                       
This
option includes support for setting/autotuning PIO modes and
prefetch
on CMD640 IDE interfaces.  For details, read
.
If you have a CMD640 IDE interface
and
your BIOS does not already do this for you, then say Y here.
Otherwise
say N.

PNP
                                        EIDE support
                                       
                               
If
you have a PnP (Plug and Play) compatible EIDE card and
would
like the kernel to automatically detect and activate
it,
say Y here.

PCI
                                        IDE chipset support
                                       
                               
Say
Y here for PCI systems which use IDE drive(s).
This
option helps the IDE driver to automatically detect and
configure
all PCI-based IDE interfaces in your system.

Sharing
                                                PCI IDE interrupts support
                                       
Some
ATA/IDE chipsets have hardware support which allows for
sharing
a single IRQ with other cards. To enable support for
this
in the ATA/IDE driver, say Y here.
It
is safe to say Y to this question, in most cases.
If
unsure, say N.

Boot
                                                off-board chipsets first support
                                       
Normally,
IDE controllers built into the motherboard (on-board
controllers)
are assigned to ide0 and ide1 while those on add-in PCI
cards
(off-board controllers) are relegated to ide2 and ide3.
Answering
Y here will allow you to reverse the situation, with
off-board
controllers on ide0/1 and on-board controllers on ide2/3.
This
can improve the usability of some boot managers such as lilo
when
booting from a drive on an off-board controller.
If
you say Y here, and you actually want to reverse the device scan
order
as explained above, you also need to issue the kernel command
line
option "ide=reverse". (Try "man bootparam" or see
the
documentation
of your boot loader (lilo or loadlin) about how to
pass
options to the kernel at boot time.)
Note
that, if you do this, the order of the hd* devices will be
rearranged
which may require modification of fstab and other files.
If
in doubt, say N.

Generic
                                                PCI IDE Chipset Support
                                               
                                       
Sorry,
no help available for this option yet.

OPTi
                                                82C621 chipset enhanced support (EXPERIMENTAL)
                                       
This
is a driver for the OPTi 82C621 EIDE controller.
Please
read the comments at the top of .

RZ1000
                                                chipset bugfix/support
                                       
The
PC-Technologies RZ1000 IDE chip is used on many common 486 and
Pentium
motherboards, usually along with the "Neptune" chipset.
Unfortunately,
it has a rather nasty design flaw that can cause
severe
data corruption under many conditions. Say Y here to include
code
which automatically detects and corrects the problem under
Linux.
This may slow disk throughput by a few percent, but at least
things
will operate 100% reliably.

Generic
                                                PCI bus-master DMA support
                                               
                                       
If
your PCI system uses IDE drive(s) (as opposed to SCSI, say) and
is
capable of bus-master DMA operation (most Pentium PCI systems),
you
will want to say Y here to reduce CPU overhead. You can then use
the
"hdparm" utility to enable DMA for drives for which it was
not
enabled
automatically. By default, DMA is not enabled automatically
for
these drives, but you can change that by saying Y to the
following
question "Use DMA by default when available". You can get
the
latest version of the hdparm utility from
[color="#008080"].
Read
the comments at the beginning of
and
the file  for more information.
It
is safe to say Y to this question.

Other
                                        IDE chipset support
                               
Say
Y here if you want to include enhanced support for various IDE
interface
chipsets used on motherboards and add-on cards. You can
then
pick your particular IDE chip from among the following options.
This
enhanced support may be necessary for Linux to be able to
access
the 3rd/4th drives in some systems. It may also enable
setting
of higher speed I/O rates to improve system performance with
these
chipsets. Most of these also require special kernel boot
parameters
to actually turn on the support at runtime; you can find
a
list of these in the file .
People
with SCSI-only systems can say N here.

IGNORE
                                        word93 Validation BITS
                               
There
are unclear terms in ATA-4 and ATA-5 standards how certain
hardware
(an 80c ribbon) should be detected. Different interpretations
of
the standards have been released in hardware. This causes problems:
for
example, a host with Ultra Mode 4 (or higher) will not run
in
that mode with an 80c ribbon.
If
you are experiencing compatibility or performance problems, you
MAY
try to answer Y here. However, it does not necessarily solve
any
of your problems, it could even cause more of them.
It
is normally safe to answer Y; however, the default is N.

SCSI
                device support
               
               

RAID
                        Transport Class
                       

SCSI
                        device support
                       
               
       
If
you want to use a SCSI hard disk, SCSI tape drive, SCSI CD-ROM or
any
other SCSI device under Linux, say Y and make sure that you know
the
name of your SCSI host adapter (the card inside your computer
that
"speaks" the SCSI protocol, also called SCSI controller),
because
you will be asked for it.
You
also need to say Y here if you have a device which speaks
the
SCSI protocol.  Examples of this include the parallel port
version
of the IOMEGA ZIP drive, USB storage devices, Fibre
Channel,
FireWire storage and the IDE-SCSI emulation driver.
To
compile this driver as a module, choose M here and read
[color="#008080"].
The
module will be called scsi_mod.
However,
do not compile this as a module if your root file system
(the
one containing the directory /) is located on a SCSI device.

legacy
                                /proc/scsi/ support
                       
This
option enables support for the various files in
/proc/scsi.
In Linux 2.6 this has been superceeded by
files
in sysfs but many legacy applications rely on this.
If
unusure say Y.

SCSI
                                disk support
                       
If
you want to use SCSI hard disks, Fibre Channel disks,
USB
storage or the SCSI or parallel port version of
the
IOMEGA ZIP drive, say Y and read the SCSI-HOWTO,
the
Disk-HOWTO and the Multi-Disk-HOWTO, available from
.
This is NOT for SCSI
[color="#008080"]CD-ROMs.
To
compile this driver as a module, choose M here and read
[color="#008080"].
The
module will be called sd_mod.
Do
not compile this driver as a module if your root file system
(the
one containing the directory /) is located on a SCSI disk.
In
this case, do not compile the driver for your SCSI host adapter
(below)
as a module either.

SCSI
                                tape support
                       
If
you want to use a SCSI tape drive under Linux, say Y and read the
SCSI-HOWTO,
available from
,
and
in the kernel source.  This is NOT
for
SCSI CD-ROMs.
To
compile this driver as a module, choose M here and read
.
The module will be called st.

SCSI
                                OnStream SC-x0 tape support
                       
The
OnStream SC-x0 SCSI tape drives can not be driven by the
standard
st driver, but instead need this special osst driver and
use
the  /dev/osstX char device nodes (major 206).  Via usb-storage
and
ide-scsi, you may be able to drive the USB-x0 and DI-x0 drives
as
well.  Note that there is also a second generation of OnStream
tape
drives (ADR-x0) that supports the standard SCSI-2 commands for
tapes
(QIC-157) and can be driven by the standard driver st.
For
more information, you may have a look at the SCSI-HOWTO
and
in the kernel source.
More
info on the OnStream driver may be found on
[color="#008080"]
Please
also have a look at the standard st docu, as most of it
applies
to osst as well.
To
compile this driver as a module, choose M here and read
.
The module will be called osst.

SCSI
                                CDROM support
                       
If
you want to use a SCSI or FireWire CD-ROM under Linux,
say
Y and read the SCSI-HOWTO and the CDROM-HOWTO at
.
Also make sure to say
Y
or M to "ISO 9660 CD-ROM file system support" later.
To
compile this driver as a module, choose M here and read
[color="#008080"].
The
module will be called sr_mod.

SCSI
                                generic support
                       
If
you want to use SCSI scanners, synthesizers or CD-writers or just
about
anything having "SCSI" in its name other than hard disks,
CD-ROMs
or tapes, say Y here. These won't be supported by the kernel
directly,
so you need some additional software which knows how to
talk
to these devices using the SCSI protocol:
For
scanners, look at SANE (). For CD
writer
software look at Cdrtools
[color="#008080"]()
and
for burning a "disk at once": CDRDAO
().
Cdparanoia is a high
quality
digital reader of audio CDs ().
For
other devices, it's possible that you'll have to write the
driver
software yourself. Please read the file
for more information.
To
compile this driver as a module, choose M here and read
.
The module will be called sg.
If
unsure, say N.

SCSI
                                media changer support
                       
This
is a driver for SCSI media changers.  Most common devices are
tape
libraries and MOD/CDROM jukeboxes.  *Real* jukeboxes, you
don't
need this for those tiny 6-slot cdrom changers.  Media
changers
are listed as "Type: Medium Changer" in /proc/scsi/scsi.
If
you have such hardware and want to use it with linux, say Y
here.
Check  for details.
If
you want to compile this as a module ( = code which can be
inserted
in and removed from the running kernel whenever you want),
say
M here and read  and
.
The module will be called ch.o.
If
unsure, say N.

Probe
                                all LUNs on each SCSI device
                       
If
you have a SCSI device that supports more than one LUN (Logical
Unit
Number), e.g. a CD jukebox, and only one LUN is detected, you
can
say Y 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 N here. The max_luns boot/module parameter
allows
to override this setting.

Verbose
                                SCSI error reporting (kernel size +=12K)
                       
The
error messages regarding your SCSI hardware will be easier to
understand
if you say Y here; it will enlarge your kernel by about
12
KB. If in doubt, say Y.

SCSI
                                logging facility
                               
                       
This
turns on a logging facility that can be used to debug a number
of
SCSI related problems.
If
you say Y here, no logging output will appear by default, but you
can
enable logging by saying Y to "/proc file system support"
and
"Sysctl
support" below and executing the command
echo
"scsi log token [level]" > /proc/scsi/scsi
at
boot time after the /proc file system has been mounted.
There
are a number of things that can be used for 'token' (you can
find
them in the source: ), and this
allows
you to select the types of information you want, and the
level
allows you to select the level of verbosity.
If
you say N here, it may be harder to track down some types of SCSI
problems.
If you say Y here your kernel will be somewhat larger, but
there
should be no noticeable performance impact as long as you have
logging
turned off.

SCSI
                                Transport Attributes
                               
                               

Parallel
                                        SCSI (SPI) Transport Attributes
                                       
                               
                       
If
you wish to export transport-specific information about
each
attached SCSI device to sysfs, say Y.  Otherwise, say N.

FiberChannel
                                        Transport Attributes
                               
If
you wish to export transport-specific information about
each
attached FiberChannel device to sysfs, say Y.
Otherwise,
say N.

iSCSI
                                        Transport Attributes
                                       
                               
If
you wish to export transport-specific information about
each
attached iSCSI device to sysfs, say Y.
Otherwise,
say N.

SAS
                                        Transport Attributes
                               
If
you wish to export transport-specific information about
each
attached SAS device to sysfs, say Y.

SCSI
                                low-level drivers
                               
                               

PCMCIA
                                SCSI adapter support
                       

Old
                CD-ROM drivers (not SCSI, not IDE)
               
               

Support
                        non-SCSI/IDE/ATAPI CDROM drives
               
       
If
you have a CD-ROM drive that is neither SCSI nor IDE/ATAPI, say Y
here,
otherwise N. Read the CD-ROM-HOWTO, available from
[color="#008080"].
Note
that the answer to this question doesn't directly affect the
kernel:
saying N will just cause the configurator to skip all
the
questions about these CD-ROM drives. If you are unsure what you
have,
say Y and find out whether you have one of the following
[color="#008080"]drives.
For
each of these drivers, a
exists.
Especially in cases where you do not know exactly which kind
of
drive you have you should read there. Most of these drivers use a
file
drivers/cdrom/{driver_name}.h where you can define your
interface
parameters and switch some internal goodies.
To
compile these CD-ROM drivers as a module, choose M instead of Y.
If
you want to use any of these CD-ROM drivers, you also have to
answer
Y or M to "ISO 9660 CD-ROM file system support" below (this
answer
will get "defaulted" for you if you enable any of the Linux
CD-ROM
drivers).

Multi-device
                support (RAID and LVM)
               
               

Multiple
                        devices driver support (RAID and LVM)
               
       
Support
multiple physical spindles through a single logical device.
Required
for RAID and logical volume management.

RAID
                                support
                               
                       
This
driver lets you combine several hard disk partitions into one
logical
block device. This can be used to simply append one
partition
to another one or to combine several redundant hard disks
into
a RAID1/4/5 device so as to provide protection against hard
disk
failures. This is called "Software RAID" since the
combining of
the
partitions is done by the kernel. "Hardware RAID" means
that the
combining
is done by a dedicated controller; if you have such a
controller,
you do not need to say Y here.
More
information about Software RAID on Linux is contained in the
Software
RAID mini-HOWTO, available from
.
There you will also learn
where
to get the supporting user space utilities raidtools.
If
unsure, say N.

Linear
                                        (append) mode
                               
If
you say Y here, then your multiple devices driver will be able to
use
the so-called linear mode, i.e. it will combine the hard disk
partitions
by simply appending one to the other.
To
compile this as a module, choose M here: the module
will
be called linear.
If
unsure, say Y.

RAID-0
                                        (striping) mode
                               
If
you say Y here, then your multiple devices driver will be able to
use
the so-called raid0 mode, i.e. it will combine the hard disk
partitions
into one logical device in such a fashion as to fill them
up
evenly, one chunk here and one chunk there. This will increase
the
throughput rate if the partitions reside on distinct disks.
Information
about Software RAID on Linux is contained in the
Software-RAID
mini-HOWTO, available from
.
There you will also
learn
where to get the supporting user space utilities raidtools.
To
compile this as a module, choose M here: the module
will
be called raid0.
If
unsure, say Y.

RAID-1
                                        (mirroring) mode
                               
A
RAID-1 set consists of several disk drives which are exact copies
of
each other.  In the event of a mirror failure, the RAID driver
will
continue to use the operational mirrors in the set, providing
an
error free MD (multiple device) to the higher levels of the
kernel.
In a set with N drives, the available space is the capacity
of
a single drive, and the set protects against a failure of (N - 1)
[color="#008080"]drives.
Information
about Software RAID on Linux is contained in the
Software-RAID
mini-HOWTO, available from
.
There you will also
learn
where to get the supporting user space utilities raidtools.
If
you want to use such a RAID-1 set, say Y.  To compile this code
as
a module, choose M here: the module will be called raid1.
If
unsure, say Y.

RAID-10
                                        (mirrored striping) mode (EXPERIMENTAL)
                               
RAID-10
provides a combination of striping (RAID-0) and
mirroring
(RAID-1) with easier configuration and more flexable
[color="#008080"]layout.
Unlike
RAID-0, but like RAID-1, RAID-10 requires all devices to
be
the same size (or at least, only as much as the smallest device
will
be used).
RAID-10
provides a variety of layouts that provide different levels
of
redundancy and performance.
RAID-10
requires mdadm-1.7.0 or later, available at:
[color="#008080"]ftp://ftp.kernel.org/pub/linux/utils/raid/mdadm/
If
unsure, say Y.

RAID-4/RAID-5
                                        mode
                               
A
RAID-5 set of N drives with a capacity of C MB per drive provides
the
capacity of C * (N - 1) MB, and protects against a failure
of
a single drive. For a given sector (row) number, (N - 1) drives
contain
data sectors, and one drive contains the parity protection.
For
a RAID-4 set, the parity blocks are present on a single drive,
while
a RAID-5 set distributes the parity across the drives in one
of
the available parity distribution methods.
Information
about Software RAID on Linux is contained in the
Software-RAID
mini-HOWTO, available from
.
There you will also
learn
where to get the supporting user space utilities raidtools.
If
you want to use such a RAID-4/RAID-5 set, say Y.  To
compile
this code as a module, choose M here: the module
will
be called raid5.
If
unsure, say Y.

RAID-6
                                        mode
                               
A
RAID-6 set of N drives with a capacity of C MB per drive
provides
the capacity of C * (N - 2) MB, and protects
against
a failure of any two drives. For a given sector
(row)
number, (N - 2) drives contain data sectors, and two
drives
contains two independent redundancy syndromes.  Like
RAID-5,
RAID-6 distributes the syndromes across the drives
in
one of the available parity distribution methods.
RAID-6
requires mdadm-1.5.0 or later, available at:
[color="#008080"]ftp://ftp.kernel.org/pub/linux/utils/raid/mdadm/
If
you want to use such a RAID-6 set, say Y.  To compile
this
code as a module, choose M here: the module will be
called
raid6.
If
unsure, say Y.

Multipath
                                        I/O support
                                       
                               
Multipath-IO
is the ability of certain devices to address the same
physical
disk over multiple 'IO paths'. The code ensures that such
paths
can be defined and handled at runtime, and ensures that a
transparent
failover to the backup path(s) happens if a IO errors
arrives
on the primary path.
If
unsure, say N.

Faulty
                                        test module for MD
                               
The
"faulty" module allows for a block device that occasionally
returns
read
or write errors.  It is useful for testing.
In
unsure, say N.

Device
                                mapper support
                       
Device-mapper
is a low level volume manager.  It works by allowing
people
to specify mappings for ranges of logical sectors.  Various
mapping
types are available, in addition people may write their own
modules
containing custom mappings if they wish.
Higher
level volume managers such as LVM2 use this driver.
To
compile this as a module, choose M here: the module will be
called
dm-mod.
If
unsure, say N.

Crypt
                                        target support
                                       
                               
This
device-mapper target allows you to create a device that
transparently
encrypts the data on it. You'll need to activate
the
ciphers you're going to use in the cryptoapi configuration.
Information
on how to use dm-crypt can be found on
[color="#008080"]
To
compile this code as a module, choose M here: the module will
be
called dm-crypt.
If
unsure, say N.

Snapshot
                                        target (EXPERIMENTAL)
                               
Allow
volume managers to take writeable snapshots of a device.

Mirror
                                        target (EXPERIMENTAL)
                               
Allow
volume managers to mirror logical volumes, also
needed
for live data migration tools such as 'pvmove'.

Zero
                                        target (EXPERIMENTAL)
                               
A
target that discards writes, and returns all zeroes for
reads.
Useful in some recovery situations.

Multipath
                                        target (EXPERIMENTAL)
                               
Allow
volume managers to support multipath hardware.

EMC
                                                CX/AX multipath support (EXPERIMENTAL)
                                       
Multipath
support for EMC CX/AX series hardware.

Fusion
                MPT device support
               
               

Fusion
                        MPT ScsiHost drivers for SPI
                       
               
       
SCSI
HOST support for a parallel SCSI host adapters.
List
of supported controllers:
[color="#008080"]LSI53C1020
[color="#008080"]LSI53C1020A
[color="#008080"]LSI53C1030
[color="#008080"]LSI53C1035

Fusion
                        MPT ScsiHost drivers for FC
               
SCSI
HOST support for a Fiber Channel host adapters.
List
of supported controllers:
[color="#008080"]LSIFC909
[color="#008080"]LSIFC919
[color="#008080"]LSIFC919X
[color="#008080"]LSIFC929
[color="#008080"]LSIFC929X
[color="#008080"]LSIFC929XL

Fusion
                        MPT ScsiHost drivers for SAS
               
SCSI
HOST support for a SAS host adapters.
List
of supported controllers:
[color="#008080"]LSISAS1064
[color="#008080"]LSISAS1066
[color="#008080"]LSISAS1068
[color="#008080"]LSISAS1064E
[color="#008080"]LSISAS1066E
[color="#008080"]LSISAS1068E

Maximum
                        number of scatter gather entries (16 – 128)
               
This
option allows you to specify the maximum number of scatter-
gather
entries per I/O. The driver default is 128, which matches
SCSI_MAX_PHYS_SEGMENTS.
However, it may decreased down to 16.
Decreasing
this parameter will reduce memory requirements
on
a per controller instance.

Fusion
                        MPT misc device (ioctl) driver
               
The
Fusion MPT misc device driver provides specialized control
of
MPT adapters via system ioctl calls.  Use of ioctl calls to
the
MPT driver requires that you create and use a misc device
node
ala:
mknod
/dev/mptctl c 10 240
One
use of this ioctl interface is to perform an upgrade (reflash)
of
the MPT adapter firmware.  Refer to readme file(s) distributed
with
the Fusion MPT linux driver for additional details.
If
enabled by saying M to this, a driver named: mptctl
will
be compiled.
If
unsure whether you really want or need this, say N.

Fusion
                        MPT LAN driver
               
This
module supports LAN IP traffic over Fibre Channel port(s)
on
Fusion MPT compatible hardware (LSIFC9xx chips).
The
physical interface used is defined in RFC 2625.
Please
refer to that document for details.
Installing
this driver requires the knowledge to configure and
activate
a new network interface, "fc0", using standard Linux tools.
If
enabled by saying M to this, a driver named: mptlan
will
be compiled.
If
unsure whether you really want or need this, say N.

IEEE
                1394 (FireWire) support
               
               

IEEE
                        1394 (FireWire) support
               
       
IEEE
1394 describes a high performance serial bus, which is also
known
as FireWire(tm) or i.Link(tm) and is used for connecting all
sorts
of devices (most notably digital video cameras) to your
[color="#008080"]computer.
If
you have FireWire hardware and want to use it, say Y here.  This
is
the core support only, you will also need to select a driver for
your
IEEE 1394 adapter.
To
compile this driver as a module, say M here: the
module
will be called ieee1394.

Excessive
                                debugging output
                       
If
you say Y here, you will get very verbose debugging logs from
the
subsystem which includes a dump of the header of every sent
and
received packet.  This can amount to a high amount of data
collected
in a very short time which is usually also saved to
disk
by the system logging daemons.
Say
Y if you really want or need the debugging output, everyone
else
says N.

OUI
                                Database built-in
                       
If
you say Y here, then an OUI list (vendor unique ID's) will be
compiled
into the ieee1394 module. This doesn't really do much
except
being able to display the vendor of a hardware node. The
downside
is that it adds about 300k to the size of the module,
or
kernel (depending on whether you compile ieee1394 as a
module,
or static in the kernel).
This
option is not needed for userspace programs like gscanbus
to
show this information.

Build
                                in extra config rom entries for certain functionality
                       
Some
IEEE1394 functionality depends on extra config rom entries
being
available in the host adapters CSR. These options will
allow
you to choose which ones.

Export
                                all symbols of ieee1394's API
                               
                       
Export
all symbols of ieee1394's driver programming interface, even
those
that are not currently used by the standard IEEE 1394 drivers.
This
option does not affect the interface to userspace applications.
Say
Y here if you want to compile externally developed drivers that
make
extended use of ieee1394's API. It is otherwise safe to say N.

Texas
                                Instruments PCILynx support
                               
                       
Say
Y here if you have an IEEE-1394 controller with the Texas
Instruments
PCILynx chip.  Note: this driver is written for revision
2
of this chip and may not work with revision 0.
To
compile this driver as a module, say M here: the
module
will be called pcilynx.

OHCI-1394
                                support
                       
Enable
this driver if you have an IEEE 1394 controller based on the
OHCI-1394
specification. The current driver is only tested with OHCI
chipsets
made by Texas Instruments and NEC. Most third-party vendors
use
one of these chipsets.  It should work with any OHCI-1394
compliant
card, however.
To
compile this driver as a module, say M here: the
module
will be called ohci1394.

OHCI-1394
                                Video support
                       
This
option enables video device usage for OHCI-1394 cards.  Enable
this
option only if you have an IEEE 1394 video device connected to
an
OHCI-1394 card.

SBP-2
                                support (Harddisks etc.)
                       
This
option enables you to use SBP-2 devices connected to your IEEE
1394
bus.  SBP-2 devices include harddrives and DVD devices.

Ethernet
                                over 1394
                               
                       
This
driver implements a functional majority of RFC 2734: IPv4 over
1394.
It will provide IP connectivity with implementations of RFC
2734
found on other operating systems.  It will not communicate with
older
versions of this driver found in stock kernels prior to 2.6.3.
This
driver is still considered experimental.  It does not yet support
MCAP,
therefore multicast support is significantly limited.

OHCI-DV
                                I/O support
                       
This
driver allows you to transmit and receive DV (digital video)
streams
on an OHCI-1394 card using a simple frame-oriented
[color="#008080"]interface.
The
user-space API for dv1394 is documented in dv1394.h.
To
compile this driver as a module, say M here: the
module
will be called dv1394.

Raw
                                IEEE1394 I/O support
                               
                       
Say
Y here if you want support for the raw device. This is generally
a
good idea, so you should say Y here. The raw device enables
direct
communication of user programs with the IEEE 1394 bus and
thus
with the attached peripherals.
To
compile this driver as a module, say M here: the
module
will be called raw1394.

I2O
                device support
               
               

I2O
                        support
               
       
The
Intelligent Input/Output (I2O) architecture allows hardware
drivers
to be split into two parts: an operating system specific
module
called the OSM and an hardware specific module called the
HDM.
The OSM can talk to a whole range of HDM's, and ideally the
HDM's
are not OS dependent. This allows for the same HDM driver to
be
used under different operating systems if the relevant OSM is in
place.
In order for this to work, you need to have an I2O interface
adapter
card in your computer. This card contains a special I/O
processor
(IOP), thus allowing high speeds since the CPU does not
have
to deal with I/O.
If
you say Y here, you will get a choice of interface adapter
drivers
and OSM's with the following questions.
To
compile this support as a module, choose M here: the
modules
will be called i2o_core.
If
unsure, say N.

Enable
                                LCT notification
                       
Only
say N here if you have a I2O controller from SUN. The SUN
firmware
doesn't support LCT notification on changes. If this option
is
enabled on such a controller the driver will hang up in a endless
loop.
On all other controllers say Y.
If
unsure, say Y.

Enable
                                Adaptec extensions
                       
Say
Y for support of raidutils for Adaptec I2O controllers. You also
have
to say Y to "I2O Configuration support", "I2O SCSI
OSM" below
and
to "SCSI generic support" under "SCSI device
configuration".

I2O
                                Configuration support
                       
Say
Y for support of the configuration interface for the I2O adapters.
If
you have a RAID controller from Adaptec and you want to use the
raidutils
to manage your RAID array, you have to say Y here.
To
compile this support as a module, choose M here: the
module
will be called i2o_config.
Note:
If you want to use the new API you have to download the
i2o_config
patch from
[color="#008080"]http://i2o.shadowconnect.com/

Enable
                                        ioctls (OBSOLETE)
                               
Enables
old ioctls.

I2O
                                Bus Adapter OSM
                       
Include
support for the I2O Bus Adapter OSM. The Bus Adapter OSM
provides
access to the busses on the I2O controller. The main purpose
is
to rescan the bus to find new devices.
To
compile this support as a module, choose M here: the
module
will be called i2o_bus.

I2O
                                Block OSM
                       
Include
support for the I2O Block OSM. The Block OSM presents disk
and
other structured block devices to the operating system. If you
are
using an RAID controller, you could access the array only by
the
Block OSM driver. But it is possible to access the single disks
by
the SCSI OSM driver, for example to monitor the disks.
To
compile this support as a module, choose M here: the
module
will be called i2o_block.

I2O
                                SCSI OSM
                       
Allows
direct SCSI access to SCSI devices on a SCSI or FibreChannel
I2O
controller. You can use both the SCSI and Block OSM together if
you
wish. To access a RAID array, you must use the Block OSM driver.
But
you could use the SCSI OSM driver to monitor the single disks.
To
compile this support as a module, choose M here: the
module
will be called i2o_scsi.

I2O
                                /proc support
                       
If
you say Y here and to "/proc file system support", you will
be
able
to read I2O related information from the virtual directory
[color="#008080"]/proc/i2o.
To
compile this support as a module, choose M here: the
module
will be called i2o_proc.

Network
                device support
               
               

Network
                        device support
               
       
You
can say N here if you don't intend to connect your Linux box to
any
other computer at all.
You'll
have to say Y if your computer contains a network card that
you
want to use under Linux. If you are going to run SLIP or PPP over
telephone
line or null modem cable you need say Y here. Connecting
two
machines with parallel ports using PLIP needs this, as well as
AX.25/KISS
for sending Internet traffic over amateur radio links.
See
also "The Linux Network Administrator's Guide" by Olaf
Kirch and
Terry
Dawson. Available at .
If
unsure, say Y.

Dummy
                        net driver support
               
This
is essentially a bit-bucket device (i.e. traffic you send to
this
device is consigned into oblivion) with a configurable IP
address.
It is most commonly used in order to make your currently
inactive
SLIP address seem like a real address for local programs.
If
you use SLIP or PPP, you might want to say Y here. Since this
thing
often comes in handy, the default is Y. It won't enlarge your
kernel
either. What a deal. Read about it in the Network
Administrator's
Guide, available from
[color="#008080"].
To
compile this driver as a module, choose M here: the module
will
be called dummy.  If you want to use more than one dummy
device
at a time, you need to compile this driver as a module.
Instead
of 'dummy', the devices will then be called 'dummy0',
'dummy1'
etc.

Bonding
                        driver support
               
Say
'Y' or 'M' if you wish to be able to 'bond' multiple Ethernet
Channels
together. This is called 'Etherchannel' by Cisco,
'Trunking'
by Sun, 802.3ad by the IEEE, and 'Bonding' in Linux.
The
driver supports multiple bonding modes to allow for both high
perfomance
and high availability operation.
Refer
to  for more
[color="#008080"]information.
To
compile this driver as a module, choose M here: the module
will
be called bonding.

EQL
                        (serial line load balancing) support
                       
               
If
you have two serial connections to some other computer (this
usually
requires two modems and two telephone lines) and you use
SLIP
(the protocol for sending Internet traffic over telephone
lines)
or PPP (a better SLIP) on them, you can make them behave like
one
double speed connection using this driver.  Naturally, this has
to
be supported at the other end as well, either with a similar EQL
Linux
driver or with a Livingston Portmaster 2e.
Say
Y if you want this and read
.
You may also want to read
section
6.2 of the NET-3-HOWTO, available from
[color="#008080"].
To
compile this driver as a module, choose M here: the module
will
be called eql.  If unsure, say N.

Universal
                        TUN/TAP device driver support
               
TUN/TAP
provides packet reception and transmission for user space
programs.
It can be viewed as a simple Point-to-Point or Ethernet
device,
which instead of receiving packets from a physical media,
receives
them from user space program and instead of sending packets
via
physical media writes them to the user space program.
When
a program opens /dev/net/tun, driver creates and registers
corresponding
net device tunX or tapX.  After a program closed above
devices,
driver will automatically delete tunXX or tapXX device and
all
routes corresponding to it.
Please
read  for more
[color="#008080"]information.
To
compile this driver as a module, choose M here: the module
will
be called tun.
If
you don't know what to use this for, you don't need it.

General
                        Instruments Surfboard 1000
                       
               
This
is a driver for the General Instrument (also known as
NextLevel)
SURFboard 1000 internal
cable
modem. This is an ISA card which is used by a number of cable
TV
companies to provide cable modem access. It's a one-way
downstream-only
cable modem, meaning that your upstream net link is
provided
by your regular phone modem.
At
present this driver only compiles as a module, so say M here if
you
have this card. The module will be called sb1000. Then read
for information on how
to
use this module, as it needs special ppp scripts for establishing
a
connection. Further documentation and the necessary scripts can be
found
at:
[color="#008080"]
[color="#008080"]
[color="#008080"]
If
you don't have this card, of course say N.

ARCnet
                        devices
               
If
you have a network card of this type, say Y and check out the
(arguably)
beautiful poetry in
[color="#008080"].
You
need both this driver, and the driver for the particular ARCnet
chipset
of your card. If you don't know, then it's probably a
COM90xx
type card, so say Y (or M) to "ARCnet COM90xx chipset
support"
below.
You
might also want to have a look at the Ethernet-HOWTO, available
from
(even though ARCnet
is
not really Ethernet).
To
compile this driver as a module, choose M here and read
.
The module will
be
called arcnet.

PHY
                        device support
                       
               
Ethernet
controllers are usually attached to PHY
devices.
This option provides infrastructure for
managing
PHY devices.

Ethernet
                        (10 or 100Mbit)
                       
                       

Ethernet
                        (1000 Mbit)
                       
                       

Ethernet
                        (10000 Mbit)
                       
                       

Token
                        Ring devices
                       
               
Token
Ring is IBM's way of communication on a local network; the
rest
of the world uses Ethernet. To participate on a Token Ring
network,
you need a special Token ring network card. If you are
connected
to such a Token Ring network and want to use your Token
Ring
card under Linux, say Y here and to the driver for your
particular
card below and read the Token-Ring mini-HOWTO, available
from
. Most people can
say
N here.

Wireless
                        LAN (non-hamradio)
                       
               
Support
for wireless LANs and everything having to do with radio,
but
not with amateur radio or FM broadcasting.
Saying
Y here also enables the Wireless Extensions (creates
/proc/net/wireless
and enables iwconfig access). The Wireless
Extension
is a generic API allowing a driver to expose to the user
space
configuration and statistics specific to common Wireless LANs.
The
beauty of it is that a single set of tool can support all the
variations
of Wireless LANs, regardless of their type (as long as
the
driver supports Wireless Extension). Another advantage is that
these
parameters may be changed on the fly without restarting the
driver
(or Linux). If you wish to use Wireless Extensions with
wireless
PCMCIA (PC-) cards, you need to say Y here; you can fetch
the
tools from
[color="#008080"].

PCMCIA
                        network device support
                       
               
Say
Y if you would like to include support for any PCMCIA or CardBus
network
adapters, then say Y to the driver for your particular card
below.
PCMCIA- or PC-cards are credit-card size devices often used
with
laptops computers; CardBus is the newer and faster version of
[color="#008080"]PCMCIA.
To
use your PC-cards, you will need supporting software from David
Hinds'
pcmcia-cs package (see the file
for
location).  You also want to check out the PCMCIA-HOWTO,
available
from .
If
unsure, say N.

Wan
                        interfaces
                       
               
Wide
Area Networks (WANs), such as X.25, Frame Relay and leased
lines,
are used to interconnect Local Area Networks (LANs) over vast
distances
with data transfer rates significantly higher than those
achievable
with commonly used asynchronous modem connections.
Usually,
a quite expensive external device called a `WAN router' is
needed
to connect to a WAN. As an alternative, a relatively
inexpensive
WAN interface card can allow your Linux box to directly
connect
to a WAN.
If
you have one of those cards and wish to use it under Linux,
say
Y here and also to the WAN driver for your card.
If
unsure, say N.

ATM
                        drivers
                       

FDDI
                        driver support
               
Fiber
Distributed Data Interface is a high speed local area network
design;
essentially a replacement for high speed Ethernet. FDDI can
run
over copper or fiber. If you are connected to such a network and
want
a driver for the FDDI card in your computer, say Y here (and
then
also Y to the driver for your FDDI card, below). Most people
will
say N.

HIPPI
                        driver support (EXPERIMENTAL)
               
HIgh
Performance Parallel Interface (HIPPI) is a 800Mbit/sec and
1600Mbit/sec
dual-simplex switched or point-to-point network. HIPPI
can
run over copper (25m) or fiber (300m on multi-mode or 10km on
single-mode).
HIPPI networks are commonly used for clusters and to
connect
to super computers. If you are connected to a HIPPI network
and
have a HIPPI network card in your computer that you want to use
under
Linux, say Y here (you must also remember to enable the driver
for
your HIPPI card below). Most people will say N here.

PLIP
                        (parallel port) support
               
PLIP
(Parallel Line Internet Protocol) is used to create a
reasonably
fast mini network consisting of two (or, rarely, more)
local
machines.  A PLIP link from a Linux box is a popular means to
install
a Linux distribution on a machine which doesn't have a
CD-ROM
drive (a minimal system has to be transferred with floppies
first).
The kernels on both machines need to have this PLIP option
enabled
for this to work.
The
PLIP driver has two modes, mode 0 and mode 1.  The parallel
ports
(the connectors at the computers with 25 holes) are connected
with
"null printer" or "Turbo Laplink" cables which
can transmit 4
bits
at a time (mode 0) or with special PLIP cables, to be used on
bidirectional
parallel ports only, which can transmit 8 bits at a
time
(mode 1); you can find the wiring of these cables in
.
The cables can be up to
15m
long.  Mode 0 works also if one of the machines runs DOS/Windows
and
has some PLIP software installed, e.g. the Crynwr PLIP packet
driver
()
and
winsock or NCSA's telnet.
If
you want to use PLIP, say Y and read the PLIP mini-HOWTO as well
as
the NET-3-HOWTO, both available from
.
Note that the PLIP
protocol
has been changed and this PLIP driver won't work together
with
the PLIP support in Linux versions 1.0.x.  This option enlarges
your
kernel by about 8 KB.
To
compile this driver as a module, choose M here and read
.
The module will be
called
plip.  If unsure, say Y or M, in case you buy a laptop
[color="#008080"]later.

PPP
                        (point-to-point protocol) support
               
PPP
(Point to Point Protocol) is a newer and better SLIP.  It serves
the
same purpose: sending Internet traffic over telephone (and other
serial)
lines.  Ask your access provider if they support it, because
otherwise
you can't use it; most Internet access providers these
days
support PPP rather than SLIP.
To
use PPP, you need an additional program called pppd as described
in
the PPP-HOWTO, available at
.
Make sure that you have
the
version of pppd recommended in .
The
PPP option enlarges your kernel by about 16 KB.
There
are actually two versions of PPP: the traditional PPP for
asynchronous
lines, such as regular analog phone lines, and
synchronous
PPP which can be used over digital ISDN lines for
example.
If you want to use PPP over phone lines or other
asynchronous
serial lines, you need to say Y (or M) here and also to
the
next option, "PPP support for async serial ports".  For PPP
over
synchronous
lines, you should say Y (or M) here and to "Support
synchronous
PPP", below.
If
you said Y to "Version information on all symbols" above,
then
you
cannot compile the PPP driver into the kernel; you can then only
compile
it as a module. To compile this driver as a module, choose M
here
and read .
The
module will be called ppp_generic.

SLIP
                        (serial line) support
                       
               
Say
Y if you intend to use SLIP or CSLIP (compressed SLIP) to
connect
to your Internet service provider or to connect to some
other
local Unix box or if you want to configure your Linux box as a
Slip/CSlip
server for other people to dial in. SLIP (Serial Line
Internet
Protocol) is a protocol used to send Internet traffic over
serial
connections such as telephone lines or null modem cables;
nowadays,
the protocol PPP is more commonly used for this same
[color="#008080"]purpose.
Normally,
your access provider has to support SLIP in order for you
to
be able to use it, but there is now a SLIP emulator called SLiRP
around
(available from
)
which
allows
you to use SLIP over a regular dial up shell connection. If
you
plan to use SLiRP, make sure to say Y to CSLIP, below. The
NET-3-HOWTO,
available from
,
explains how to
configure
SLIP. Note that you don't need this option if you just
want
to run term (term is a program which gives you almost full
Internet
connectivity if you have a regular dial up shell account on
some
Internet connected Unix computer. Read
).
SLIP
support
will enlarge your kernel by about 4 KB. If unsure, say N.
To
compile this driver as a module, choose M here and read
.
The module will be
called
slip.

Fibre
                        Channel driver support
               
Fibre
Channel is a high speed serial protocol mainly used to connect
large
storage devices to the computer; it is compatible with and
intended
to replace SCSI.
If
you intend to use Fibre Channel, you need to have a Fibre channel
adaptor
card in your computer; say Y here and to the driver for your
adaptor
below. You also should have said Y to "SCSI support" and
"SCSI
generic support".

Traffic
                        Shaper (EXPERIMENTAL)
               
The
traffic shaper is a virtual network device that allows you to
limit
the rate of outgoing data flow over some other network device.
The
traffic that you want to slow down can then be routed through
these
virtual devices. See
for more information.
An
alternative to this traffic shaper is the experimental
Class-Based
Queueing (CBQ) scheduling support which you get if you
say
Y to "QoS and/or fair queueing" above.
To
compile this driver as a module, choose M here: the module
will
be called shaper.  If unsure, say N.

Network
                        console logging support (EXPERIMENTAL)
               
If
you want to log kernel messages over the network, enable this.
See
for details.

ISDN
                subsystem
       
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 is that the speed is higher than ordinary
modem/telephone
connections, and that you can have voice
conversations
while downloading stuff.  It only works 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  on the WWW.
Select
this option if you want your kernel to support ISDN.

Telephony
                Support
               
       
Say
Y here if you have a telephony card, which for example allows
you
to use a regular phone for voice-over-IP applications.
Note:
this has nothing to do with modems.  You do not need to say Y
here
in order to be able to use a modem under Linux.
To
compile this driver as a module, choose M here: the
module
will be called phonedev.

Input
                device support
               
               

Generic
                        input layer (needed for keyboard, mouse, ...)
               
       
Say
Y 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 standard PS/2
keyboard
and mouse.
Say
N here if you have a headless (no monitor, no keyboard) system.
More
information is available:
If
unsure, say Y.
To
compile this driver as a module, choose M here: the
module
will be called input.

Mouse
                                interface
                       
Say
Y here if you want your mouse to be accessible as char devices
13:32+
- /dev/input/mouseX and 13:63 - /dev/input/mice as an
emulated
IntelliMouse Explorer PS/2 mouse. That way, all user space
programs
(including SVGAlib, GPM and X) will be able to use your
[color="#008080"]mouse.
If
unsure, say Y.
To
compile this driver as a module, choose M here: the
module
will be called mousedev.

Joystick
                                interface
                               
                       
Say
Y here if you want your joystick or gamepad to be
accessible
as char device 13:0+ - /dev/input/jsX device.
If
unsure, say Y.
More
information is available:
To
compile this driver as a module, choose M here: the
module
will be called joydev.

Touchscreen
                                interface
                       
Say
Y here if you have an application that only can understand the
Compaq
touchscreen protocol for absolute pointer data. This is
useful
namely for embedded configurations.
If
unsure, say N.
To
compile this driver as a module, choose M here: the
module
will be called tsdev.

Event
                                interface
                       
Say
Y here if you want your input device events be accessible
under
char device 13:64+ - /dev/input/eventX in a generic way.
To
compile this driver as a module, choose M here: the
module
will be called evdev.

Event
                                debugging
                       
Say
Y here if you have a problem with the input subsystem and
want
all events (keypresses, mouse movements), to be output to
the
system log. While this is useful for debugging, it's also
a
security threat - your keypresses include your passwords, of
[color="#008080"]course.
If
unsure, say N.
To
compile this driver as a module, choose M here: the
module
will be called evbug.
Input
                                Device Drivers
                               

Keyboards
                       
Say
Y here, and a list of supported keyboards will be displayed.
This
option doesn't affect the kernel.
If
unsure, say Y.

Mouse
                       
Say
Y here, and a list of supported mice will be displayed.
This
option doesn't affect the kernel.
If
unsure, say Y.

Joysticks
                       
If
you have a joystick, 6dof controller, gamepad, steering wheel,
weapon
control system or something like that you can say Y here
and
the list of supported devices will be displayed. This option
doesn't
affect the kernel.
Please
read the file  which
contains
more information.

Touchscreens
                               
                               
                       
Say
Y here, and a list of supported touchscreens will be displayed.
This
option doesn't affect the kernel.
If
unsure, say Y.

Miscellaneous
                                devices
                       
Say
Y here, and a list of miscellaneous input drivers will be displayed.
Everything
that didn't fit into the other categories is here. This option
doesn't
affect the kernel.
If
unsure, say Y.

Hardware
                        I/O ports
                       
                       

Serial
                                I/O support
                       
               
Say
Yes here if you have any input device that uses serial I/O to
communicate
with the system. This includes the
             * standard AT
keyboard and PS/2 mouse *
as
well as serial mice, Sun keyboards, some joysticks and 6dof
devices
and more.
If
unsure, say Y.
To
compile this driver as a module, choose M here: the
module
will be called serio.

Gameport
                                support
                       
Gameport
support is for the standard 15-pin PC gameport. If you
have
a joystick, gamepad, gameport card, a soundcard with a gameport
or
anything else that uses the gameport, say Y or M here and also to
at
least one of the hardware specific drivers.
For
Ensoniq AudioPCI (ES1370), AudioPCI 97 (ES1371), ESS Solo1,
S3
SonicVibes, Trident 4DWave, SiS7018, and ALi 5451 gameport
support
is provided by the sound drivers, so you won't need any
from
the below listed modules. You still need to say Y here.
If
unsure, say Y.
To
compile this driver as a module, choose M here: the
module
will be called gameport.

Character
                devices
               
               

Virtual
                        terminal
                       
               
       
If
you say Y here, you will 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. This is rather useful, for example one
virtual
terminal can collect 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-.
The
setterm command ("man setterm") can be used to change the
properties
(such as colors or beeping) of a virtual terminal. The
man
page console_codes(4) ("man console_codes") contains the
special
character
sequences that can be used to change those properties
directly.
The fonts used on virtual terminals can be changed with
the
setfont ("man setfont") command and the key bindings are
defined
with
the loadkeys ("man loadkeys") command.
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 N here in order to save some
memory;
the only way to log into such a system is then via a serial
or
network connection.
If
unsure, say Y, or else you won't be able to do much with your new
shiny
Linux system :-)

Support
                                for console on virtual terminal
                       
The
system console is the device which receives all kernel messages
and
warnings and which allows logins in single user mode. If you
answer
Y 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 Y here unless you want
the
kernel messages be output only to a serial port (in which case
you
should say Y to "Console on serial port", below).
If
you do say Y here, by default the currently visible virtual
terminal
(/dev/tty0) will be used as system console. You can change
that
with a kernel command line option such as "console=tty3"
which
would
use the third virtual terminal as system console. (Try "man
bootparam"
or see the documentation of your boot loader (lilo or
loadlin)
about how to pass options to the kernel at boot time.)
If
unsure, say Y.

Non-standard
                        serial port support
               
Say
Y here if you have any non-standard serial boards -- boards
which
aren't supported using the standard "dumb" serial driver.
This
includes intelligent serial boards such as Cyclades,
Digiboards,
etc. These are usually used for systems that need many
serial
ports because they serve many terminals or dial-in
[color="#008080"]connections.
Note
that the answer to this question won't directly affect the
kernel:
saying N will just cause the configurator to skip all
the
questions about non-standard serial boards.
Most
people can say N here.

Serial
                        drivers
                       

8250/16550
                                and compatible serial support
                       
               
This
selects whether you want to include the driver for the standard
serial
ports.  The standard answer is Y.  People who might say N
here
are those that are 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.  (Note that the Cyclades and Stallion multi
serial
port drivers do not need this driver built in for them to
[color="#008080"]work.)
To
compile this driver as a module, choose M here: the
module
will be called 8250.
[WARNING:
Do not compile this driver as a module if you are using
non-standard
serial ports, since the configuration information will
be
lost when the driver is unloaded.  This limitation may be lifted
in
the future.]
BTW1:
If you have a mouseman serial mouse which is not recognized by
the
X window system, try running gpm first.
BTW2:
If you intend to use a software modem (also called Winmodem)
under
Linux, forget it.  These modems are crippled and require
proprietary
drivers which are only available under Windows.
Most
people will say Y or M here, so that they can use serial mice,
modems
and similar devices connecting to the standard serial ports.

Unix98
                        PTY support
               
A
pseudo terminal (PTY) is a software device consisting of two
halves:
a master and a slave. The slave device behaves identical to
a
physical terminal; the master device is used by a process to
read
data from and write data to the slave, thereby emulating a
terminal.
Typical programs for the master side are telnet servers
and
xterms.
Linux
has traditionally used the BSD-like names /dev/ptyxx for
masters
and /dev/ttyxx for slaves of pseudo terminals. This scheme
has
a number of problems. The GNU C library glibc 2.1 and later,
however,
supports the Unix98 naming standard: in order to acquire a
pseudo
terminal, a process opens /dev/ptmx; the number of the pseudo
terminal
is then made available to the process and the pseudo
terminal
slave can be accessed as /dev/pts/. What was
traditionally
/dev/ttyp2 will then be /dev/pts/2, for example.
All
modern Linux systems use the Unix98 ptys.  Say Y unless
you're
on an embedded system and want to conserve memory.

Legacy
                        (BSD) PTY support
               
A
pseudo terminal (PTY) is a software device consisting of two
halves:
a master and a slave. The slave device behaves identical to
a
physical terminal; the master device is used by a process to
read
data from and write data to the slave, thereby emulating a
terminal.
Typical programs for the master side are telnet servers
and
xterms.
Linux
has traditionally used the BSD-like names /dev/ptyxx
for
masters and /dev/ttyxx for slaves of pseudo
terminals.
This scheme has a number of problems, including
security.
This option enables these legacy devices; on most
systems,
it is safe to say N.

Parallel
                        printer support
               
If
you intend to attach a printer to the parallel port of your Linux
box
(as opposed to using a serial printer; if the connector at the
printer
has 9 or 25 holes ["female"], then it's serial), say Y.
Also
read the Printing-HOWTO, available from
[color="#008080"].
It
is possible to share one parallel port among several devices
(e.g.
printer and ZIP drive) and it is safe to compile the
corresponding
drivers into the kernel.
To
compile this driver as a module, choose M here and read
.
The module will be called lp.
If
you have several parallel ports, you can specify which ports to
use
with the "lp" kernel command line option.  (Try "man
bootparam"
or
see the documentation of your boot loader (lilo or loadlin) about
how
to pass options to the kernel at boot time.)  The syntax of the
"lp"
command line option can be found in .
If
you have more than 8 printers, you need to increase the LP_NO
macro
in lp.c and the PARPORT_MAX macro in parport.h.

Support
                                for console on line printer
                       
If
you want kernel messages to be printed out as they occur, you
can
have a console on the printer. This option adds support for
doing
that; to actually get it to happen you need to pass the
option
"console=lp0" to the kernel at boot time.
If
the printer is out of paper (or off, or unplugged, or too
busy..)
the kernel will stall until the printer is ready again.
By
defining CONSOLE_LP_STRICT to 0 (at your own risk) you
can
make the kernel continue when this happens,
but
it'll lose the kernel messages.
If
unsure, say N.

Support
                        for user-space parallel port device drivers
               
Saying
Y to this adds support for /dev/parport device nodes.  This
is
needed for programs that want portable access to the parallel
port,
for instance deviceid (which displays Plug-and-Play device
[color="#008080"]IDs).
This
is the parallel port equivalent of SCSI generic support (sg).
It
is safe to say N to this -- it is not needed for normal printing
or
parallel port CD-ROM/disk support.
To
compile this driver as a module, choose M here: the
module
will be called ppdev.
If
unsure, say N.

Texas
                        Instruments parallel link cable support
                       
               
If
you own a Texas Instruments graphing calculator and use a
parallel
link cable, then you might be interested in this driver.
If
you enable this driver, you will be able to communicate with
your
calculator through a set of device nodes under /dev. The
main
advantage of this driver is that you don't have to be root
to
use this precise link cable (depending on the permissions on
the
device nodes, though).
To
compile this driver as a module, choose M here: the
module
will be called tipar.
If
you don't know what a parallel link cable is or what a Texas
Instruments
graphing calculator is, then you probably don't need this
[color="#008080"]driver.
If
unsure, say N.

IPMI
                       
                       
                       

IPMI
                                top-level message handler
                       
               
This
enables the central IPMI message handler, required for IPMI
to
work.
IPMI
is a standard for managing sensors (temperature,
voltage,
etc.) in a system.
See
for more details on the driver.
If
unsure, say N.

Watchdog
                        Cards
                       
                       

Watchdog
                                Timer Support
                       
               
If
you say Y here (and to one of the following options) and create a
character
special file /dev/watchdog with major number 10 and minor
number
130 using mknod ("man mknod"), you will get a watchdog,
i.e.:
subsequently
opening the file and then failing to write to it for
longer
than 1 minute will result in rebooting the machine. This
could
be useful for a networked machine that needs to come back
online
as fast as possible after a lock-up. There's both a watchdog
implementation
entirely in software (which can sometimes fail to
reboot
the machine) and a driver for hardware watchdog boards, which
are
more robust and can also keep track of the temperature inside
your
computer. For details, read
in
the kernel source.
The
watchdog is usually used together with the watchdog daemon
which
is available from
.
This daemon can
also
monitor NFS connections and can reboot the machine when the process
table
is full.
If
unsure, say N.

Intel/AMD/VIA
                        HW Random Number Generator support
               
This
driver provides kernel-side support for the Random Number
Generator
hardware found on Intel i8xx-based motherboards,
AMD
76x-based motherboards, and Via Nehemiah CPUs.
Provides
a character driver, used to read() entropy data.
To
compile this driver as a module, choose M here: the
module
will be called hw_random.
If
unsure, say N.

/dev/nvram
                        support
               
If
you say Y here and create a character special file /dev/nvram
with
major number 10 and minor number 144 using mknod ("man mknod"),
you
get read and write access to the extra bytes of non-volatile
memory
in the real time clock (RTC), which is contained in every PC
and
most Ataris.  The actual number of bytes varies, depending on the
nvram
in the system, but is usually 114 (128-14 for the RTC).
This
memory is conventionally called "CMOS RAM" on PCs and
"NVRAM"
on
Ataris. /dev/nvram may be used to view settings there, or to
change
them (with some utility). It could also be used to frequently
save
a few bits of very important data that may not be lost over
power-off
and for which writing to disk is too insecure. Note
however
that most NVRAM space in a PC belongs to the BIOS and you
should
NEVER idly tamper with it. See Ralf Brown's interrupt list
for
a guide to the use of CMOS bytes by your BIOS.
On
Atari machines, /dev/nvram is always configured and does not need
to
be selected.
To
compile this driver as a module, choose M here: the
module
will be called nvram.

Enhanced
                        Real Time Clock Support
               
If
you say Y here and create a character special file /dev/rtc with
major
number 10 and minor number 135 using mknod ("man mknod"),
you
will
get access to the real time clock (or hardware clock) built
into
your computer.
Every
PC has such a clock built in. It can be used to generate
signals
from as low as 1Hz up to 8192Hz, and can also be used
as
a 24 hour alarm. It reports status information via the file
/proc/driver/rtc
and its behaviour is set by various ioctls on
[color="#008080"]/dev/rtc.
If
you run Linux on a multiprocessor machine and said Y to
"Symmetric
Multi Processing" above, you should say Y here to read
and
set the RTC in an SMP compatible fashion.
If
you think you have a use for such a device (such as periodic data
sampling),
then say Y here, and read
for
details.
To
compile this driver as a module, choose M here: the
module
will be called rtc.

Double
                        Talk PC internal speech card support
               
This
driver is for the DoubleTalk PC, a speech synthesizer
manufactured
by RC Systems ().  It is also
called
the `internal DoubleTalk'.
To
compile this driver as a module, choose M here: the
module
will be called dtlk.

Siemens
                        R3964 line discipline
               
This
driver allows synchronous communication with devices using the
Siemens
R3964 packet protocol. Unless you are dealing with special
hardware
like PLCs, you are unlikely to need this.
To
compile this driver as a module, choose M here: the
module
will be called n_r3964.
If
unsure, say N.

Applicom
                        intelligent fieldbus card support
               
This
driver provides the kernel-side support for the intelligent
fieldbus
cards made by Applicom International. More information
about
these cards can be found on the WWW at the address
,
or by email from David Woodhouse
[color="#008080"].
To
compile this driver as a module, choose M here: the
module
will be called applicom.
If
unsure, say N.

Sony
                        Vaio Programmable I/O Control Device support (EXPERIMENTAL)
               
This
driver enables access to the Sony Programmable I/O Control
Device
which can be found in many (all ?) Sony Vaio laptops.
If
you have one of those laptops, read
,
and say Y or M here.
To
compile this driver as a module, choose M here: the
module
will be called sonypi.

Ftape,
                        the floppy tape device driver
                       

Ftape
                                (QIC-80/Travan) support
                       
               
If
you have a tape drive that is connected to your floppy
controller,
say Y here.
Some
tape drives (like the Seagate "Tape Store 3200" or the
Iomega
"Ditto
3200" or the Exabyte "Eagle TR-3") come with a "high
speed"
controller
of their own. These drives (and their companion
controllers)
are also supported if you say Y here.
If
you have a special controller (such as the CMS FC-10, FC-20,
Mountain
Mach-II, or any controller that is based on the Intel 82078
FDC
like the high speed controllers by Seagate and Exabyte and
Iomega's
"Ditto Dash") you must configure it by selecting the
appropriate
entries from the "Floppy tape controllers" sub-menu
below
and possibly modify the default values for the IRQ and DMA
channel
and the IO base in ftape's configuration menu.
If
you want to use your floppy tape drive on a PCI-bus based system,
please
read the file .
The
ftape kernel driver is also available as a runtime loadable
module.
To compile this driver as a module, choose M here: the
module
will be called ftape.

/dev/agpgart
                        (AGP Support) AGP
               
AGP
(Accelerated Graphics Port) is a bus system mainly used to
connect
graphics cards to the rest of the system.
If
you have an AGP system and you say Y here, it will be possible to
use
the AGP features of your 3D rendering video card. This code acts
as
a sort of "AGP driver" for the motherboard's chipset.
If
you need more texture memory than you can get with the AGP GART
(theoretically
up to 256 MB, but in practice usually 64 or 128 MB
due
to kernel allocation issues), you could use PCI accesses
and
have up to a couple gigs of texture space.
Note
that this is the only means to have X/GLX use
write-combining
with MTRR support on the AGP bus. Without it, OpenGL
direct
rendering will be a lot slower but still faster than PIO.
To
compile this driver as a module, choose M here: the
module
will be called agpgart.
You
should say Y here if you want to use GLX or DRI.
If
unsure, say N.

ALI
                                chipset support
                       
This
option gives you AGP support for the GLX component of
X
on the following ALi chipsets.  The supported chipsets
include
M1541, M1621, M1631, M1632, M1641,M1647,and M1651.
For
the ALi-chipset question, ALi suggests you refer to
[color="#008080"].
The
M1541 chipset can do AGP 1x and 2x, but note that there is an
acknowledged
incompatibility with Matrox G200 cards. Due to
timing
issues, this chipset cannot do AGP 2x with the G200.
This
is a hardware limitation. AGP 1x seems to be fine, though.

ATI
                                chipset support
                               
                       
This
option gives you AGP support for the GLX component of
X
on the ATI RadeonIGP family of chipsets.

AMD
                                Irongate, 761, and 762 chipset support
                       
This
option gives you AGP support for the GLX component of
X
on AMD Irongate, 761, and 762 chipsets.

AMD
                                Opteron/Athlon64 on-CPU GART support
                               
                       
This
option gives you AGP support for the GLX component of
X
using the on-CPU northbridge of the AMD Athlon64/Opteron CPUs.
You
still need an external AGP bridge like the AMD 8151, VIA
K8T400M,
SiS755. It may also support other AGP bridges when loaded
with
agp_try_unsupported=1.

Intel
                                440LX/BX/GX, I8xx and E7x05 chipset support
                               
                       
This
option gives you AGP support for the GLX component of X
on
Intel 440LX/BX/GX, 815, 820, 830, 840, 845, 850, 860, 875,
E7205
and E7505 chipsets and full support for the 810, 815, 830M,
845G,
852GM, 855GM, 865G and I915 integrated graphics chipsets.

NVIDIA
                                nForce/nForce2 chipset support
                       
This
option gives you AGP support for the GLX component of
X
on NVIDIA chipsets including nForce and nForce2

SiS
                                chipset support
                       
This
option gives you AGP support for the GLX component of
X
on Silicon Integrated Systems [SiS] chipsets.
Note
that 5591/5592 AGP chipsets are NOT supported.

Serverworks
                                LE/HE chipset support
                       
Say
Y here to support the Serverworks AGP card.  See
for product descriptions and images.

VIA
                                chipset support
                       
This
option gives you AGP support for the GLX component of
X
on VIA MVP3/Apollo Pro chipsets.

Transmeta
                                Efficeon support
                               
                       
This
option gives you AGP support for the Transmeta Efficeon
series
processors with integrated northbridges.

Direct
                        Rendering Manager (XFree86 4.1.0 and higher DRI support)
               
Kernel-level
support for the Direct Rendering Infrastructure (DRI)
introduced
in XFree86 4.0. If you say Y here, you need to select
the
module that's right for your graphics card from the list below.
These
modules provide support for synchronization, security, and
DMA
transfers. Please see  for more
details.
You should also select and configure AGP
(/dev/agpgart)
support.

PCMCIA
                        character devices
                       
               

ACP
                        Modem (Mwave) support
               
The
ACP modem (Mwave) for Linux is a WinModem. It is composed of a
kernel
driver and a user level application. Together these components
support
direct attachment to public switched telephone networks (PSTNs)
and
support selected world wide countries.
This
version of the ACP Modem driver supports the IBM Thinkpad 600E,
600,
and 770 that include on board ACP modem hardware.
The
modem also supports the standard communications port interface
(ttySx)
and is compatible with the Hayes AT Command Set.
The
user level application needed to use this driver can be found at
the
IBM Linux Technology Center (LTC) web site:
[color="#008080"].
If
you own one of the above IBM Thinkpads which has the Mwave chipset
in
it, say Y.
To
compile this driver as a module, choose M here: the
module
will be called mwave.

AMD
                        CS5535/CS5536 GPIO (Geode Companion Device)
               
Give
userspace access to the GPIO pins on the AMD CS5535 and
CS5536
Geode companion devices.
If
compiled as a module, it will be called cs5535_gpio.

RAW
                        driver (/dev/raw/rawN) (OBSOLETE)
               
The
raw driver permits block devices to be bound to /dev/raw/rawN.
Once
bound, I/O against /dev/raw/rawN uses efficient zero-copy I/O.
See
the raw(8) manpage for more details.
The
raw driver is deprecated and will be removed soon.
Applications
should simply open the device (eg /dev/hda1)
with
the O_DIRECT flag.

HPET
                        - High Precision Event Timer
               
If
you say Y here, you will have a miscdevice named "/dev/hpet/".
Each
open
selects one of the timers supported by the HPET.  The timers are
non-periodioc
and/or periodic.

Allow
                                mmap of HPET
                               
                       
If
you say Y here, user applications will be able to mmap
the
HPET registers.
In
some hardware implementations, the page containing HPET
registers
may also contain other things that shouldn't be
exposed
to the user.  If this applies to your hardware,
say
N here.

Hangcheck
                        timer
               
The
hangcheck-timer module detects when the system has gone
out
to lunch past a certain margin.  It can reboot the system
or
merely print a warning.

TPM
                        devices
               
TPM
Hardware Support TCG_TPM
If
you have a TPM security chip in your system, which
implements
the Trusted Computing Group's specification,
say
Yes and it will be accessible from within Linux.  For
more
information see .
An
implementation of the Trusted Software Stack (TSS), the
userspace
enablement piece of the specification, can be
obtained
at: .  To
compile
this driver as a module, choose M here; the module
will
be called tpm. If unsure, say N.
Note:
For more TPM drivers enable CONFIG_PNP, CONFIG_ACPI
and
CONFIG_PNPACPI.

Telecom
                        clock driver for MPBL0010 ATCA SBC
               
The
telecom clock device is specific to the MPBL0010 ATCA computer and
allows
direct userspace access to the configuration of the telecom clock
configuration
settings.  This device is used for hardware synchronization
across
the ATCA backplane fabric.  Upon loading, the driver exports a
sysfs
directory, /sys/devices/platform/telco_clock, with a number of
files
for controlling the behavior of this hardware.

I2C
                support
               
               

I2C
                        support
               
       
I2C
(pronounce: I-square-C) is a slow serial bus protocol used in
many
micro controller applications and developed by Philips.  SMBus,
or
System Management Bus is a subset of the I2C protocol.  More
information
is contained in the directory ,
especially
in the file called "summary" there.
Both
I2C and SMBus are supported here. You will need this for
hardware
sensors support, and also for Video For Linux support.
If
you want I2C support, you should say Y here and also to the
specific
driver for your bus adapter(s) below.
This
I2C support can also be built as a module.  If so, the module
will
be called i2c-core.

I2C
                                device interface
                       
Say
Y here to use i2c-* device files, usually found in the /dev
directory
on your system.  They make it possible to have user-space
programs
use the I2C bus.  Information on how to do this is
contained
in the file .
This
support is also available as a module.  If so, the module
will
be called i2c-dev.

I2C
                                Algorithms
                               
                               

I2C
                                Hardware Bus support
                               
                               

Miscellaneous
                                I2C Chip support
                               
                               

I2C
                                Core debugging messages
                       
Say
Y here if you want the I2C core to produce a bunch of debug
messages
to the system log.  Select this if you are having a
problem
with I2C support and want to see more of what is going on.

I2C
                                Algorithm debugging messages
                       
Say
Y here if you want the I2C algorithm drivers to produce a bunch
of
debug messages to the system log.  Select this if you are having
a
problem with I2C support and want to see more of what is going
[color="#008080"]on.

I2C
                                Bus debugging messages
                               
                       
Say
Y here if you want the I2C bus drivers to produce a bunch of
debug
messages to the system log.  Select this if you are having
a
problem with I2C support and want to see more of what is going
[color="#008080"]on.

I2C
                                Chip debugging messages
                       
Say
Y here if you want the I2C chip drivers to produce a bunch of
debug
messages to the system log.  Select this if you are having
a
problem with I2C support and want to see more of what is going
[color="#008080"]on.

SPI
                support
               
       
The
"Serial Peripheral Interface" is a low level synchronous
protocol.
Chips that support SPI can have data transfer rates
up
to several tens of Mbit/sec.  Chips are addressed with a
controller
and a chipselect.  Most SPI slaves don't support
dynamic
device discovery; some are even write-only or read-only.
SPI
is widely used by microcontollers to talk with sensors,
eeprom
and flash memory, codecs and various other controller
chips,
analog to digital (and d-to-a) converters, and more.
MMC
and SD cards can be accessed using SPI protocol; and for
DataFlash
cards used in MMC sockets, SPI must always be used.
SPI
is one of a family of similar protocols using a four wire
interface
(select, clock, data in, data out) including Microwire
(half
duplex), SSP, SSI, and PSP.  This driver framework should
work
with most such devices and controllers.

Dallas's
                1-wire bus
               
               

Dallas's
                        1-wire support
               
       
Dallas's
1-wire bus is useful to connect slow 1-pin devices
such
as iButtons and thermal sensors.
If
you want W1 support, you should say Y here.
This
W1 support can also be built as a module.  If so, the module
will
be called wire.ko.

Matrox
                                G400 transport layer for 1-wire
                               
                       
Say
Y here if you want to communicate with your 1-wire devices
using
Matrox's G400 GPIO pins.
This
support is also available as a module.  If so, the module
will
be called matrox_w1.ko.

DS9490R
                                transport layer driver
                       
Say
Y here if you want to have a driver for DS9490R UWB  W1
bridge.
This
support is also available as a module.  If so, the module
will
be called ds9490r.ko.

DS9490R
                                        USB  W1 transport layer for 1-wire
                               
Say
Y here if you want to communicate with your 1-wire devices
using
DS9490R USB bridge.
This
support is also available as a module.  If so, the module
will
be called ds_w1_bridge.ko.

Thermal
                                family implementation
                               
                       
Say
Y here if you want to connect 1-wire thermal sensors to you
[color="#008080"]wire.

Simple
                                64bit memory family implementation
                       
Say
Y here if you want to connect 1-wire
simple
64bit memory rom(ds2401/ds2411/ds1990*) to you wire.

4kb
                                EEPROM family support (DS2433)
                       
Say
Y here if you want to use a 1-wire
4kb
EEPROM family device (DS2433).

Protect
                                        DS2433 data with a CRC16
                               
Say
Y here to protect DS2433 data with a CRC16.
Each
block has 30 bytes of data and a two byte CRC16.
Full
block writes are only allowed if the CRC is valid.

Hardware
                Monitoring support
               

Hardware
                        Monitoring support
               
       
Hardware
monitoring devices let you monitor the hardware health
of
a system. Most modern motherboards include such a device. It
can
include temperature sensors, voltage sensors, fan speed
sensors
and various additional features such as the ability to
control
the speed of the fans.  If you want this support you
should
say Y here and also to the specific driver(s) for your
sensors
chip(s) below.
This
support can also be built as a module.  If so, the module
will
be called hwmon.

Analog
                        Devices ADM1021 and compatibles
                       
               
If
you say yes here you get support for Analog Devices ADM1021
and
ADM1023 sensor chips and clones: Maxim MAX1617 and MAX1617A,
Genesys
Logic GL523SM, National Semiconductor LM84, TI THMC10,
and
the XEON processor built-in sensor.
This
driver can also be built as a module.  If so, the module
will
be called adm1021.

Asus
                        ASB100 Bach
               
If
you say yes here you get support for the ASB100 Bach sensor
chip
found on some Asus mainboards.
This
driver can also be built as a module.  If so, the module
will
be called asb100.

Misc
                devices
               
               

Device
                        driver for IBM RSA service processor
               
       
This
option enables device driver support for in-band access to the
IBM
RSA (Condor) service processor in eServer xSeries systems.
The
ibmasm device driver allows user space application to access
ASM
(Advanced Systems Management) functions on the service
processor.
The driver is meant to be used in conjunction with
a
user space API.
The
ibmasm driver also enables the OS to use the UART on the
service
processor board as a regular serial port. To make use of
this
feature serial driver support (CONFIG_SERIAL_8250) must be
[color="#008080"]enabled.
WARNING:
This software may not be supported or function
correctly
on your IBM server. Please consult the IBM ServerProven
website
for
information
on the specific driver level and support statement
for
your IBM server.
If
unsure, say N.

Multimedia
                Capabilities Port drivers
               
               

Multimedia
                devices
               

Video
                        For Linux
               
       
Support
for audio/video capture and overlay devices and FM radio
cards.
The exact capabilities of each device vary. User tools for
this
are available from
[color="#008080"].
This
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.
Documentation
for the original API is included in the file
.
Documentation for V4L2 is
available
on the web at .
To
compile this driver as a module, choose M here: the
module
will be called videodev.

Video
                                For Linux
                               
                               

Video
                                        Adapters
                                       
                                       

Enable
                                        advanced debug functionality
                               
                       
Say
Y here to enable advanced debugging functionality on some
V4L
devices.
In
doubt, say N.

BT848
                                        Video For Linux
                               
Support
for BT848 based frame grabber/overlay boards. This includes
the
Miro, Hauppauge and STB boards. Please read the material in
for more information.
To
compile this driver as a module, choose M here: the
module
will be called bttv.

Mediavision
                                        Pro Movie Studio Video For Linux
                               
Say
Y if you have such a thing.
To
compile this driver as a module, choose M here: the
module
will be called pms.

Quickcam
                                        BW Video For Linux
                                       
                               
Say
Y have if you the black and white version of the QuickCam
camera.
See the next option for the color version.
To
compile this driver as a module, choose M here: the
module
will be called bw-qcam.

QuickCam
                                        Colour Video For Linux (EXPERIMENTAL)
                               
This
is the video4linux driver for the colour version of the
Connectix
QuickCam.  If you have one of these cameras, say Y here,
otherwise
say N.  This driver does not work with the original
monochrome
QuickCam, QuickCam VC or QuickClip.  It is also available
as
a module (c-qcam).
Read
for more
information.

W9966CF
                                        Webcam (FlyCam Supra and others) Video For Linux
                               
Video4linux
driver for Winbond's w9966 based Webcams.
Currently
tested with the LifeView FlyCam Supra.
If
you have one of these cameras, say Y here
otherwise
say N.
This
driver is also available as a module (w9966).
Check
out  for more
[color="#008080"]information.

CPiA
                                        Video For Linux
                               
This
is the video4linux driver for cameras based on Vision's CPiA
(Colour
Processor Interface ASIC), such as the Creative Labs Video
Blaster
Webcam II. If you have one of these cameras, say Y here
and
select parallel port and/or USB lowlevel support below,
otherwise
say N. This will not work with the Creative Webcam III.
Please
read  for more
[color="#008080"]information.
This
driver is also available as a module (cpia).

SAA5246A,
                                        SAA5281 Teletext processor
                               
Support
for I2C bus based teletext using the SAA5246A or SAA5281
chip.
Useful only if you live in Europe.
To
compile this driver as a module, choose M here: the
module
will be called saa5246a.

SAA5249
                                        Teletext processor
                               
Support
for I2C bus based teletext using the SAA5249 chip. At the
moment
this is only useful on some European WinTV cards.
To
compile this driver as a module, choose M here: the
module
will be called saa5249.

SAB3036
                                        tuner
                                       
                               
Say
Y here to include support for Philips SAB3036 compatible tuners.
If
in doubt, say N.

Stradis
                                        4:2:2 MPEG-2 video driver  (EXPERIMENTAL)
                               
Say
Y here to enable support for the Stradis 4:2:2 MPEG-2 video
driver
for PCI.  There is a product page at
[color="#008080"].

Zoran
                                        ZR36057/36067 Video For Linux
                               
Say
Y for support for MJPEG capture cards based on the Zoran
36057/36067
PCI controller chipset. This includes the Iomega
Buz,
Pinnacle DC10+ and the Linux Media Labs LML33. There is
a
driver homepage at . For
more
information, check .
To
compile this driver as a module, choose M here: the
module
will be called zr36067.

Sony
                                        Vaio Picturebook Motion Eye Video For Linux
                                       
                               
This
is the video4linux driver for the Motion Eye camera found
in
the Vaio Picturebook laptops. Please read the material in
for more information.
If
you say Y or M here, you need to say Y or M to "Sony
Programmable
I/O
Control Device" in the character device section.
To
compile this driver as a module, choose M here: the
module
will be called meye.

Philips
                                        SAA7134 support
                               
This
is a video4linux driver for Philips SAA713x based
TV
cards.
To
compile this driver as a module, choose M here: the
module
will be called saa7134.

Siemens-Nixdorf
                                        'Multimedia eXtension Board'
                               
This
is a video4linux driver for the 'Multimedia eXtension Board'
TV
card by Siemens-Nixdorf.
To
compile this driver as a module, choose M here: the
module
will be called mxb.

Philips-Semiconductors
                                        'dpc7146 demonstration board'
                               
This
is a video4linux driver for the 'dpc7146 demonstration
board'
by Philips-Semiconductors. It's the reference design
for
SAA7146 bases boards, so if you have some unsupported
saa7146
based, analog video card, chances are good that it
will
work with this skeleton driver.
To
compile this driver as a module, choose M here: the
module
will be called dpc7146.

Hexium
                                        HV-PCI6 and Orion frame grabber
                                       
                               
This
is a video4linux driver for the Hexium HV-PCI6 and
Orion
frame grabber cards by Hexium.
To
compile this driver as a module, choose M here: the
module
will be called hexium_orion.

Hexium
                                        Gemini frame grabber
                               
This
is a video4linux driver for the Hexium Gemini frame
grabber
card by Hexium. Please note that the Gemini Dual
card
is *not* fully supported.
To
compile this driver as a module, choose M here: the
module
will be called hexium_gemini.

Conexant
                                        2388x (bt878 successor) support
                               
This
is a video4linux driver for Conexant 2388x based
TV
cards.
To
compile this driver as a module, choose M here: the
module
will be called cx8800

VP-3054
                                        Secondary I2C Bus Support
                               
This
adds DVB-T support for cards based on the
Connexant
2388x chip and the MT352 demodulator,
which
also require support for the VP-3054
Secondary
I2C bus, such at DNTV Live! DVB-T Pro.

Empia
                                        EM2800/2820/2840 USB video capture support
                               
This
is a video4linux driver for Empia 28xx based TV cards.
To
compile this driver as a module, choose M here: the
module
will be called em28xx

OmniVision
                                        Camera Chip support
                               
Support
for the OmniVision OV6xxx and OV7xxx series of camera chips.
This
driver is intended to be used with the ov511 and w9968cf USB
camera
drivers.
To
compile this driver as a module, choose M here: the
module
will be called ovcamchip

Add
                                        support for additional audio chipsets
                               
Say
Y here to compile drivers for WM8775 and CS53L32A audio
[color="#008080"]decoders.

Add
                                        support for additional video chipsets
                               
Say
Y here to compile drivers for SAA7115, SAA7127 and CX25840
video
decoders.

Radio
                                Adapters
                               
                               

ADS
                                        Cadet AM/FM Tuner
                               
                       
Choose
Y here if you have one of these AM/FM radio cards, and then
fill
in the port address below.
In
order to control your radio card, you will need to use programs
that
are compatible with the Video For Linux API.  Information on
this
API and pointers to "v4l" programs may be found at
[color="#008080"].
Further
documentation on this driver can be found on the WWW at
[color="#008080"].
To
compile this driver as a module, choose M here: the
module
will be called radio-cadet.

AIMSlab
                                        RadioTrack (aka RadioReveal) support
                                       
                               
Choose
Y here if you have one of these FM radio cards, and then fill
in
the port address below.
Note
that newer AIMSlab RadioTrack cards have a different chipset
and
are not supported by this driver.  For these cards, use the
RadioTrack
II driver below.
If
you have a GemTeks combined (PnP) sound- and radio card you must
use
this driver as a module and setup the card with isapnptools.
You
must also pass the module a suitable io parameter, 0x248 has
been
reported to be used by these cards.
In
order to control your radio card, you will need to use programs
that
are compatible with the Video For Linux API.  Information on
this
API and pointers to "v4l" programs may be found at
.
More information is
contained
in the file
[color="#008080"].
To
compile this driver as a module, choose M here: the
module
will be called radio-aimslab.

AIMSlab
                                        RadioTrack II support
                               
Choose
Y here if you have this FM radio card, and then fill in the
port
address below.
In
order to control your radio card, you will need to use programs
that
are compatible with the Video For Linux API.  Information on
this
API and pointers to "v4l" programs may be found at
[color="#008080"].
To
compile this driver as a module, choose M here: the
module
will be called radio-rtrack2.

Aztech/Packard
                                        Bell Radio
                               
Choose
Y here if you have one of these FM radio cards, and then fill
in
the port address below.
In
order to control your radio card, you will need to use programs
that
are compatible with the Video For Linux API.  Information on
this
API and pointers to "v4l" programs may be found at
[color="#008080"].
To
compile this driver as a module, choose M here: the
module
will be called radio-aztech.

GemTek
                                        Radio Card support
                               
Choose
Y here if you have this FM radio card, and then fill in the
port
address below.
In
order to control your radio card, you will need to use programs
that
are compatible with the Video For Linux API.  Information on
this
API and pointers to "v4l" programs may be found at
[color="#008080"].
To
compile this driver as a module, choose M here: the
module
will be called radio-gemtek.

GemTek
                                        PCI Radio Card support
                               
Choose
Y here if you have this PCI FM radio card.
In
order to control your radio card, you will need to use programs
that
are compatible with the Video for Linux API.  Information on
this
API and pointers to "v4l" programs may be found at
[color="#008080"].
To
compile this driver as a module, choose M here: the
module
will be called radio-gemtek-pci.

Guillemot
                                        MAXI Radio FM 2000 radio
                               
Choose
Y here if you have this radio card.  This card may also be
found
as Gemtek PCI FM.
In
order to control your radio card, you will need to use programs
that
are compatible with the Video For Linux API.  Information on
this
API and pointers to "v4l" programs may be found at
[color="#008080"].
To
compile this driver as a module, choose M here: the
module
will be called radio-maxiradio.

Maestro
                                        on board radio
                               
Say
Y here to directly support the on-board radio tuner on the
Maestro
2 or 2E sound card.
In
order to control your radio card, you will need to use programs
that
are compatible with the Video For Linux API.  Information on
this
API and pointers to "v4l" programs may be found at
[color="#008080"].
To
compile this driver as a module, choose M here: the
module
will be called radio-maestro.

SF16FMI
                                        Radio
                               
Choose
Y here if you have one of these FM radio cards.  If you
compile
the driver into the kernel and your card is not PnP one, you
have
to add "sf16fm=" to the kernel command line (I/O
address is
0x284
or 0x384).
In
order to control your radio card, you will need to use programs
that
are compatible with the Video For Linux API.  Information on
this
API and pointers to "v4l" programs may be found at
[color="#008080"].
To
compile this driver as a module, choose M here: the
module
will be called radio-sf16fmi.

SF16FMR2
                                        Radio
                                       
                               
Choose
Y here if you have one of these FM radio cards.
In
order to control your radio card, you will need to use programs
that
are compatible with the Video For Linux API.  Information on
this
API and pointers to "v4l" programs may be found on the WWW
at
[color="#008080"].
To
compile this driver as a module, choose M here: the
module
will be called radio-sf16fmr2.

TerraTec
                                        ActiveRadio ISA Standalone
                                       
                               
Choose
Y here if you have this FM radio card, and then fill in the
port
address below. (TODO)
Note:
This driver is in its early stages.  Right now volume and
frequency
control and muting works at least for me, but
unfortunately
I have not found anybody who wants to use this card
with
Linux.  So if it is this what YOU are trying to do right now,
PLEASE
DROP ME A NOTE!!  Rolf Offermanns .
In
order to control your radio card, you will need to use programs
that
are compatible with the Video For Linux API.  Information on
this
API and pointers to "v4l" programs may be found at
[color="#008080"].
To
compile this driver as a module, choose M here: the
module
will be called radio-terratec.

Trust
                                        FM radio
                               
This
is a driver for the Trust FM radio cards. Say Y if you have
such
a card and want to use it under Linux.
To
compile this driver as a module, choose M here: the
module
will be called radio-trust.

Typhoon
                                        Radio (a.k.a. EcoRadio)
                               
Choose
Y here if you have one of these FM radio cards, and then fill
in
the port address and the frequency used for muting below.
In
order to control your radio card, you will need to use programs
that
are compatible with the Video For Linux API.  Information on
this
API and pointers to "v4l" programs may be found at
[color="#008080"].
To
compile this driver as a module, choose M here: the
module
will be called radio-typhoon.

Zoltrix
                                        Radio
                                       
                               
Choose
Y here if you have one of these FM radio cards, and then fill
in
the port address below.
In
order to control your radio card, you will need to use programs
that
are compatible with the Video For Linux API.  Information on
this
API and pointers to "v4l" programs may be found at
[color="#008080"].
To
compile this driver as a module, choose M here: the
module
will be called radio-zoltrix.

                               

Digital
                        Video Broadcasting Devices
                       
                       

DVB
                                For Linux DVB
                       
               
Support
for audio/video capture and overlay devices and FM radio
cards.
The exact capabilities of each device vary. User tools for
this
are available from
[color="#008080"].
This
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.
Documentation
for the original API is included in the file
.
Documentation for V4L2 is
available
on the web at .
To
compile this driver as a module, choose M here: the
module
will be called videodev.

DVB
                                        Core Support
                               
DVB
core utility functions for device handling, software fallbacks etc.
Say
Y when you have a DVB card and want to use it. Say Y if your want
to
build your drivers outside the kernel, but need the DVB core. All
in-kernel
drivers will select this automatically if needed.
If
unsure say N.

Graphics
                support
               
               

Support
                        for frame buffer devices
               
       
The
frame buffer device provides an abstraction for the graphics
hardware.
It represents the frame buffer of some video hardware and
allows
application software to access the graphics hardware through
a
well-defined interface, so the software doesn't need to know
anything
about the low-level (hardware register) stuff.
Frame
buffer devices work identically across the different
architectures
supported by Linux and make the implementation of
application
programs easier and more portable; at this point, an X
server
exists which uses the frame buffer device exclusively.
On
several non-X86 architectures, the frame buffer device is the
only
way to use the graphics hardware.
The
device is accessed through special device nodes, usually located
in
the /dev directory, i.e. /dev/fb*.
You
need an utility program called fbset to make full use of frame
buffer
devices. Please read
and
the Framebuffer-HOWTO at
for more
[color="#008080"]information.
Say
Y here and to the driver for your graphics board below if you
are
compiling a kernel for a non-x86 architecture.
If
you are compiling for the x86 architecture, you can say Y if you
want
to play with it, but it is not essential. Please note that
running
graphical applications that directly touch the hardware
(e.g.
an accelerated X server) and that are not frame buffer
device-aware
may cause unexpected results. If unsure, say N.

Virtual
                        Frame Buffer support (ONLY FOR TESTING!)
                       
               
This
is a `virtual' frame buffer device. It operates on a chunk of
unswappable
kernel memory instead of on the memory of a graphics
board.
This means you cannot see any output sent to this frame
buffer
device, while it does consume precious memory. The main use
of
this frame buffer device is testing and debugging the frame
buffer
subsystem. Do NOT enable it for normal systems! To protect
the
innocent, it has to be enabled explicitly at boot time using the
kernel
option `video=vfb:'.
To
compile this driver as a module, choose M here: the
module
will be called vfb.
If
unsure, say N.

Console
                        display driver support
                       
                       

Logo
                        configuration
                       
                       

Backlight
                        & LCD device support
                       
               
Enable
this to be able to choose the drivers for controlling the
backlight
and the LCD panel on some platforms, for example on PDAs.

Sound
               
               
               

Sound
                        card support
                       

Advanced
                        Linux Sound Architecture
                       
                       

Open
                        Sound System
                       
               
               

USB
                support
               
               

MMC/SD
                Card support
               
               

InfiniBand
                support
               
               

EDAC
                - error detection and reporting (RAS) (EXPERIMENTAL)
               
       
               
               
               

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/17431/showart_137796.html