2005-04-17 06:20:36 +08:00
|
|
|
#
|
|
|
|
|
# Library configuration
|
|
|
|
|
#
|
|
|
|
|
|
2009-03-07 00:21:46 +08:00
|
|
|
config BINARY_PRINTF
|
|
|
|
|
def_bool n
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
menu "Library routines"
|
|
|
|
|
|
2009-07-13 18:35:12 +08:00
|
|
|
config RAID6_PQ
|
|
|
|
|
tristate
|
|
|
|
|
|
2006-12-08 18:36:25 +08:00
|
|
|
config BITREVERSE
|
|
|
|
|
tristate
|
|
|
|
|
|
2009-06-11 21:51:15 +08:00
|
|
|
config RATIONAL
|
|
|
|
|
boolean
|
|
|
|
|
|
2012-05-25 04:12:28 +08:00
|
|
|
config GENERIC_STRNCPY_FROM_USER
|
|
|
|
|
bool
|
|
|
|
|
|
2012-05-27 02:06:38 +08:00
|
|
|
config GENERIC_STRNLEN_USER
|
|
|
|
|
bool
|
|
|
|
|
|
2013-06-05 00:46:26 +08:00
|
|
|
config GENERIC_NET_UTILS
|
|
|
|
|
bool
|
|
|
|
|
|
2008-04-25 19:12:53 +08:00
|
|
|
config GENERIC_FIND_FIRST_BIT
|
2008-10-16 13:01:38 +08:00
|
|
|
bool
|
2008-04-25 19:12:53 +08:00
|
|
|
|
2012-01-30 06:20:48 +08:00
|
|
|
config NO_GENERIC_PCI_IOPORT_MAP
|
|
|
|
|
bool
|
|
|
|
|
|
2011-11-25 02:45:20 +08:00
|
|
|
config GENERIC_PCI_IOMAP
|
|
|
|
|
bool
|
|
|
|
|
|
2011-11-24 20:54:28 +08:00
|
|
|
config GENERIC_IOMAP
|
|
|
|
|
bool
|
2011-11-25 02:45:20 +08:00
|
|
|
select GENERIC_PCI_IOMAP
|
2011-11-24 20:54:28 +08:00
|
|
|
|
2012-02-07 08:22:46 +08:00
|
|
|
config GENERIC_IO
|
|
|
|
|
boolean
|
|
|
|
|
default n
|
|
|
|
|
|
lib: add support for stmp-style devices
MX23/28 use IP cores which follow a register layout I have first seen on
STMP3xxx SoCs. In this layout, every register actually has four u32:
1.) to store a value directly
2.) a SET register where every 1-bit sets the corresponding bit,
others are unaffected
3.) same with a CLR register
4.) same with a TOG (toggle) register
Also, the 2 MSBs in register 0 are always the same and can be used to reset
the IP core.
All this is strictly speaking not mach-specific (but IP core specific) and,
thus, doesn't need to be in mach-mxs/include. At least mx6 also uses IP cores
following this stmp-style. So:
Introduce a stmp-style device, put the code and defines for that in a public
place (lib/), and let drivers for stmp-style devices select that code.
To avoid regressions and ease reviewing, the actual code is simply copied from
mach-mxs. It definately wants updates, but those need a seperate patch series.
Voila, mach dependency gone, reusable code introduced. Note that I didn't
remove the duplicated code from mach-mxs yet, first the drivers have to be
converted.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Dong Aisheng <dong.aisheng@linaro.org>
2011-09-01 02:35:40 +08:00
|
|
|
config STMP_DEVICE
|
|
|
|
|
bool
|
|
|
|
|
|
2012-12-18 08:01:39 +08:00
|
|
|
config PERCPU_RWSEM
|
|
|
|
|
boolean
|
|
|
|
|
|
lockref: implement lockless reference count updates using cmpxchg()
Instead of taking the spinlock, the lockless versions atomically check
that the lock is not taken, and do the reference count update using a
cmpxchg() loop. This is semantically identical to doing the reference
count update protected by the lock, but avoids the "wait for lock"
contention that you get when accesses to the reference count are
contended.
Note that a "lockref" is absolutely _not_ equivalent to an atomic_t.
Even when the lockref reference counts are updated atomically with
cmpxchg, the fact that they also verify the state of the spinlock means
that the lockless updates can never happen while somebody else holds the
spinlock.
So while "lockref_put_or_lock()" looks a lot like just another name for
"atomic_dec_and_lock()", and both optimize to lockless updates, they are
fundamentally different: the decrement done by atomic_dec_and_lock() is
truly independent of any lock (as long as it doesn't decrement to zero),
so a locked region can still see the count change.
The lockref structure, in contrast, really is a *locked* reference
count. If you hold the spinlock, the reference count will be stable and
you can modify the reference count without using atomics, because even
the lockless updates will see and respect the state of the lock.
In order to enable the cmpxchg lockless code, the architecture needs to
do three things:
(1) Make sure that the "arch_spinlock_t" and an "unsigned int" can fit
in an aligned u64, and have a "cmpxchg()" implementation that works
on such a u64 data type.
(2) define a helper function to test for a spinlock being unlocked
("arch_spin_value_unlocked()")
(3) select the "ARCH_USE_CMPXCHG_LOCKREF" config variable in its
Kconfig file.
This enables it for x86-64 (but not 32-bit, we'd need to make sure
cmpxchg() turns into the proper cmpxchg8b in order to enable it for
32-bit mode).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-09-03 03:12:15 +08:00
|
|
|
config ARCH_USE_CMPXCHG_LOCKREF
|
|
|
|
|
bool
|
|
|
|
|
|
2005-04-17 06:20:36 +08: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 19:17:26 +08: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 23:22:42 +08:00
|
|
|
config CRC_T10DIF
|
|
|
|
|
tristate "CRC calculation for the T10 Data Integrity Field"
|
2013-09-07 10:56:26 +08:00
|
|
|
select CRYPTO
|
|
|
|
|
select CRYPTO_CRCT10DIF
|
2008-06-25 23:22:42 +08:00
|
|
|
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 22:17:04 +08: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 06:20:36 +08:00
|
|
|
config CRC32
|
2012-03-24 06:02:25 +08:00
|
|
|
tristate "CRC32/CRC32c functions"
|
2005-04-17 06:20:36 +08:00
|
|
|
default y
|
2006-12-08 18:36:25 +08:00
|
|
|
select BITREVERSE
|
2005-04-17 06:20:36 +08:00
|
|
|
help
|
|
|
|
|
This option is provided for the case where no in-kernel-tree
|
2012-03-24 06:02:25 +08:00
|
|
|
modules require CRC32/CRC32c functions, but a module built outside
|
|
|
|
|
the kernel tree does. Such modules that use library CRC32/CRC32c
|
|
|
|
|
functions require M here.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-03-24 06:02:22 +08:00
|
|
|
config CRC32_SELFTEST
|
|
|
|
|
bool "CRC32 perform self test on init"
|
|
|
|
|
default n
|
|
|
|
|
depends on CRC32
|
|
|
|
|
help
|
|
|
|
|
This option enables the CRC32 library functions to perform a
|
|
|
|
|
self test on initialization. The self test computes crc32_le
|
|
|
|
|
and crc32_be over byte strings with random alignment and length
|
|
|
|
|
and computes the total elapsed time and number of bytes processed.
|
|
|
|
|
|
2012-03-24 06:02:26 +08:00
|
|
|
choice
|
|
|
|
|
prompt "CRC32 implementation"
|
|
|
|
|
depends on CRC32
|
|
|
|
|
default CRC32_SLICEBY8
|
2012-03-29 05:42:56 +08:00
|
|
|
help
|
|
|
|
|
This option allows a kernel builder to override the default choice
|
|
|
|
|
of CRC32 algorithm. Choose the default ("slice by 8") unless you
|
|
|
|
|
know that you need one of the others.
|
2012-03-24 06:02:26 +08:00
|
|
|
|
|
|
|
|
config CRC32_SLICEBY8
|
|
|
|
|
bool "Slice by 8 bytes"
|
|
|
|
|
help
|
|
|
|
|
Calculate checksum 8 bytes at a time with a clever slicing algorithm.
|
|
|
|
|
This is the fastest algorithm, but comes with a 8KiB lookup table.
|
|
|
|
|
Most modern processors have enough cache to hold this table without
|
|
|
|
|
thrashing the cache.
|
|
|
|
|
|
|
|
|
|
This is the default implementation choice. Choose this one unless
|
|
|
|
|
you have a good reason not to.
|
|
|
|
|
|
|
|
|
|
config CRC32_SLICEBY4
|
|
|
|
|
bool "Slice by 4 bytes"
|
|
|
|
|
help
|
|
|
|
|
Calculate checksum 4 bytes at a time with a clever slicing algorithm.
|
|
|
|
|
This is a bit slower than slice by 8, but has a smaller 4KiB lookup
|
|
|
|
|
table.
|
|
|
|
|
|
|
|
|
|
Only choose this option if you know what you are doing.
|
|
|
|
|
|
|
|
|
|
config CRC32_SARWATE
|
|
|
|
|
bool "Sarwate's Algorithm (one byte at a time)"
|
|
|
|
|
help
|
|
|
|
|
Calculate checksum a byte at a time using Sarwate's algorithm. This
|
|
|
|
|
is not particularly fast, but has a small 256 byte lookup table.
|
|
|
|
|
|
|
|
|
|
Only choose this option if you know what you are doing.
|
|
|
|
|
|
|
|
|
|
config CRC32_BIT
|
|
|
|
|
bool "Classic Algorithm (one bit at a time)"
|
|
|
|
|
help
|
|
|
|
|
Calculate checksum one bit at a time. This is VERY slow, but has
|
|
|
|
|
no lookup table. This is provided as a debugging option.
|
|
|
|
|
|
|
|
|
|
Only choose this option if you are debugging crc32.
|
|
|
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
|
2007-07-17 19:04:03 +08: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 06:20:36 +08:00
|
|
|
config LIBCRC32C
|
|
|
|
|
tristate "CRC32c (Castagnoli, et al) Cyclic Redundancy-Check"
|
2008-11-13 22:05:13 +08:00
|
|
|
select CRYPTO
|
2008-11-07 15:11:47 +08:00
|
|
|
select CRYPTO_CRC32C
|
2005-04-17 06:20:36 +08: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 17:22:15 +08: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 15:04:40 +08:00
|
|
|
config AUDIT_GENERIC
|
|
|
|
|
bool
|
|
|
|
|
depends on AUDIT && !AUDIT_ARCH
|
|
|
|
|
default y
|
|
|
|
|
|
2014-03-15 13:48:00 +08:00
|
|
|
config AUDIT_ARCH_COMPAT_GENERIC
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
|
|
|
|
config AUDIT_COMPAT_GENERIC
|
|
|
|
|
bool
|
|
|
|
|
depends on AUDIT_GENERIC && AUDIT_ARCH_COMPAT_GENERIC && COMPAT
|
|
|
|
|
default y
|
|
|
|
|
|
2013-11-11 19:20:37 +08:00
|
|
|
config RANDOM32_SELFTEST
|
|
|
|
|
bool "PRNG perform self test on init"
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
This option enables the 32 bit PRNG library functions to perform a
|
|
|
|
|
self test on initialization.
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
#
|
|
|
|
|
# compression support is select'ed if needed
|
|
|
|
|
#
|
|
|
|
|
config ZLIB_INFLATE
|
|
|
|
|
tristate
|
|
|
|
|
|
|
|
|
|
config ZLIB_DEFLATE
|
|
|
|
|
tristate
|
|
|
|
|
|
2007-07-11 08:22:24 +08:00
|
|
|
config LZO_COMPRESS
|
|
|
|
|
tristate
|
|
|
|
|
|
|
|
|
|
config LZO_DECOMPRESS
|
|
|
|
|
tristate
|
|
|
|
|
|
2013-07-09 07:01:49 +08:00
|
|
|
config LZ4_COMPRESS
|
|
|
|
|
tristate
|
|
|
|
|
|
|
|
|
|
config LZ4HC_COMPRESS
|
|
|
|
|
tristate
|
|
|
|
|
|
2013-07-09 07:01:46 +08:00
|
|
|
config LZ4_DECOMPRESS
|
|
|
|
|
tristate
|
|
|
|
|
|
2011-01-13 09:01:22 +08:00
|
|
|
source "lib/xz/Kconfig"
|
|
|
|
|
|
2009-01-06 05:48:31 +08: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 16:01:43 +08:00
|
|
|
select ZLIB_INFLATE
|
2009-01-06 05:48:31 +08: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 09:01:23 +08:00
|
|
|
config DECOMPRESS_XZ
|
|
|
|
|
select XZ_DEC
|
|
|
|
|
tristate
|
|
|
|
|
|
2010-01-09 06:42:46 +08:00
|
|
|
config DECOMPRESS_LZO
|
|
|
|
|
select LZO_DECOMPRESS
|
|
|
|
|
tristate
|
|
|
|
|
|
2013-07-09 07:01:46 +08:00
|
|
|
config DECOMPRESS_LZ4
|
|
|
|
|
select LZ4_DECOMPRESS
|
|
|
|
|
tristate
|
|
|
|
|
|
2005-06-22 08:15:02 +08:00
|
|
|
#
|
|
|
|
|
# Generic allocator support is selected if needed
|
|
|
|
|
#
|
|
|
|
|
config GENERIC_ALLOCATOR
|
|
|
|
|
boolean
|
|
|
|
|
|
2005-04-17 06:20:36 +08: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 18:05:32 +08: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 08:39:03 +08:00
|
|
|
#
|
|
|
|
|
# Textsearch support is select'ed if needed
|
|
|
|
|
#
|
2005-06-24 11:49:30 +08:00
|
|
|
config TEXTSEARCH
|
2005-06-25 08:39:03 +08:00
|
|
|
boolean
|
2005-04-17 06:20:36 +08: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 11:58:37 +08:00
|
|
|
config TEXTSEARCH_KMP
|
2005-06-25 08:39:03 +08: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 11:58:37 +08:00
|
|
|
|
2005-08-26 07:12:22 +08:00
|
|
|
config TEXTSEARCH_BM
|
2005-08-26 07:23:11 +08:00
|
|
|
tristate
|
2005-08-26 07:12:22 +08:00
|
|
|
|
2005-06-24 11:59:16 +08:00
|
|
|
config TEXTSEARCH_FSM
|
2005-06-25 08:39:03 +08:00
|
|
|
tristate
|
2005-06-24 11:59:16 +08:00
|
|
|
|
2009-11-21 03:13:39 +08:00
|
|
|
config BTREE
|
|
|
|
|
boolean
|
|
|
|
|
|
Add a generic associative array implementation.
Add a generic associative array implementation that can be used as the
container for keyrings, thereby massively increasing the capacity available
whilst also speeding up searching in keyrings that contain a lot of keys.
This may also be useful in FS-Cache for tracking cookies.
Documentation is added into Documentation/associative_array.txt
Some of the properties of the implementation are:
(1) Objects are opaque pointers. The implementation does not care where they
point (if anywhere) or what they point to (if anything).
[!] NOTE: Pointers to objects _must_ be zero in the two least significant
bits.
(2) Objects do not need to contain linkage blocks for use by the array. This
permits an object to be located in multiple arrays simultaneously.
Rather, the array is made up of metadata blocks that point to objects.
(3) Objects are labelled as being one of two types (the type is a bool value).
This information is stored in the array, but has no consequence to the
array itself or its algorithms.
(4) Objects require index keys to locate them within the array.
(5) Index keys must be unique. Inserting an object with the same key as one
already in the array will replace the old object.
(6) Index keys can be of any length and can be of different lengths.
(7) Index keys should encode the length early on, before any variation due to
length is seen.
(8) Index keys can include a hash to scatter objects throughout the array.
(9) The array can iterated over. The objects will not necessarily come out in
key order.
(10) The array can be iterated whilst it is being modified, provided the RCU
readlock is being held by the iterator. Note, however, under these
circumstances, some objects may be seen more than once. If this is a
problem, the iterator should lock against modification. Objects will not
be missed, however, unless deleted.
(11) Objects in the array can be looked up by means of their index key.
(12) Objects can be looked up whilst the array is being modified, provided the
RCU readlock is being held by the thread doing the look up.
The implementation uses a tree of 16-pointer nodes internally that are indexed
on each level by nibbles from the index key. To improve memory efficiency,
shortcuts can be emplaced to skip over what would otherwise be a series of
single-occupancy nodes. Further, nodes pack leaf object pointers into spare
space in the node rather than making an extra branch until as such time an
object needs to be added to a full node.
Signed-off-by: David Howells <dhowells@redhat.com>
2013-09-24 17:35:17 +08:00
|
|
|
config ASSOCIATIVE_ARRAY
|
|
|
|
|
bool
|
|
|
|
|
help
|
|
|
|
|
Generic associative array. Can be searched and iterated over whilst
|
|
|
|
|
it is being modified. It is also reasonably quick to search and
|
|
|
|
|
modify. The algorithms are non-recursive, and the trees are highly
|
|
|
|
|
capacious.
|
|
|
|
|
|
|
|
|
|
See:
|
|
|
|
|
|
|
|
|
|
Documentation/assoc_array.txt
|
|
|
|
|
|
|
|
|
|
for more information.
|
|
|
|
|
|
2007-02-11 23:41:31 +08:00
|
|
|
config HAS_IOMEM
|
2006-12-13 16:35:00 +08:00
|
|
|
boolean
|
2007-02-11 23:41:31 +08:00
|
|
|
depends on !NO_IOMEM
|
2012-02-07 08:22:46 +08:00
|
|
|
select GENERIC_IO
|
2007-02-11 23:41:31 +08:00
|
|
|
default y
|
|
|
|
|
|
2014-04-08 06:39:19 +08:00
|
|
|
config HAS_IOPORT_MAP
|
2007-02-11 23:41:31 +08:00
|
|
|
boolean
|
2014-04-08 06:39:19 +08:00
|
|
|
depends on HAS_IOMEM && !NO_IOPORT_MAP
|
2006-12-13 16:35:00 +08:00
|
|
|
default y
|
|
|
|
|
|
2007-05-07 05:49:09 +08:00
|
|
|
config HAS_DMA
|
|
|
|
|
boolean
|
|
|
|
|
depends on !NO_DMA
|
|
|
|
|
default y
|
|
|
|
|
|
2007-08-23 05:01:36 +08:00
|
|
|
config CHECK_SIGNATURE
|
|
|
|
|
bool
|
|
|
|
|
|
2008-12-13 18:50:27 +08: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 07:42:30 +08:00
|
|
|
config DISABLE_OBSOLETE_CPUMASK_FUNCTIONS
|
|
|
|
|
bool "Disable obsolete cpumask functions" if DEBUG_PER_CPU_MAPS
|
2013-01-17 10:54:16 +08:00
|
|
|
depends on BROKEN
|
2009-01-01 07:42:30 +08:00
|
|
|
|
2011-01-19 19:03:25 +08: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-29 00:32:35 +08:00
|
|
|
config DQL
|
|
|
|
|
bool
|
|
|
|
|
|
2009-03-04 14:53:30 +08:00
|
|
|
#
|
|
|
|
|
# Netlink attribute parsing support is select'ed if needed
|
|
|
|
|
#
|
|
|
|
|
config NLATTR
|
|
|
|
|
bool
|
|
|
|
|
|
2009-06-13 05:10:05 +08:00
|
|
|
#
|
|
|
|
|
# Generic 64-bit atomic support is selected if needed
|
|
|
|
|
#
|
|
|
|
|
config GENERIC_ATOMIC64
|
|
|
|
|
bool
|
|
|
|
|
|
2012-07-31 05:41:09 +08:00
|
|
|
config ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
|
|
|
|
|
def_bool y if GENERIC_ATOMIC64
|
|
|
|
|
|
2009-09-26 07:07:19 +08:00
|
|
|
config LRU_CACHE
|
|
|
|
|
tristate
|
|
|
|
|
|
2010-11-16 09:58:37 +08:00
|
|
|
config AVERAGE
|
2011-03-02 03:03:05 +08: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 09:58:37 +08:00
|
|
|
|
2012-02-02 06:17:54 +08:00
|
|
|
config CLZ_TAB
|
|
|
|
|
bool
|
|
|
|
|
|
2011-05-31 17:22:16 +08:00
|
|
|
config CORDIC
|
2011-07-29 20:59:51 +08:00
|
|
|
tristate "CORDIC algorithm"
|
2011-05-31 17:22:16 +08:00
|
|
|
help
|
2011-07-29 21:36:04 +08:00
|
|
|
This option provides an implementation of the CORDIC algorithm;
|
|
|
|
|
calculations are in fixed point. Module will be called cordic.
|
2011-05-31 17:22:16 +08:00
|
|
|
|
2012-04-27 20:24:03 +08:00
|
|
|
config DDR
|
|
|
|
|
bool "JEDEC DDR data"
|
|
|
|
|
help
|
|
|
|
|
Data from JEDEC specs for DDR SDRAM memories,
|
|
|
|
|
particularly the AC timing parameters and addressing
|
|
|
|
|
information. This data is useful for drivers handling
|
|
|
|
|
DDR SDRAM controllers.
|
|
|
|
|
|
2011-08-31 19:05:16 +08:00
|
|
|
config MPILIB
|
2012-01-17 23:12:06 +08:00
|
|
|
tristate
|
2012-02-02 06:17:54 +08:00
|
|
|
select CLZ_TAB
|
2011-08-31 19:05:16 +08: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.
|
|
|
|
|
|
2012-01-17 23:12:03 +08:00
|
|
|
config SIGNATURE
|
2012-01-17 23:12:06 +08:00
|
|
|
tristate
|
2012-01-17 23:12:04 +08:00
|
|
|
depends on KEYS && CRYPTO
|
|
|
|
|
select CRYPTO_SHA1
|
2011-10-14 20:25:16 +08:00
|
|
|
select MPILIB
|
|
|
|
|
help
|
|
|
|
|
Digital signature verification. Currently only RSA is supported.
|
|
|
|
|
Implementation is done using GnuPG MPI library
|
|
|
|
|
|
2012-07-06 00:12:38 +08:00
|
|
|
#
|
|
|
|
|
# libfdt files, only selected if needed.
|
|
|
|
|
#
|
|
|
|
|
config LIBFDT
|
|
|
|
|
bool
|
|
|
|
|
|
2012-09-22 06:30:46 +08:00
|
|
|
config OID_REGISTRY
|
|
|
|
|
tristate
|
|
|
|
|
help
|
|
|
|
|
Enable fast lookup object identifier registry.
|
|
|
|
|
|
2013-04-16 04:09:45 +08:00
|
|
|
config UCS2_STRING
|
|
|
|
|
tristate
|
|
|
|
|
|
2013-06-09 17:46:43 +08:00
|
|
|
source "lib/fonts/Kconfig"
|
|
|
|
|
|
2005-06-24 11:49:30 +08:00
|
|
|
endmenu
|