2005-04-17 02:20:36 +04:00
#
# Library configuration
#
2009-03-06 19:21:46 +03:00
config BINARY_PRINTF
def_bool n
2005-04-17 02:20:36 +04:00
menu "Library routines"
2009-07-13 14:35:12 +04:00
config RAID6_PQ
tristate
2006-12-08 13:36:25 +03:00
config BITREVERSE
tristate
2009-06-11 17:51:15 +04:00
config RATIONAL
boolean
2008-04-25 15:12:53 +04:00
config GENERIC_FIND_FIRST_BIT
2008-10-16 09:01:38 +04:00
bool
2008-04-25 15:12:53 +04:00
2011-11-24 22:45:20 +04:00
config GENERIC_PCI_IOMAP
bool
2011-11-24 16:54:28 +04:00
config GENERIC_IOMAP
bool
2011-11-24 22:45:20 +04:00
select GENERIC_PCI_IOMAP
2011-11-24 16:54:28 +04:00
2005-04-17 02:20:36 +04:00
config CRC_CCITT
tristate "CRC-CCITT functions"
help
This option is provided for the case where no in-kernel-tree
modules require CRC-CCITT functions, but a module built outside
the kernel tree does. Such modules that use library CRC-CCITT
functions require M here.
2005-08-17 15:17:26 +04:00
config CRC16
tristate "CRC16 functions"
help
This option is provided for the case where no in-kernel-tree
modules require CRC16 functions, but a module built outside
the kernel tree does. Such modules that use library CRC16
functions require M here.
2008-06-25 19:22:42 +04:00
config CRC_T10DIF
tristate "CRC calculation for the T10 Data Integrity Field"
help
This option is only needed if a module that's not in the
kernel tree needs to calculate CRC checks for use with the
SCSI data integrity subsystem.
2006-06-12 18:17:04 +04:00
config CRC_ITU_T
tristate "CRC ITU-T V.41 functions"
help
This option is provided for the case where no in-kernel-tree
modules require CRC ITU-T V.41 functions, but a module built outside
the kernel tree does. Such modules that use library CRC ITU-T V.41
functions require M here.
2005-04-17 02:20:36 +04:00
config CRC32
tristate "CRC32 functions"
default y
2006-12-08 13:36:25 +03:00
select BITREVERSE
2005-04-17 02:20:36 +04:00
help
This option is provided for the case where no in-kernel-tree
modules require CRC32 functions, but a module built outside the
kernel tree does. Such modules that use library CRC32 functions
require M here.
2007-07-17 15:04:03 +04:00
config CRC7
tristate "CRC7 functions"
help
This option is provided for the case where no in-kernel-tree
modules require CRC7 functions, but a module built outside
the kernel tree does. Such modules that use library CRC7
functions require M here.
2005-04-17 02:20:36 +04:00
config LIBCRC32C
tristate "CRC32c (Castagnoli, et al) Cyclic Redundancy-Check"
2008-11-13 17:05:13 +03:00
select CRYPTO
2008-11-07 10:11:47 +03:00
select CRYPTO_CRC32C
2005-04-17 02:20:36 +04:00
help
This option is provided for the case where no in-kernel-tree
modules require CRC32c functions, but a module built outside the
kernel tree does. Such modules that use library CRC32c functions
require M here. See Castagnoli93.
Module will be libcrc32c.
2011-05-31 13:22:15 +04:00
config CRC8
tristate "CRC8 function"
help
This option provides CRC8 function. Drivers may select this
when they need to do cyclic redundancy check according CRC8
algorithm. Module will be called crc8.
2006-09-12 11:04:40 +04:00
config AUDIT_GENERIC
bool
depends on AUDIT && !AUDIT_ARCH
default y
2005-04-17 02:20:36 +04:00
#
# compression support is select'ed if needed
#
config ZLIB_INFLATE
tristate
config ZLIB_DEFLATE
tristate
2007-07-11 04:22:24 +04:00
config LZO_COMPRESS
tristate
config LZO_DECOMPRESS
tristate
2011-01-13 04:01:22 +03:00
source "lib/xz/Kconfig"
2009-01-06 00:48:31 +03:00
#
# These all provide a common interface (hence the apparent duplication with
# ZLIB_INFLATE; DECOMPRESS_GZIP is just a wrapper.)
#
config DECOMPRESS_GZIP
2009-01-07 11:01:43 +03:00
select ZLIB_INFLATE
2009-01-06 00:48:31 +03:00
tristate
config DECOMPRESS_BZIP2
tristate
config DECOMPRESS_LZMA
tristate
decompressors: add boot-time XZ support
This implements the API defined in <linux/decompress/generic.h> which is
used for kernel, initramfs, and initrd decompression. This patch together
with the first patch is enough for XZ-compressed initramfs and initrd;
XZ-compressed kernel will need arch-specific changes.
The buffering requirements described in decompress_unxz.c are stricter
than with gzip, so the relevant changes should be done to the
arch-specific code when adding support for XZ-compressed kernel.
Similarly, the heap size in arch-specific pre-boot code may need to be
increased (30 KiB is enough).
The XZ decompressor needs memmove(), memeq() (memcmp() == 0), and
memzero() (memset(ptr, 0, size)), which aren't available in all
arch-specific pre-boot environments. I'm including simple versions in
decompress_unxz.c, but a cleaner solution would naturally be nicer.
Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Alain Knaff <alain@knaff.lu>
Cc: Albin Tonnerre <albin.tonnerre@free-electrons.com>
Cc: Phillip Lougher <phillip@lougher.demon.co.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-01-13 04:01:23 +03:00
config DECOMPRESS_XZ
select XZ_DEC
tristate
2010-01-09 01:42:46 +03:00
config DECOMPRESS_LZO
select LZO_DECOMPRESS
tristate
2005-06-22 04:15:02 +04:00
#
# Generic allocator support is selected if needed
#
config GENERIC_ALLOCATOR
boolean
2005-04-17 02:20:36 +04:00
#
# reed solomon support is select'ed if needed
#
config REED_SOLOMON
tristate
config REED_SOLOMON_ENC8
boolean
config REED_SOLOMON_DEC8
boolean
config REED_SOLOMON_ENC16
boolean
config REED_SOLOMON_DEC16
boolean
lib: add shared BCH ECC library
This is a new software BCH encoding/decoding library, similar to the shared
Reed-Solomon library.
Binary BCH (Bose-Chaudhuri-Hocquenghem) codes are widely used to correct
errors in NAND flash devices requiring more than 1-bit ecc correction; they
are generally better suited for NAND flash than RS codes because NAND bit
errors do not occur in bursts. Latest SLC NAND devices typically require at
least 4-bit ecc protection per 512 bytes block.
This library provides software encoding/decoding, but may also be used with
ASIC/SoC hardware BCH engines to perform error correction. It is being
currently used for this purpose on an OMAP3630 board (4bit/8bit HW BCH). It
has also been used to decode raw dumps of NAND devices with on-die BCH ecc
engines (e.g. Micron 4bit ecc SLC devices).
Latest NAND devices (including SLC) can exhibit high error rates (typically
a dozen or more bitflips per hour during stress tests); in order to
minimize the performance impact of error correction, this library
implements recently developed algorithms for fast polynomial root finding
(see bch.c header for details) instead of the traditional exhaustive Chien
root search; a few performance figures are provided below:
Platform: arm926ejs @ 468 MHz, 32 KiB icache, 16 KiB dcache
BCH ecc : 4-bit per 512 bytes
Encoding average throughput: 250 Mbits/s
Error correction time (compared with Chien search):
average worst average (Chien) worst (Chien)
----------------------------------------------------------
1 bit 8.5 µs 11 µs 200 µs 383 µs
2 bit 9.7 µs 12.5 µs 477 µs 728 µs
3 bit 18.1 µs 20.6 µs 758 µs 1010 µs
4 bit 19.5 µs 23 µs 1028 µs 1280 µs
In the above figures, "worst" is meant in terms of error pattern, not in
terms of cache miss / page faults effects (not taken into account here).
The library has been extensively tested on the following platforms: x86,
x86_64, arm926ejs, omap3630, qemu-ppc64, qemu-mips.
Signed-off-by: Ivan Djelic <ivan.djelic@parrot.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2011-03-11 13:05:32 +03:00
#
# BCH support is selected if needed
#
config BCH
tristate
config BCH_CONST_PARAMS
boolean
help
Drivers may select this option to force specific constant
values for parameters 'm' (Galois field order) and 't'
(error correction capability). Those specific values must
be set by declaring default values for symbols BCH_CONST_M
and BCH_CONST_T.
Doing so will enable extra compiler optimizations,
improving encoding and decoding performance up to 2x for
usual (m,t) values (typically such that m*t < 200).
When this option is selected, the BCH library supports
only a single (m,t) configuration. This is mainly useful
for NAND flash board drivers requiring known, fixed BCH
parameters.
config BCH_CONST_M
int
range 5 15
help
Constant value for Galois field order 'm'. If 'k' is the
number of data bits to protect, 'm' should be chosen such
that (k + m*t) <= 2**m - 1.
Drivers should declare a default value for this symbol if
they select option BCH_CONST_PARAMS.
config BCH_CONST_T
int
help
Constant value for error correction capability in bits 't'.
Drivers should declare a default value for this symbol if
they select option BCH_CONST_PARAMS.
2005-06-25 04:39:03 +04:00
#
# Textsearch support is select'ed if needed
#
2005-06-24 07:49:30 +04:00
config TEXTSEARCH
2005-06-25 04:39:03 +04:00
boolean
2005-04-17 02:20:36 +04:00
[LIB]: Knuth-Morris-Pratt textsearch algorithm
Implements a linear-time string-matching algorithm due to Knuth,
Morris, and Pratt [1]. Their algorithm avoids the explicit
computation of the transition function DELTA altogether. Its
matching time is O(n), for n being length(text), using just an
auxiliary function PI[1..m], for m being length(pattern),
precomputed from the pattern in time O(m). The array PI allows
the transition function DELTA to be computed efficiently
"on the fly" as needed. Roughly speaking, for any state
"q" = 0,1,...,m and any character "a" in SIGMA, the value
PI["q"] contains the information that is independent of "a" and
is needed to compute DELTA("q", "a") [2]. Since the array PI
has only m entries, whereas DELTA has O(m|SIGMA|) entries, we
save a factor of |SIGMA| in the preprocessing time by computing
PI rather than DELTA.
[1] Cormen, Leiserson, Rivest, Stein
Introdcution to Algorithms, 2nd Edition, MIT Press
[2] See finite automation theory
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-24 07:58:37 +04:00
config TEXTSEARCH_KMP
2005-06-25 04:39:03 +04:00
tristate
[LIB]: Knuth-Morris-Pratt textsearch algorithm
Implements a linear-time string-matching algorithm due to Knuth,
Morris, and Pratt [1]. Their algorithm avoids the explicit
computation of the transition function DELTA altogether. Its
matching time is O(n), for n being length(text), using just an
auxiliary function PI[1..m], for m being length(pattern),
precomputed from the pattern in time O(m). The array PI allows
the transition function DELTA to be computed efficiently
"on the fly" as needed. Roughly speaking, for any state
"q" = 0,1,...,m and any character "a" in SIGMA, the value
PI["q"] contains the information that is independent of "a" and
is needed to compute DELTA("q", "a") [2]. Since the array PI
has only m entries, whereas DELTA has O(m|SIGMA|) entries, we
save a factor of |SIGMA| in the preprocessing time by computing
PI rather than DELTA.
[1] Cormen, Leiserson, Rivest, Stein
Introdcution to Algorithms, 2nd Edition, MIT Press
[2] See finite automation theory
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-24 07:58:37 +04:00
2005-08-26 03:12:22 +04:00
config TEXTSEARCH_BM
2005-08-26 03:23:11 +04:00
tristate
2005-08-26 03:12:22 +04:00
2005-06-24 07:59:16 +04:00
config TEXTSEARCH_FSM
2005-06-25 04:39:03 +04:00
tristate
2005-06-24 07:59:16 +04:00
2009-11-20 22:13:39 +03:00
config BTREE
boolean
2007-02-11 18:41:31 +03:00
config HAS_IOMEM
2006-12-13 11:35:00 +03:00
boolean
2007-02-11 18:41:31 +03:00
depends on !NO_IOMEM
default y
config HAS_IOPORT
boolean
depends on HAS_IOMEM && !NO_IOPORT
2006-12-13 11:35:00 +03:00
default y
2007-05-07 01:49:09 +04:00
config HAS_DMA
boolean
depends on !NO_DMA
default y
2007-08-23 01:01:36 +04:00
config CHECK_SIGNATURE
bool
2008-12-13 13:50:27 +03:00
config CPUMASK_OFFSTACK
bool "Force CPU masks off stack" if DEBUG_PER_CPU_MAPS
help
Use dynamic allocation for cpumask_var_t, instead of putting
them on the stack. This is a bit more expensive, but avoids
stack overflow.
2009-01-01 02:42:30 +03:00
config DISABLE_OBSOLETE_CPUMASK_FUNCTIONS
bool "Disable obsolete cpumask functions" if DEBUG_PER_CPU_MAPS
depends on EXPERIMENTAL && BROKEN
2011-01-19 14:03:25 +03:00
config CPU_RMAP
bool
depends on SMP
dql: Dynamic queue limits
Implementation of dynamic queue limits (dql). This is a libary which
allows a queue limit to be dynamically managed. The goal of dql is
to set the queue limit, number of objects to the queue, to be minimized
without allowing the queue to be starved.
dql would be used with a queue which has these properties:
1) Objects are queued up to some limit which can be expressed as a
count of objects.
2) Periodically a completion process executes which retires consumed
objects.
3) Starvation occurs when limit has been reached, all queued data has
actually been consumed but completion processing has not yet run,
so queuing new data is blocked.
4) Minimizing the amount of queued data is desirable.
A canonical example of such a queue would be a NIC HW transmit queue.
The queue limit is dynamic, it will increase or decrease over time
depending on the workload. The queue limit is recalculated each time
completion processing is done. Increases occur when the queue is
starved and can exponentially increase over successive intervals.
Decreases occur when more data is being maintained in the queue than
needed to prevent starvation. The number of extra objects, or "slack",
is measured over successive intervals, and to avoid hysteresis the
limit is only reduced by the miminum slack seen over a configurable
time period.
dql API provides routines to manage the queue:
- dql_init is called to intialize the dql structure
- dql_reset is called to reset dynamic values
- dql_queued called when objects are being enqueued
- dql_avail returns availability in the queue
- dql_completed is called when objects have be consumed in the queue
Configuration consists of:
- max_limit, maximum limit
- min_limit, minimum limit
- slack_hold_time, time to measure instances of slack before reducing
queue limit
Signed-off-by: Tom Herbert <therbert@google.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-11-28 20:32:35 +04:00
config DQL
bool
2009-03-04 09:53:30 +03:00
#
# Netlink attribute parsing support is select'ed if needed
#
config NLATTR
bool
2009-06-13 01:10:05 +04:00
#
# Generic 64-bit atomic support is selected if needed
#
config GENERIC_ATOMIC64
bool
2009-09-26 03:07:19 +04:00
config LRU_CACHE
tristate
2010-11-16 04:58:37 +03:00
config AVERAGE
2011-03-01 22:03:05 +03:00
bool "Averaging functions"
help
This option is provided for the case where no in-kernel-tree
modules require averaging functions, but a module built outside
the kernel tree does. Such modules that use library averaging
functions require Y here.
If unsure, say N.
2010-11-16 04:58:37 +03:00
2011-05-31 13:22:16 +04:00
config CORDIC
2011-07-29 16:59:51 +04:00
tristate "CORDIC algorithm"
2011-05-31 13:22:16 +04:00
help
2011-07-29 17:36:04 +04:00
This option provides an implementation of the CORDIC algorithm;
calculations are in fixed point. Module will be called cordic.
2011-05-31 13:22:16 +04:00
2011-08-31 15:05:16 +04:00
config MPILIB
2012-01-17 19:12:06 +04:00
tristate
2011-08-31 15:05:16 +04:00
help
Multiprecision maths library from GnuPG.
It is used to implement RSA digital signature verification,
which is used by IMA/EVM digital signature extension.
2011-11-07 17:16:37 +04:00
config MPILIB_EXTRA
2012-01-17 19:12:06 +04:00
bool
2011-11-07 17:16:37 +04:00
depends on MPILIB
help
2012-01-17 19:12:05 +04:00
Additional sources of multiprecision maths library from GnuPG.
This code is unnecessary for RSA digital signature verification,
but can be compiled if needed.
2011-11-07 17:16:37 +04:00
2012-01-17 19:12:03 +04:00
config SIGNATURE
2012-01-17 19:12:06 +04:00
tristate
2012-01-17 19:12:04 +04:00
depends on KEYS && CRYPTO
select CRYPTO_SHA1
2011-10-14 16:25:16 +04:00
select MPILIB
help
Digital signature verification. Currently only RSA is supported.
Implementation is done using GnuPG MPI library
2005-06-24 07:49:30 +04:00
endmenu
