2005-04-16 16:20:36 -06:00
|
|
|
#
|
|
|
|
# Library configuration
|
|
|
|
#
|
|
|
|
|
2009-03-06 09:21:46 -07:00
|
|
|
config BINARY_PRINTF
|
|
|
|
def_bool n
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
menu "Library routines"
|
|
|
|
|
2009-07-13 04:35:12 -06:00
|
|
|
config RAID6_PQ
|
|
|
|
tristate
|
|
|
|
|
2006-12-08 03:36:25 -07:00
|
|
|
config BITREVERSE
|
|
|
|
tristate
|
|
|
|
|
2009-06-11 07:51:15 -06:00
|
|
|
config RATIONAL
|
|
|
|
boolean
|
|
|
|
|
2008-04-25 05:12:53 -06:00
|
|
|
config GENERIC_FIND_FIRST_BIT
|
2008-10-15 23:01:38 -06:00
|
|
|
bool
|
2008-04-25 05:12:53 -06:00
|
|
|
|
2005-04-16 16:20:36 -06: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 05:17:26 -06: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 09:22:42 -06: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 08:17:04 -06: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-16 16:20:36 -06:00
|
|
|
config CRC32
|
|
|
|
tristate "CRC32 functions"
|
|
|
|
default y
|
2006-12-08 03:36:25 -07:00
|
|
|
select BITREVERSE
|
2005-04-16 16:20:36 -06: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 05:04:03 -06: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-16 16:20:36 -06:00
|
|
|
config LIBCRC32C
|
|
|
|
tristate "CRC32c (Castagnoli, et al) Cyclic Redundancy-Check"
|
2008-11-13 07:05:13 -07:00
|
|
|
select CRYPTO
|
2008-11-07 00:11:47 -07:00
|
|
|
select CRYPTO_CRC32C
|
2005-04-16 16:20:36 -06: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 03:22:15 -06: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 01:04:40 -06:00
|
|
|
config AUDIT_GENERIC
|
|
|
|
bool
|
|
|
|
depends on AUDIT && !AUDIT_ARCH
|
|
|
|
default y
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
#
|
|
|
|
# compression support is select'ed if needed
|
|
|
|
#
|
|
|
|
config ZLIB_INFLATE
|
|
|
|
tristate
|
|
|
|
|
|
|
|
config ZLIB_DEFLATE
|
|
|
|
tristate
|
|
|
|
|
2007-07-10 18:22:24 -06:00
|
|
|
config LZO_COMPRESS
|
|
|
|
tristate
|
|
|
|
|
|
|
|
config LZO_DECOMPRESS
|
|
|
|
tristate
|
|
|
|
|
2011-01-12 18:01:22 -07:00
|
|
|
source "lib/xz/Kconfig"
|
|
|
|
|
2009-01-05 14:48:31 -07: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 01:01:43 -07:00
|
|
|
select ZLIB_INFLATE
|
2009-01-05 14:48:31 -07: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-12 18:01:23 -07:00
|
|
|
config DECOMPRESS_XZ
|
|
|
|
select XZ_DEC
|
|
|
|
tristate
|
|
|
|
|
2010-01-08 15:42:46 -07:00
|
|
|
config DECOMPRESS_LZO
|
|
|
|
select LZO_DECOMPRESS
|
|
|
|
tristate
|
|
|
|
|
2005-06-21 18:15:02 -06:00
|
|
|
#
|
|
|
|
# Generic allocator support is selected if needed
|
|
|
|
#
|
|
|
|
config GENERIC_ALLOCATOR
|
|
|
|
boolean
|
|
|
|
|
2005-04-16 16:20:36 -06: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 03:05:32 -07: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-24 18:39:03 -06:00
|
|
|
#
|
|
|
|
# Textsearch support is select'ed if needed
|
|
|
|
#
|
2005-06-23 21:49:30 -06:00
|
|
|
config TEXTSEARCH
|
2005-06-24 18:39:03 -06:00
|
|
|
boolean
|
2005-04-16 16:20:36 -06: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-23 21:58:37 -06:00
|
|
|
config TEXTSEARCH_KMP
|
2005-06-24 18:39:03 -06: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-23 21:58:37 -06:00
|
|
|
|
2005-08-25 17:12:22 -06:00
|
|
|
config TEXTSEARCH_BM
|
2005-08-25 17:23:11 -06:00
|
|
|
tristate
|
2005-08-25 17:12:22 -06:00
|
|
|
|
2005-06-23 21:59:16 -06:00
|
|
|
config TEXTSEARCH_FSM
|
2005-06-24 18:39:03 -06:00
|
|
|
tristate
|
2005-06-23 21:59:16 -06:00
|
|
|
|
2009-11-20 12:13:39 -07:00
|
|
|
config BTREE
|
|
|
|
boolean
|
|
|
|
|
2007-02-11 08:41:31 -07:00
|
|
|
config HAS_IOMEM
|
2006-12-13 01:35:00 -07:00
|
|
|
boolean
|
2007-02-11 08:41:31 -07:00
|
|
|
depends on !NO_IOMEM
|
|
|
|
default y
|
|
|
|
|
|
|
|
config HAS_IOPORT
|
|
|
|
boolean
|
|
|
|
depends on HAS_IOMEM && !NO_IOPORT
|
2006-12-13 01:35:00 -07:00
|
|
|
default y
|
|
|
|
|
2007-05-06 15:49:09 -06:00
|
|
|
config HAS_DMA
|
|
|
|
boolean
|
|
|
|
depends on !NO_DMA
|
|
|
|
default y
|
|
|
|
|
2007-08-22 15:01:36 -06:00
|
|
|
config CHECK_SIGNATURE
|
|
|
|
bool
|
|
|
|
|
2008-12-13 03:50:27 -07: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.
|
|
|
|
|
2008-12-31 16:42:30 -07:00
|
|
|
config DISABLE_OBSOLETE_CPUMASK_FUNCTIONS
|
|
|
|
bool "Disable obsolete cpumask functions" if DEBUG_PER_CPU_MAPS
|
|
|
|
depends on EXPERIMENTAL && BROKEN
|
|
|
|
|
2011-01-19 04:03:25 -07:00
|
|
|
config CPU_RMAP
|
|
|
|
bool
|
|
|
|
depends on SMP
|
|
|
|
|
2009-03-03 23:53:30 -07:00
|
|
|
#
|
|
|
|
# Netlink attribute parsing support is select'ed if needed
|
|
|
|
#
|
|
|
|
config NLATTR
|
|
|
|
bool
|
|
|
|
|
2009-06-12 15:10:05 -06:00
|
|
|
#
|
|
|
|
# Generic 64-bit atomic support is selected if needed
|
|
|
|
#
|
|
|
|
config GENERIC_ATOMIC64
|
|
|
|
bool
|
|
|
|
|
2009-09-25 17:07:19 -06:00
|
|
|
config LRU_CACHE
|
|
|
|
tristate
|
|
|
|
|
2010-11-15 18:58:37 -07:00
|
|
|
config AVERAGE
|
2011-03-01 12:03:05 -07: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-15 18:58:37 -07:00
|
|
|
|
2011-05-31 03:22:16 -06:00
|
|
|
config CORDIC
|
|
|
|
tristate "Cordic function"
|
|
|
|
help
|
|
|
|
The option provides arithmetic function using cordic algorithm
|
|
|
|
so its calculations are in fixed point. Modules can select this
|
|
|
|
when they require this function. Module will be called cordic.
|
|
|
|
|
lib, Add lock-less NULL terminated single list
Cmpxchg is used to implement adding new entry to the list, deleting
all entries from the list, deleting first entry of the list and some
other operations.
Because this is a single list, so the tail can not be accessed in O(1).
If there are multiple producers and multiple consumers, llist_add can
be used in producers and llist_del_all can be used in consumers. They
can work simultaneously without lock. But llist_del_first can not be
used here. Because llist_del_first depends on list->first->next does
not changed if list->first is not changed during its operation, but
llist_del_first, llist_add, llist_add (or llist_del_all, llist_add,
llist_add) sequence in another consumer may violate that.
If there are multiple producers and one consumer, llist_add can be
used in producers and llist_del_all or llist_del_first can be used in
the consumer.
This can be summarized as follow:
| add | del_first | del_all
add | - | - | -
del_first | | L | L
del_all | | | -
Where "-" stands for no lock is needed, while "L" stands for lock is
needed.
The list entries deleted via llist_del_all can be traversed with
traversing function such as llist_for_each etc. But the list entries
can not be traversed safely before deleted from the list. The order
of deleted entries is from the newest to the oldest added one. If you
want to traverse from the oldest to the newest, you must reverse the
order by yourself before traversing.
The basic atomic operation of this list is cmpxchg on long. On
architectures that don't have NMI-safe cmpxchg implementation, the
list can NOT be used in NMI handler. So code uses the list in NMI
handler should depend on CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-12 23:14:23 -06:00
|
|
|
config LLIST
|
|
|
|
bool
|
|
|
|
|
2005-06-23 21:49:30 -06:00
|
|
|
endmenu
|