Documentation: fix multiple typos found in the admin-guide subdirectory
Fix thirty five typos in dm-integrity.rst, dm-raid.rst, dm-zoned.rst, verity.rst, writecache.rst, tsx_async_abort.rst, md.rst, bttv.rst, dvb_references.rst, frontend-cardlist.rst, gspca-cardlist.rst, ipu3.rst, remote-controller.rst, mm/index.rst, numaperf.rst, userfaultfd.rst, module-signing.rst, imx-ddr.rst, intel-speed-select.rst, intel_pstate.rst, ramoops.rst, abi.rst, kernel.rst, vm.rst Signed-off-by: Andrew Klychkov <andrew.a.klychkov@gmail.com> Link: https://lore.kernel.org/r/20201204072848.GA49895@spblnx124.lan Signed-off-by: Jonathan Corbet <corbet@lwn.net>zero-sugar-mainline-defconfig
Andrew Klychkov
Jonathan Corbet
parent
b2105aa2c6
commit
751d5b2741
|
|
@ -117,7 +117,7 @@ journal_watermark:number
|
|||
|
||||
commit_time:number
|
||||
Commit time in milliseconds. When this time passes, the journal is
|
||||
written. The journal is also written immediatelly if the FLUSH
|
||||
written. The journal is also written immediately if the FLUSH
|
||||
request is received.
|
||||
|
||||
internal_hash:algorithm(:key) (the key is optional)
|
||||
|
|
@ -147,7 +147,7 @@ journal_crypt:algorithm(:key) (the key is optional)
|
|||
"salsa20" or "ctr(aes)").
|
||||
|
||||
The journal contains history of last writes to the block device,
|
||||
an attacker reading the journal could see the last sector nubmers
|
||||
an attacker reading the journal could see the last sector numbers
|
||||
that were written. From the sector numbers, the attacker can infer
|
||||
the size of files that were written. To protect against this
|
||||
situation, you can encrypt the journal.
|
||||
|
|
|
|||
|
|
@ -418,6 +418,6 @@ Version History
|
|||
specific devices are requested via rebuild. Fix RAID leg
|
||||
rebuild errors.
|
||||
1.15.0 Fix size extensions not being synchronized in case of new MD bitmap
|
||||
pages allocated; also fix those not occuring after previous reductions
|
||||
pages allocated; also fix those not occurring after previous reductions
|
||||
1.15.1 Fix argument count and arguments for rebuild/write_mostly/journal_(dev|mode)
|
||||
on the status line.
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ The dm-zoned implementation is simple and minimizes system overhead (CPU
|
|||
and memory usage as well as storage capacity loss). For a 10TB
|
||||
host-managed disk with 256 MB zones, dm-zoned memory usage per disk
|
||||
instance is at most 4.5 MB and as little as 5 zones will be used
|
||||
internally for storing metadata and performaing reclaim operations.
|
||||
internally for storing metadata and performing reclaim operations.
|
||||
|
||||
dm-zoned target devices are formatted and checked using the dmzadm
|
||||
utility available at:
|
||||
|
|
@ -102,7 +102,7 @@ the buffer zone assigned. If the accessed chunk has no mapping, or the
|
|||
accessed blocks are invalid, the read buffer is zeroed and the read
|
||||
operation terminated.
|
||||
|
||||
After some time, the limited number of convnetional zones available may
|
||||
After some time, the limited number of conventional zones available may
|
||||
be exhausted (all used to map chunks or buffer sequential zones) and
|
||||
unaligned writes to unbuffered chunks become impossible. To avoid this
|
||||
situation, a reclaim process regularly scans used conventional zones and
|
||||
|
|
@ -158,7 +158,7 @@ Ex::
|
|||
dmzadm --format /dev/sdxx /dev/sdyy
|
||||
|
||||
|
||||
Fomatted device(s) can be started with the dmzadm utility, too.:
|
||||
Formatted device(s) can be started with the dmzadm utility, too.:
|
||||
|
||||
Ex::
|
||||
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ Construction Parameters
|
|||
|
||||
<#opt_params>
|
||||
Number of optional parameters. If there are no optional parameters,
|
||||
the optional paramaters section can be skipped or #opt_params can be zero.
|
||||
the optional parameters section can be skipped or #opt_params can be zero.
|
||||
Otherwise #opt_params is the number of following arguments.
|
||||
|
||||
Example of optional parameters section:
|
||||
|
|
|
|||
|
|
@ -37,10 +37,10 @@ Constructor parameters:
|
|||
autocommit_blocks n (default: 64 for pmem, 65536 for ssd)
|
||||
when the application writes this amount of blocks without
|
||||
issuing the FLUSH request, the blocks are automatically
|
||||
commited
|
||||
committed
|
||||
autocommit_time ms (default: 1000)
|
||||
autocommit time in milliseconds. The data is automatically
|
||||
commited if this time passes and no FLUSH request is
|
||||
committed if this time passes and no FLUSH request is
|
||||
received
|
||||
fua (by default on)
|
||||
applicable only to persistent memory - use the FUA flag
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ Hyper-Thread attacks are possible.
|
|||
|
||||
The victim of a malicious actor does not need to make use of TSX. Only the
|
||||
attacker needs to begin a TSX transaction and raise an asynchronous abort
|
||||
which in turn potenitally leaks data stored in the buffers.
|
||||
which in turn potentially leaks data stored in the buffers.
|
||||
|
||||
More detailed technical information is available in the TAA specific x86
|
||||
architecture section: :ref:`Documentation/x86/tsx_async_abort.rst <tsx_async_abort>`.
|
||||
|
|
|
|||
|
|
@ -221,7 +221,7 @@ All md devices contain:
|
|||
|
||||
layout
|
||||
The ``layout`` for the array for the particular level. This is
|
||||
simply a number that is interpretted differently by different
|
||||
simply a number that is interpreted differently by different
|
||||
levels. It can be written while assembling an array.
|
||||
|
||||
array_size
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ the Subsystem ID in the second line, looks like this:
|
|||
only bt878-based cards can have a subsystem ID (which does not mean
|
||||
that every card really has one). bt848 cards can't have a Subsystem
|
||||
ID and therefore can't be autodetected. There is a list with the ID's
|
||||
at :doc:`bttv-cardlist` (in case you are intrested or want to mail
|
||||
at :doc:`bttv-cardlist` (in case you are interested or want to mail
|
||||
patches with updates).
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ The DVB mailing list linux-dvb is hosted at vger. Please see
|
|||
http://vger.kernel.org/vger-lists.html#linux-media for details.
|
||||
|
||||
There are also some other old lists hosted at:
|
||||
https://linuxtv.org/lists.php. If you're insterested on that for historic
|
||||
https://linuxtv.org/lists.php. If you're interested on that for historic
|
||||
reasons, please check the archive at https://linuxtv.org/pipermail/linux-dvb/.
|
||||
|
||||
The media subsystem Wiki is hosted at https://linuxtv.org/wiki/.
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ cx24116 Conexant CX24116 based
|
|||
cx24117 Conexant CX24117 based
|
||||
cx24120 Conexant CX24120 based
|
||||
cx24123 Conexant CX24123 based
|
||||
ds3000 Montage Tehnology DS3000 based
|
||||
ds3000 Montage Technology DS3000 based
|
||||
mb86a16 Fujitsu MB86A16 based
|
||||
mt312 Zarlink VP310/MT312/ZL10313 based
|
||||
s5h1420 Samsung S5H1420 based
|
||||
|
|
@ -83,7 +83,7 @@ tda10086 Philips TDA10086 based
|
|||
tda8083 Philips TDA8083 based
|
||||
tda8261 Philips TDA8261 based
|
||||
tda826x Philips TDA826X silicon tuner
|
||||
ts2020 Montage Tehnology TS2020 based tuners
|
||||
ts2020 Montage Technology TS2020 based tuners
|
||||
tua6100 Infineon TUA6100 PLL
|
||||
cx24113 Conexant CX24113/CX24128 tuner for DVB-S/DSS
|
||||
itd1000 Integrant ITD1000 Zero IF tuner for DVB-S/DSS
|
||||
|
|
|
|||
|
|
@ -305,7 +305,7 @@ pac7302 093a:2625 Genius iSlim 310
|
|||
pac7302 093a:2626 Labtec 2200
|
||||
pac7302 093a:2627 Genius FaceCam 300
|
||||
pac7302 093a:2628 Genius iLook 300
|
||||
pac7302 093a:2629 Genious iSlim 300
|
||||
pac7302 093a:2629 Genius iSlim 300
|
||||
pac7302 093a:262a Webcam 300k
|
||||
pac7302 093a:262c Philips SPC 230 NC
|
||||
jl2005bcd 0979:0227 Various brands, 19 known cameras supported
|
||||
|
|
|
|||
|
|
@ -86,7 +86,7 @@ raw Bayer format that is specific to IPU3.
|
|||
Let us take the example of ov5670 sensor connected to CSI2 port 0, for a
|
||||
2592x1944 image capture.
|
||||
|
||||
Using the media contorller APIs, the ov5670 sensor is configured to send
|
||||
Using the media controller APIs, the ov5670 sensor is configured to send
|
||||
frames in packed raw Bayer format to IPU3 CSI2 receiver.
|
||||
|
||||
.. code-block:: none
|
||||
|
|
@ -313,8 +313,8 @@ configuration steps of 0.03125 (1/32).
|
|||
|
||||
**Geometric Distortion Correction**
|
||||
|
||||
Geometric Distortion Correction is used to performe correction of distortions
|
||||
and image filtering. It needs some extra filter and envelop padding pixels to
|
||||
Geometric Distortion Correction is used to perform correction of distortions
|
||||
and image filtering. It needs some extra filter and envelope padding pixels to
|
||||
work, so the input resolution of GDC should be larger than the output
|
||||
resolution.
|
||||
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ Using without lircd
|
|||
|
||||
Xorg recognizes several IR keycodes that have its numerical value lower
|
||||
than 247. With the advent of Wayland, the input driver got updated too,
|
||||
and should now accept all keycodes. Yet, you may want to just reasign
|
||||
and should now accept all keycodes. Yet, you may want to just reassign
|
||||
the keycodes to something that your favorite media application likes.
|
||||
|
||||
This can be done by setting
|
||||
|
|
|
|||
|
|
@ -3,9 +3,9 @@ Memory Management
|
|||
=================
|
||||
|
||||
Linux memory management subsystem is responsible, as the name implies,
|
||||
for managing the memory in the system. This includes implemnetation of
|
||||
for managing the memory in the system. This includes implementation of
|
||||
virtual memory and demand paging, memory allocation both for kernel
|
||||
internal structures and user space programms, mapping of files into
|
||||
internal structures and user space programs, mapping of files into
|
||||
processes address space and many other cool things.
|
||||
|
||||
Linux memory management is a complex system with many configurable
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ memory node's access class 0 initiators as follows::
|
|||
/sys/devices/system/node/nodeY/access0/initiators/
|
||||
|
||||
These attributes apply only when accessed from nodes that have the
|
||||
are linked under the this access's inititiators.
|
||||
are linked under the this access's initiators.
|
||||
|
||||
The performance characteristics the kernel provides for the local initiators
|
||||
are exported are as follows::
|
||||
|
|
|
|||
|
|
@ -114,7 +114,7 @@ Notes:
|
|||
you must provide some kind of page in your thread after reading from
|
||||
the uffd. You must provide either ``UFFDIO_COPY`` or ``UFFDIO_ZEROPAGE``.
|
||||
The normal behavior of the OS automatically providing a zero page on
|
||||
an annonymous mmaping is not in place.
|
||||
an anonymous mmaping is not in place.
|
||||
|
||||
- None of the page-delivering ioctls default to the range that you
|
||||
registered with. You must fill in all fields for the appropriate
|
||||
|
|
|
|||
|
|
@ -106,7 +106,7 @@ This has a number of options available:
|
|||
certificate and a private key.
|
||||
|
||||
If the PEM file containing the private key is encrypted, or if the
|
||||
PKCS#11 token requries a PIN, this can be provided at build time by
|
||||
PKCS#11 token requires a PIN, this can be provided at build time by
|
||||
means of the ``KBUILD_SIGN_PIN`` variable.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Freescale i.MX8 DDR Performance Monitoring Unit (PMU)
|
|||
|
||||
There are no performance counters inside the DRAM controller, so performance
|
||||
signals are brought out to the edge of the controller where a set of 4 x 32 bit
|
||||
counters is implemented. This is controlled by the CSV modes programed in counter
|
||||
counters is implemented. This is controlled by the CSV modes programmed in counter
|
||||
control register which causes a large number of PERF signals to be generated.
|
||||
|
||||
Selection of the value for each counter is done via the config registers. There
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ To get help on a command, another level of help is provided. For example for the
|
|||
|
||||
Summary of platform capability
|
||||
------------------------------
|
||||
To check the current platform and driver capaibilities, execute::
|
||||
To check the current platform and driver capabilities, execute::
|
||||
|
||||
#intel-speed-select --info
|
||||
|
||||
|
|
@ -658,7 +658,7 @@ If -a option is not used, then the following steps are required before enabling
|
|||
Intel(R) SST-BF:
|
||||
|
||||
- Discover Intel(R) SST-BF and note low and high priority base frequency
|
||||
- Note the high prioity CPU list
|
||||
- Note the high priority CPU list
|
||||
- Enable CLOS using core-power feature set
|
||||
- Configure CLOS parameters. Use CLOS.min to set to minimum performance
|
||||
- Subscribe desired CPUs to CLOS groups
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ Operation Modes
|
|||
|
||||
``intel_pstate`` can operate in two different modes, active or passive. In the
|
||||
active mode, it uses its own internal performance scaling governor algorithm or
|
||||
allows the hardware to do preformance scaling by itself, while in the passive
|
||||
allows the hardware to do performance scaling by itself, while in the passive
|
||||
mode it responds to requests made by a generic ``CPUFreq`` governor implementing
|
||||
a certain performance scaling algorithm. Which of them will be in effect
|
||||
depends on what kernel command line options are used and on the capabilities of
|
||||
|
|
@ -380,13 +380,13 @@ argument is passed to the kernel in the command line.
|
|||
|
||||
``no_turbo``
|
||||
If set (equal to 1), the driver is not allowed to set any turbo P-states
|
||||
(see `Turbo P-states Support`_). If unset (equalt to 0, which is the
|
||||
(see `Turbo P-states Support`_). If unset (equal to 0, which is the
|
||||
default), turbo P-states can be set by the driver.
|
||||
[Note that ``intel_pstate`` does not support the general ``boost``
|
||||
attribute (supported by some other scaling drivers) which is replaced
|
||||
by this one.]
|
||||
|
||||
This attrubute does not affect the maximum supported frequency value
|
||||
This attribute does not affect the maximum supported frequency value
|
||||
supplied to the ``CPUFreq`` core and exposed via the policy interface,
|
||||
but it affects the maximum possible value of per-policy P-state limits
|
||||
(see `Interpretation of Policy Attributes`_ below for details).
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ and type of the memory area are set using three variables:
|
|||
* ``mem_address`` for the start
|
||||
* ``mem_size`` for the size. The memory size will be rounded down to a
|
||||
power of two.
|
||||
* ``mem_type`` to specifiy if the memory type (default is pgprot_writecombine).
|
||||
* ``mem_type`` to specify if the memory type (default is pgprot_writecombine).
|
||||
|
||||
Typically the default value of ``mem_type=0`` should be used as that sets the pstore
|
||||
mapping to pgprot_writecombine. Setting ``mem_type=1`` attempts to use
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ vsyscall32 (x86)
|
|||
|
||||
Determines whether the kernels maps a vDSO page into 32-bit processes;
|
||||
can be set to 1 to enable, or 0 to disable. Defaults to enabled if
|
||||
``CONFIG_COMPAT_VDSO`` is set, disabled otherwide.
|
||||
``CONFIG_COMPAT_VDSO`` is set, disabled otherwise.
|
||||
|
||||
This controls the same setting as the ``vdso32`` kernel boot
|
||||
parameter.
|
||||
|
|
|
|||
|
|
@ -879,7 +879,7 @@ The default value is 127.
|
|||
perf_event_mlock_kb
|
||||
===================
|
||||
|
||||
Control size of per-cpu ring buffer not counted agains mlock limit.
|
||||
Control size of per-cpu ring buffer not counted against mlock limit.
|
||||
|
||||
The default value is 512 + 1 page
|
||||
|
||||
|
|
|
|||
|
|
@ -146,7 +146,7 @@ This should be used on systems where stalls for minor page faults are an
|
|||
acceptable trade for large contiguous free memory. Set to 0 to prevent
|
||||
compaction from moving pages that are unevictable. Default value is 1.
|
||||
On CONFIG_PREEMPT_RT the default value is 0 in order to avoid a page fault, due
|
||||
to compaction, which would block the task from becomming active until the fault
|
||||
to compaction, which would block the task from becoming active until the fault
|
||||
is resolved.
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue