|
|
|
|
#
|
|
|
|
|
# Library configuration
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
config BINARY_PRINTF
|
|
|
|
|
def_bool n
|
|
|
|
|
|
|
|
|
|
menu "Library routines"
|
|
|
|
|
|
|
|
|
|
config RAID6_PQ
|
|
|
|
|
tristate
|
|
|
|
|
|
|
|
|
|
config BITREVERSE
|
|
|
|
|
tristate
|
|
|
|
|
|
|
|
|
|
config HAVE_ARCH_BITREVERSE
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
depends on BITREVERSE
|
|
|
|
|
help
|
|
|
|
|
This option enables the use of hardware bit-reversal instructions on
|
|
|
|
|
architectures which support such operations.
|
|
|
|
|
|
|
|
|
|
config RATIONAL
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config GENERIC_STRNCPY_FROM_USER
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config GENERIC_STRNLEN_USER
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config GENERIC_NET_UTILS
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config GENERIC_FIND_FIRST_BIT
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config NO_GENERIC_PCI_IOPORT_MAP
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config GENERIC_PCI_IOMAP
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config GENERIC_IOMAP
|
|
|
|
|
bool
|
|
|
|
|
select GENERIC_PCI_IOMAP
|
|
|
|
|
|
|
|
|
|
config GENERIC_IO
|
|
|
|
|
bool
|
|
|
|
|
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>
14 years ago
|
|
|
config STMP_DEVICE
|
|
|
|
|
bool
|
|
|
|
|
|
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>
11 years ago
|
|
|
config ARCH_USE_CMPXCHG_LOCKREF
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config ARCH_HAS_FAST_MULTIPLIER
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
config CRC_T10DIF
|
|
|
|
|
tristate "CRC calculation for the T10 Data Integrity Field"
|
|
|
|
|
select CRYPTO
|
|
|
|
|
select CRYPTO_CRCT10DIF
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
config CRC32
|
|
|
|
|
tristate "CRC32/CRC32c functions"
|
|
|
|
|
default y
|
|
|
|
|
select BITREVERSE
|
|
|
|
|
help
|
|
|
|
|
This option is provided for the case where no in-kernel-tree
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
config CRC32_SELFTEST
|
|
|
|
|
tristate "CRC32 perform self test on init"
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
choice
|
|
|
|
|
prompt "CRC32 implementation"
|
|
|
|
|
depends on CRC32
|
|
|
|
|
default CRC32_SLICEBY8
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
config CRC4
|
|
|
|
|
tristate "CRC4 functions"
|
|
|
|
|
help
|
|
|
|
|
This option is provided for the case where no in-kernel-tree
|
|
|
|
|
modules require CRC4 functions, but a module built outside
|
|
|
|
|
the kernel tree does. Such modules that use library CRC4
|
|
|
|
|
functions require M here.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
config LIBCRC32C
|
|
|
|
|
tristate "CRC32c (Castagnoli, et al) Cyclic Redundancy-Check"
|
|
|
|
|
select CRYPTO
|
|
|
|
|
select CRYPTO_CRC32C
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
lib: Add xxhash module
Adds xxhash kernel module with xxh32 and xxh64 hashes. xxhash is an
extremely fast non-cryptographic hash algorithm for checksumming.
The zstd compression and decompression modules added in the next patch
require xxhash. I extracted it out from zstd since it is useful on its
own. I copied the code from the upstream XXHash source repository and
translated it into kernel style. I ran benchmarks and tests in the kernel
and tests in userland.
I benchmarked xxhash as a special character device. I ran in four modes,
no-op, xxh32, xxh64, and crc32. The no-op mode simply copies the data to
kernel space and ignores it. The xxh32, xxh64, and crc32 modes compute
hashes on the copied data. I also ran it with four different buffer sizes.
The benchmark file is located in the upstream zstd source repository under
`contrib/linux-kernel/xxhash_test.c` [1].
I ran the benchmarks on a Ubuntu 14.04 VM with 2 cores and 4 GiB of RAM.
The VM is running on a MacBook Pro with a 3.1 GHz Intel Core i7 processor,
16 GB of RAM, and a SSD. I benchmarked using the file `filesystem.squashfs`
from `ubuntu-16.10-desktop-amd64.iso`, which is 1,536,217,088 B large.
Run the following commands for the benchmark:
modprobe xxhash_test
mknod xxhash_test c 245 0
time cp filesystem.squashfs xxhash_test
The time is reported by the time of the userland `cp`.
The GB/s is computed with
1,536,217,008 B / time(buffer size, hash)
which includes the time to copy from userland.
The Normalized GB/s is computed with
1,536,217,088 B / (time(buffer size, hash) - time(buffer size, none)).
| Buffer Size (B) | Hash | Time (s) | GB/s | Adjusted GB/s |
|-----------------|-------|----------|------|---------------|
| 1024 | none | 0.408 | 3.77 | - |
| 1024 | xxh32 | 0.649 | 2.37 | 6.37 |
| 1024 | xxh64 | 0.542 | 2.83 | 11.46 |
| 1024 | crc32 | 1.290 | 1.19 | 1.74 |
| 4096 | none | 0.380 | 4.04 | - |
| 4096 | xxh32 | 0.645 | 2.38 | 5.79 |
| 4096 | xxh64 | 0.500 | 3.07 | 12.80 |
| 4096 | crc32 | 1.168 | 1.32 | 1.95 |
| 8192 | none | 0.351 | 4.38 | - |
| 8192 | xxh32 | 0.614 | 2.50 | 5.84 |
| 8192 | xxh64 | 0.464 | 3.31 | 13.60 |
| 8192 | crc32 | 1.163 | 1.32 | 1.89 |
| 16384 | none | 0.346 | 4.43 | - |
| 16384 | xxh32 | 0.590 | 2.60 | 6.30 |
| 16384 | xxh64 | 0.466 | 3.30 | 12.80 |
| 16384 | crc32 | 1.183 | 1.30 | 1.84 |
Tested in userland using the test-suite in the zstd repo under
`contrib/linux-kernel/test/XXHashUserlandTest.cpp` [2] by mocking the
kernel functions. A line in each branch of every function in `xxhash.c`
was commented out to ensure that the test-suite fails. Additionally
tested while testing zstd and with SMHasher [3].
[1] https://phabricator.intern.facebook.com/P57526246
[2] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/test/XXHashUserlandTest.cpp
[3] https://github.com/aappleby/smhasher
zstd source repository: https://github.com/facebook/zstd
XXHash source repository: https://github.com/cyan4973/xxhash
Signed-off-by: Nick Terrell <terrelln@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
7 years ago
|
|
|
config XXHASH
|
|
|
|
|
tristate
|
|
|
|
|
|
|
|
|
|
config AUDIT_GENERIC
|
|
|
|
|
bool
|
|
|
|
|
depends on AUDIT && !AUDIT_ARCH
|
|
|
|
|
default y
|
|
|
|
|
|
|
|
|
|
config AUDIT_ARCH_COMPAT_GENERIC
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
|
|
|
|
config AUDIT_COMPAT_GENERIC
|
|
|
|
|
bool
|
|
|
|
|
depends on AUDIT_GENERIC && AUDIT_ARCH_COMPAT_GENERIC && COMPAT
|
|
|
|
|
default y
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# compression support is select'ed if needed
|
|
|
|
|
#
|
|
|
|
|
config 842_COMPRESS
|
|
|
|
|
select CRC32
|
|
|
|
|
tristate
|
|
|
|
|
|
|
|
|
|
config 842_DECOMPRESS
|
|
|
|
|
select CRC32
|
|
|
|
|
tristate
|
|
|
|
|
|
|
|
|
|
config ZLIB_INFLATE
|
|
|
|
|
tristate
|
|
|
|
|
|
|
|
|
|
config ZLIB_DEFLATE
|
|
|
|
|
tristate
|
|
|
|
|
select BITREVERSE
|
|
|
|
|
|
|
|
|
|
config LZO_COMPRESS
|
|
|
|
|
tristate
|
|
|
|
|
|
|
|
|
|
config LZO_DECOMPRESS
|
|
|
|
|
tristate
|
|
|
|
|
|
|
|
|
|
config LZ4_COMPRESS
|
|
|
|
|
tristate
|
|
|
|
|
|
|
|
|
|
config LZ4HC_COMPRESS
|
|
|
|
|
tristate
|
|
|
|
|
|
|
|
|
|
config LZ4_DECOMPRESS
|
|
|
|
|
tristate
|
|
|
|
|
|
lib: Add zstd modules
Add zstd compression and decompression kernel modules.
zstd offers a wide varity of compression speed and quality trade-offs.
It can compress at speeds approaching lz4, and quality approaching lzma.
zstd decompressions at speeds more than twice as fast as zlib, and
decompression speed remains roughly the same across all compression levels.
The code was ported from the upstream zstd source repository. The
`linux/zstd.h` header was modified to match linux kernel style.
The cross-platform and allocation code was stripped out. Instead zstd
requires the caller to pass a preallocated workspace. The source files
were clang-formatted [1] to match the Linux Kernel style as much as
possible. Otherwise, the code was unmodified. We would like to avoid
as much further manual modification to the source code as possible, so it
will be easier to keep the kernel zstd up to date.
I benchmarked zstd compression as a special character device. I ran zstd
and zlib compression at several levels, as well as performing no
compression, which measure the time spent copying the data to kernel space.
Data is passed to the compresser 4096 B at a time. The benchmark file is
located in the upstream zstd source repository under
`contrib/linux-kernel/zstd_compress_test.c` [2].
I ran the benchmarks on a Ubuntu 14.04 VM with 2 cores and 4 GiB of RAM.
The VM is running on a MacBook Pro with a 3.1 GHz Intel Core i7 processor,
16 GB of RAM, and a SSD. I benchmarked using `silesia.tar` [3], which is
211,988,480 B large. Run the following commands for the benchmark:
sudo modprobe zstd_compress_test
sudo mknod zstd_compress_test c 245 0
sudo cp silesia.tar zstd_compress_test
The time is reported by the time of the userland `cp`.
The MB/s is computed with
1,536,217,008 B / time(buffer size, hash)
which includes the time to copy from userland.
The Adjusted MB/s is computed with
1,536,217,088 B / (time(buffer size, hash) - time(buffer size, none)).
The memory reported is the amount of memory the compressor requests.
| Method | Size (B) | Time (s) | Ratio | MB/s | Adj MB/s | Mem (MB) |
|----------|----------|----------|-------|---------|----------|----------|
| none | 11988480 | 0.100 | 1 | 2119.88 | - | - |
| zstd -1 | 73645762 | 1.044 | 2.878 | 203.05 | 224.56 | 1.23 |
| zstd -3 | 66988878 | 1.761 | 3.165 | 120.38 | 127.63 | 2.47 |
| zstd -5 | 65001259 | 2.563 | 3.261 | 82.71 | 86.07 | 2.86 |
| zstd -10 | 60165346 | 13.242 | 3.523 | 16.01 | 16.13 | 13.22 |
| zstd -15 | 58009756 | 47.601 | 3.654 | 4.45 | 4.46 | 21.61 |
| zstd -19 | 54014593 | 102.835 | 3.925 | 2.06 | 2.06 | 60.15 |
| zlib -1 | 77260026 | 2.895 | 2.744 | 73.23 | 75.85 | 0.27 |
| zlib -3 | 72972206 | 4.116 | 2.905 | 51.50 | 52.79 | 0.27 |
| zlib -6 | 68190360 | 9.633 | 3.109 | 22.01 | 22.24 | 0.27 |
| zlib -9 | 67613382 | 22.554 | 3.135 | 9.40 | 9.44 | 0.27 |
I benchmarked zstd decompression using the same method on the same machine.
The benchmark file is located in the upstream zstd repo under
`contrib/linux-kernel/zstd_decompress_test.c` [4]. The memory reported is
the amount of memory required to decompress data compressed with the given
compression level. If you know the maximum size of your input, you can
reduce the memory usage of decompression irrespective of the compression
level.
| Method | Time (s) | MB/s | Adjusted MB/s | Memory (MB) |
|----------|----------|---------|---------------|-------------|
| none | 0.025 | 8479.54 | - | - |
| zstd -1 | 0.358 | 592.15 | 636.60 | 0.84 |
| zstd -3 | 0.396 | 535.32 | 571.40 | 1.46 |
| zstd -5 | 0.396 | 535.32 | 571.40 | 1.46 |
| zstd -10 | 0.374 | 566.81 | 607.42 | 2.51 |
| zstd -15 | 0.379 | 559.34 | 598.84 | 4.61 |
| zstd -19 | 0.412 | 514.54 | 547.77 | 8.80 |
| zlib -1 | 0.940 | 225.52 | 231.68 | 0.04 |
| zlib -3 | 0.883 | 240.08 | 247.07 | 0.04 |
| zlib -6 | 0.844 | 251.17 | 258.84 | 0.04 |
| zlib -9 | 0.837 | 253.27 | 287.64 | 0.04 |
Tested in userland using the test-suite in the zstd repo under
`contrib/linux-kernel/test/UserlandTest.cpp` [5] by mocking the kernel
functions. Fuzz tested using libfuzzer [6] with the fuzz harnesses under
`contrib/linux-kernel/test/{RoundTripCrash.c,DecompressCrash.c}` [7] [8]
with ASAN, UBSAN, and MSAN. Additionaly, it was tested while testing the
BtrFS and SquashFS patches coming next.
[1] https://clang.llvm.org/docs/ClangFormat.html
[2] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/zstd_compress_test.c
[3] http://sun.aei.polsl.pl/~sdeor/index.php?page=silesia
[4] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/zstd_decompress_test.c
[5] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/test/UserlandTest.cpp
[6] http://llvm.org/docs/LibFuzzer.html
[7] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/test/RoundTripCrash.c
[8] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/test/DecompressCrash.c
zstd source repository: https://github.com/facebook/zstd
Signed-off-by: Nick Terrell <terrelln@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
7 years ago
|
|
|
config ZSTD_COMPRESS
|
|
|
|
|
select XXHASH
|
|
|
|
|
tristate
|
|
|
|
|
|
|
|
|
|
config ZSTD_DECOMPRESS
|
|
|
|
|
select XXHASH
|
|
|
|
|
tristate
|
|
|
|
|
|
|
|
|
|
source "lib/xz/Kconfig"
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# These all provide a common interface (hence the apparent duplication with
|
|
|
|
|
# ZLIB_INFLATE; DECOMPRESS_GZIP is just a wrapper.)
|
|
|
|
|
#
|
|
|
|
|
config DECOMPRESS_GZIP
|
|
|
|
|
select ZLIB_INFLATE
|
|
|
|
|
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>
14 years ago
|
|
|
config DECOMPRESS_XZ
|
|
|
|
|
select XZ_DEC
|
|
|
|
|
tristate
|
|
|
|
|
|
|
|
|
|
config DECOMPRESS_LZO
|
|
|
|
|
select LZO_DECOMPRESS
|
|
|
|
|
tristate
|
|
|
|
|
|
|
|
|
|
config DECOMPRESS_LZ4
|
|
|
|
|
select LZ4_DECOMPRESS
|
|
|
|
|
tristate
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# Generic allocator support is selected if needed
|
|
|
|
|
#
|
|
|
|
|
config GENERIC_ALLOCATOR
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# reed solomon support is select'ed if needed
|
|
|
|
|
#
|
|
|
|
|
config REED_SOLOMON
|
|
|
|
|
tristate
|
|
|
|
|
|
|
|
|
|
config REED_SOLOMON_ENC8
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config REED_SOLOMON_DEC8
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config REED_SOLOMON_ENC16
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config REED_SOLOMON_DEC16
|
|
|
|
|
bool
|
|
|
|
|
|
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>
14 years ago
|
|
|
#
|
|
|
|
|
# BCH support is selected if needed
|
|
|
|
|
#
|
|
|
|
|
config BCH
|
|
|
|
|
tristate
|
|
|
|
|
|
|
|
|
|
config BCH_CONST_PARAMS
|
|
|
|
|
bool
|
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>
14 years ago
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# Textsearch support is select'ed if needed
|
|
|
|
|
#
|
|
|
|
|
config TEXTSEARCH
|
|
|
|
|
bool
|
|
|
|
|
|
[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>
20 years ago
|
|
|
config TEXTSEARCH_KMP
|
|
|
|
|
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>
20 years ago
|
|
|
|
|
|
|
|
config TEXTSEARCH_BM
|
|
|
|
|
tristate
|
|
|
|
|
|
|
|
|
|
config TEXTSEARCH_FSM
|
|
|
|
|
tristate
|
|
|
|
|
|
|
|
|
|
config BTREE
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config INTERVAL_TREE
|
|
|
|
|
bool
|
|
|
|
|
help
|
|
|
|
|
Simple, embeddable, interval-tree. Can find the start of an
|
|
|
|
|
overlapping range in log(n) time and then iterate over all
|
|
|
|
|
overlapping nodes. The algorithm is implemented as an
|
|
|
|
|
augmented rbtree.
|
|
|
|
|
|
|
|
|
|
See:
|
|
|
|
|
|
|
|
|
|
Documentation/rbtree.txt
|
|
|
|
|
|
|
|
|
|
for more information.
|
|
|
|
|
|
|
|
|
|
config RADIX_TREE_MULTIORDER
|
|
|
|
|
bool
|
|
|
|
|
|
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>
11 years ago
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
config HAS_IOMEM
|
|
|
|
|
bool
|
|
|
|
|
depends on !NO_IOMEM
|
|
|
|
|
select GENERIC_IO
|
|
|
|
|
default y
|
|
|
|
|
|
|
|
|
|
config HAS_IOPORT_MAP
|
|
|
|
|
bool
|
|
|
|
|
depends on HAS_IOMEM && !NO_IOPORT_MAP
|
|
|
|
|
default y
|
|
|
|
|
|
|
|
|
|
config HAS_DMA
|
|
|
|
|
bool
|
|
|
|
|
depends on !NO_DMA
|
|
|
|
|
default y
|
|
|
|
|
|
|
|
|
|
config SGL_ALLOC
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
|
|
|
|
config DMA_NOOP_OPS
|
|
|
|
|
bool
|
|
|
|
|
depends on HAS_DMA && (!64BIT || ARCH_DMA_ADDR_T_64BIT)
|
|
|
|
|
default n
|
|
|
|
|
|
|
|
|
|
config DMA_VIRT_OPS
|
|
|
|
|
bool
|
|
|
|
|
depends on HAS_DMA && (!64BIT || ARCH_DMA_ADDR_T_64BIT)
|
|
|
|
|
default n
|
|
|
|
|
|
|
|
|
|
config CHECK_SIGNATURE
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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>
13 years ago
|
|
|
config DQL
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config GLOB
|
|
|
|
|
bool
|
|
|
|
|
# This actually supports modular compilation, but the module overhead
|
|
|
|
|
# is ridiculous for the amount of code involved. Until an out-of-tree
|
|
|
|
|
# driver asks for it, we'll just link it directly it into the kernel
|
|
|
|
|
# when required. Since we're ignoring out-of-tree users, there's also
|
|
|
|
|
# no need bother prompting for a manual decision:
|
|
|
|
|
# prompt "glob_match() function"
|
|
|
|
|
help
|
|
|
|
|
This option provides a glob_match function for performing
|
|
|
|
|
simple text pattern matching. It originated in the ATA code
|
|
|
|
|
to blacklist particular drive models, but other device drivers
|
|
|
|
|
may need similar functionality.
|
|
|
|
|
|
|
|
|
|
All drivers in the Linux kernel tree that require this function
|
|
|
|
|
should automatically select this option. Say N unless you
|
|
|
|
|
are compiling an out-of tree driver which tells you that it
|
|
|
|
|
depends on this.
|
|
|
|
|
|
|
|
|
|
config GLOB_SELFTEST
|
|
|
|
|
tristate "glob self-test on init"
|
|
|
|
|
depends on GLOB
|
|
|
|
|
help
|
|
|
|
|
This option enables a simple self-test of the glob_match
|
|
|
|
|
function on startup. It is primarily useful for people
|
|
|
|
|
working on the code to ensure they haven't introduced any
|
|
|
|
|
regressions.
|
|
|
|
|
|
|
|
|
|
It only adds a little bit of code and slows kernel boot (or
|
|
|
|
|
module load) by a small amount, so you're welcome to play with
|
|
|
|
|
it, but you probably don't need it.
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# Netlink attribute parsing support is select'ed if needed
|
|
|
|
|
#
|
|
|
|
|
config NLATTR
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# Generic 64-bit atomic support is selected if needed
|
|
|
|
|
#
|
|
|
|
|
config GENERIC_ATOMIC64
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config LRU_CACHE
|
|
|
|
|
tristate
|
|
|
|
|
|
|
|
|
|
config CLZ_TAB
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config CORDIC
|
|
|
|
|
tristate "CORDIC algorithm"
|
|
|
|
|
help
|
|
|
|
|
This option provides an implementation of the CORDIC algorithm;
|
|
|
|
|
calculations are in fixed point. Module will be called cordic.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
config IRQ_POLL
|
|
|
|
|
bool "IRQ polling library"
|
|
|
|
|
help
|
|
|
|
|
Helper library to poll interrupt mitigation using polling.
|
|
|
|
|
|
|
|
|
|
config MPILIB
|
|
|
|
|
tristate
|
|
|
|
|
select CLZ_TAB
|
|
|
|
|
help
|
|
|
|
|
Multiprecision maths library from GnuPG.
|
|
|
|
|
It is used to implement RSA digital signature verification,
|
|
|
|
|
which is used by IMA/EVM digital signature extension.
|
|
|
|
|
|
|
|
|
|
config SIGNATURE
|
|
|
|
|
tristate
|
|
|
|
|
depends on KEYS
|
|
|
|
|
select CRYPTO
|
|
|
|
|
select CRYPTO_SHA1
|
|
|
|
|
select MPILIB
|
|
|
|
|
help
|
|
|
|
|
Digital signature verification. Currently only RSA is supported.
|
|
|
|
|
Implementation is done using GnuPG MPI library
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# libfdt files, only selected if needed.
|
|
|
|
|
#
|
|
|
|
|
config LIBFDT
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config OID_REGISTRY
|
|
|
|
|
tristate
|
|
|
|
|
help
|
|
|
|
|
Enable fast lookup object identifier registry.
|
|
|
|
|
|
|
|
|
|
config UCS2_STRING
|
|
|
|
|
tristate
|
|
|
|
|
|
|
|
|
|
source "lib/fonts/Kconfig"
|
|
|
|
|
|
lib: scatterlist: add sg splitting function
Sometimes a scatter-gather has to be split into several chunks, or sub
scatter lists. This happens for example if a scatter list will be
handled by multiple DMA channels, each one filling a part of it.
A concrete example comes with the media V4L2 API, where the scatter list
is allocated from userspace to hold an image, regardless of the
knowledge of how many DMAs will fill it :
- in a simple RGB565 case, one DMA will pump data from the camera ISP
to memory
- in the trickier YUV422 case, 3 DMAs will pump data from the camera
ISP pipes, one for pipe Y, one for pipe U and one for pipe V
For these cases, it is necessary to split the original scatter list into
multiple scatter lists, which is the purpose of this patch.
The guarantees that are required for this patch are :
- the intersection of spans of any couple of resulting scatter lists is
empty.
- the union of spans of all resulting scatter lists is a subrange of
the span of the original scatter list.
- streaming DMA API operations (mapping, unmapping) should not happen
both on both the resulting and the original scatter list. It's either
the first or the later ones.
- the caller is reponsible to call kfree() on the resulting
scatterlists.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Jens Axboe <axboe@fb.com>
10 years ago
|
|
|
config SG_SPLIT
|
|
|
|
|
def_bool n
|
|
|
|
|
help
|
|
|
|
|
Provides a helper to split scatterlists into chunks, each chunk being
|
|
|
|
|
a scatterlist. This should be selected by a driver or an API which
|
|
|
|
|
whishes to split a scatterlist amongst multiple DMA channels.
|
lib: scatterlist: add sg splitting function
Sometimes a scatter-gather has to be split into several chunks, or sub
scatter lists. This happens for example if a scatter list will be
handled by multiple DMA channels, each one filling a part of it.
A concrete example comes with the media V4L2 API, where the scatter list
is allocated from userspace to hold an image, regardless of the
knowledge of how many DMAs will fill it :
- in a simple RGB565 case, one DMA will pump data from the camera ISP
to memory
- in the trickier YUV422 case, 3 DMAs will pump data from the camera
ISP pipes, one for pipe Y, one for pipe U and one for pipe V
For these cases, it is necessary to split the original scatter list into
multiple scatter lists, which is the purpose of this patch.
The guarantees that are required for this patch are :
- the intersection of spans of any couple of resulting scatter lists is
empty.
- the union of spans of all resulting scatter lists is a subrange of
the span of the original scatter list.
- streaming DMA API operations (mapping, unmapping) should not happen
both on both the resulting and the original scatter list. It's either
the first or the later ones.
- the caller is reponsible to call kfree() on the resulting
scatterlists.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Jens Axboe <axboe@fb.com>
10 years ago
|
|
|
|
|
|
|
|
config SG_POOL
|
|
|
|
|
def_bool n
|
|
|
|
|
help
|
|
|
|
|
Provides a helper to allocate chained scatterlists. This should be
|
|
|
|
|
selected by a driver or an API which whishes to allocate chained
|
|
|
|
|
scatterlist.
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# sg chaining option
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
config ARCH_HAS_SG_CHAIN
|
|
|
|
|
def_bool n
|
|
|
|
|
|
|
|
|
|
config ARCH_HAS_PMEM_API
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config ARCH_HAS_UACCESS_FLUSHCACHE
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config STACKDEPOT
|
|
|
|
|
bool
|
|
|
|
|
select STACKTRACE
|
|
|
|
|
|
|
|
|
|
config STACK_HASH_ORDER_SHIFT
|
|
|
|
|
int "stack depot hash size (12 => 4KB, 20 => 1024KB)"
|
|
|
|
|
range 12 20
|
|
|
|
|
default 20
|
|
|
|
|
depends on STACKDEPOT
|
|
|
|
|
help
|
|
|
|
|
Select the hash size as a power of 2 for the stackdepot hash table.
|
|
|
|
|
Choose a lower value to reduce the memory impact.
|
|
|
|
|
|
|
|
|
|
config SBITMAP
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config PARMAN
|
|
|
|
|
tristate "parman" if COMPILE_TEST
|
|
|
|
|
|
|
|
|
|
config PRIME_NUMBERS
|
|
|
|
|
tristate
|
|
|
|
|
|
|
|
|
|
config STRING_SELFTEST
|
|
|
|
|
bool "Test string functions"
|
|
|
|
|
|
|
|
|
|
endmenu
|
