mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-09-27 12:57:53 +00:00
Merge branch 'mauro' into docs-next
Mauro says: > As discussed at: > https://lore.kernel.org/linux-doc/871r9k6rmy.fsf@meer.lwn.net/ > > It is better to avoid using :doc:`foo` to refer to Documentation/foo.rst, as the > automarkup.py extension should handle it automatically, on most cases. > > There are a couple of exceptions to this rule: > > 1. when :doc: tag is used to point to a kernel-doc DOC: markup; > 2. when it is used with a named tag, e. g. :doc:`some name <foo>`; > > On this series: > > Patch 1 manually adjust the references inside driver-api/pm/devices.rst, > as there it uses :file:`foo` to refer to some Documentation/ files; > > Patch 2 converts a table at Documentation/dev-tools/kunit/api/index.rst > into a list, carefully avoiding the > > The remaining patches convert the other occurrences via a replace script. > They were manually edited, in order to honour 80-columns where possible. > > This series based on docs-next branch. In order to avoid merge conflicts, > I rebased it internally against yesterday's linux-next, dropping a patch > and a hunk that would have caused conflicts there. >
This commit is contained in:
Jonathan Corbet
commit
257e652462
46 changed files with 171 additions and 147 deletions
|
|
@ -125,4 +125,4 @@ all the EPF devices are created and linked with the EPC device.
|
|||
| interrupt_pin
|
||||
| function
|
||||
|
||||
[1] :doc:`pci-endpoint`
|
||||
[1] Documentation/PCI/endpoint/pci-endpoint.rst
|
||||
|
|
|
|||
|
|
@ -265,7 +265,7 @@ Set the DMA mask size
|
|||
---------------------
|
||||
.. note::
|
||||
If anything below doesn't make sense, please refer to
|
||||
:doc:`/core-api/dma-api`. This section is just a reminder that
|
||||
Documentation/core-api/dma-api.rst. This section is just a reminder that
|
||||
drivers need to indicate DMA capabilities of the device and is not
|
||||
an authoritative source for DMA interfaces.
|
||||
|
||||
|
|
@ -291,7 +291,7 @@ Many 64-bit "PCI" devices (before PCI-X) and some PCI-X devices are
|
|||
Setup shared control data
|
||||
-------------------------
|
||||
Once the DMA masks are set, the driver can allocate "consistent" (a.k.a. shared)
|
||||
memory. See :doc:`/core-api/dma-api` for a full description of
|
||||
memory. See Documentation/core-api/dma-api.rst for a full description of
|
||||
the DMA APIs. This section is just a reminder that it needs to be done
|
||||
before enabling DMA on the device.
|
||||
|
||||
|
|
@ -421,7 +421,7 @@ owners if there is one.
|
|||
|
||||
Then clean up "consistent" buffers which contain the control data.
|
||||
|
||||
See :doc:`/core-api/dma-api` for details on unmapping interfaces.
|
||||
See Documentation/core-api/dma-api.rst for details on unmapping interfaces.
|
||||
|
||||
|
||||
Unregister from other subsystems
|
||||
|
|
|
|||
|
|
@ -3,7 +3,8 @@
|
|||
SRBDS - Special Register Buffer Data Sampling
|
||||
=============================================
|
||||
|
||||
SRBDS is a hardware vulnerability that allows MDS :doc:`mds` techniques to
|
||||
SRBDS is a hardware vulnerability that allows MDS
|
||||
Documentation/admin-guide/hw-vuln/mds.rst techniques to
|
||||
infer values returned from special register accesses. Special register
|
||||
accesses are accesses to off core registers. According to Intel's evaluation,
|
||||
the special register reads that have a security expectation of privacy are
|
||||
|
|
|
|||
|
|
@ -20,8 +20,8 @@ Nehalem and later generations of Intel processors, but the level of support for
|
|||
a particular processor model in it depends on whether or not it recognizes that
|
||||
processor model and may also depend on information coming from the platform
|
||||
firmware. [To understand ``intel_idle`` it is necessary to know how ``CPUIdle``
|
||||
works in general, so this is the time to get familiar with :doc:`cpuidle` if you
|
||||
have not done that yet.]
|
||||
works in general, so this is the time to get familiar with
|
||||
Documentation/admin-guide/pm/cpuidle.rst if you have not done that yet.]
|
||||
|
||||
``intel_idle`` uses the ``MWAIT`` instruction to inform the processor that the
|
||||
logical CPU executing it is idle and so it may be possible to put some of the
|
||||
|
|
@ -53,7 +53,8 @@ processor) corresponding to them depends on the processor model and it may also
|
|||
depend on the configuration of the platform.
|
||||
|
||||
In order to create a list of available idle states required by the ``CPUIdle``
|
||||
subsystem (see :ref:`idle-states-representation` in :doc:`cpuidle`),
|
||||
subsystem (see :ref:`idle-states-representation` in
|
||||
Documentation/admin-guide/pm/cpuidle.rst),
|
||||
``intel_idle`` can use two sources of information: static tables of idle states
|
||||
for different processor models included in the driver itself and the ACPI tables
|
||||
of the system. The former are always used if the processor model at hand is
|
||||
|
|
@ -98,7 +99,8 @@ states may not be enabled by default if there are no matching entries in the
|
|||
preliminary list of idle states coming from the ACPI tables. In that case user
|
||||
space still can enable them later (on a per-CPU basis) with the help of
|
||||
the ``disable`` idle state attribute in ``sysfs`` (see
|
||||
:ref:`idle-states-representation` in :doc:`cpuidle`). This basically means that
|
||||
:ref:`idle-states-representation` in
|
||||
Documentation/admin-guide/pm/cpuidle.rst). This basically means that
|
||||
the idle states "known" to the driver may not be enabled by default if they have
|
||||
not been exposed by the platform firmware (through the ACPI tables).
|
||||
|
||||
|
|
@ -186,7 +188,8 @@ be desirable. In practice, it is only really necessary to do that if the idle
|
|||
states in question cannot be enabled during system startup, because in the
|
||||
working state of the system the CPU power management quality of service (PM
|
||||
QoS) feature can be used to prevent ``CPUIdle`` from touching those idle states
|
||||
even if they have been enumerated (see :ref:`cpu-pm-qos` in :doc:`cpuidle`).
|
||||
even if they have been enumerated (see :ref:`cpu-pm-qos` in
|
||||
Documentation/admin-guide/pm/cpuidle.rst).
|
||||
Setting ``max_cstate`` to 0 causes the ``intel_idle`` initialization to fail.
|
||||
|
||||
The ``no_acpi`` and ``use_acpi`` module parameters (recognized by ``intel_idle``
|
||||
|
|
@ -202,7 +205,8 @@ Namely, the positions of the bits that are set in the ``states_off`` value are
|
|||
the indices of idle states to be disabled by default (as reflected by the names
|
||||
of the corresponding idle state directories in ``sysfs``, :file:`state0`,
|
||||
:file:`state1` ... :file:`state<i>` ..., where ``<i>`` is the index of the given
|
||||
idle state; see :ref:`idle-states-representation` in :doc:`cpuidle`).
|
||||
idle state; see :ref:`idle-states-representation` in
|
||||
Documentation/admin-guide/pm/cpuidle.rst).
|
||||
|
||||
For example, if ``states_off`` is equal to 3, the driver will disable idle
|
||||
states 0 and 1 by default, and if it is equal to 8, idle state 3 will be
|
||||
|
|
|
|||
|
|
@ -18,8 +18,8 @@ General Information
|
|||
(``CPUFreq``). It is a scaling driver for the Sandy Bridge and later
|
||||
generations of Intel processors. Note, however, that some of those processors
|
||||
may not be supported. [To understand ``intel_pstate`` it is necessary to know
|
||||
how ``CPUFreq`` works in general, so this is the time to read :doc:`cpufreq` if
|
||||
you have not done that yet.]
|
||||
how ``CPUFreq`` works in general, so this is the time to read
|
||||
Documentation/admin-guide/pm/cpufreq.rst if you have not done that yet.]
|
||||
|
||||
For the processors supported by ``intel_pstate``, the P-state concept is broader
|
||||
than just an operating frequency or an operating performance point (see the
|
||||
|
|
@ -445,8 +445,9 @@ Interpretation of Policy Attributes
|
|||
-----------------------------------
|
||||
|
||||
The interpretation of some ``CPUFreq`` policy attributes described in
|
||||
:doc:`cpufreq` is special with ``intel_pstate`` as the current scaling driver
|
||||
and it generally depends on the driver's `operation mode <Operation Modes_>`_.
|
||||
Documentation/admin-guide/pm/cpufreq.rst is special with ``intel_pstate``
|
||||
as the current scaling driver and it generally depends on the driver's
|
||||
`operation mode <Operation Modes_>`_.
|
||||
|
||||
First of all, the values of the ``cpuinfo_max_freq``, ``cpuinfo_min_freq`` and
|
||||
``scaling_cur_freq`` attributes are produced by applying a processor-specific
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ Documentation for /proc/sys/abi/
|
|||
|
||||
Copyright (c) 2020, Stephen Kitt
|
||||
|
||||
For general info, see :doc:`index`.
|
||||
For general info, see Documentation/admin-guide/sysctl/index.rst.
|
||||
|
||||
------------------------------------------------------------------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,8 @@ Copyright (c) 1998, 1999, Rik van Riel <riel@nl.linux.org>
|
|||
|
||||
Copyright (c) 2009, Shen Feng<shen@cn.fujitsu.com>
|
||||
|
||||
For general info and legal blurb, please look in :doc:`index`.
|
||||
For general info and legal blurb, please look in
|
||||
Documentation/admin-guide/sysctl/index.rst.
|
||||
|
||||
------------------------------------------------------------------------------
|
||||
|
||||
|
|
@ -54,7 +55,7 @@ free space valid for 30 seconds.
|
|||
acpi_video_flags
|
||||
================
|
||||
|
||||
See :doc:`/power/video`. This allows the video resume mode to be set,
|
||||
See Documentation/power/video.rst. This allows the video resume mode to be set,
|
||||
in a similar fashion to the ``acpi_sleep`` kernel parameter, by
|
||||
combining the following values:
|
||||
|
||||
|
|
@ -89,7 +90,7 @@ is 0x15 and the full version number is 0x234, this file will contain
|
|||
the value 340 = 0x154.
|
||||
|
||||
See the ``type_of_loader`` and ``ext_loader_type`` fields in
|
||||
:doc:`/x86/boot` for additional information.
|
||||
Documentation/x86/boot.rst for additional information.
|
||||
|
||||
|
||||
bootloader_version (x86 only)
|
||||
|
|
@ -99,7 +100,7 @@ The complete bootloader version number. In the example above, this
|
|||
file will contain the value 564 = 0x234.
|
||||
|
||||
See the ``type_of_loader`` and ``ext_loader_ver`` fields in
|
||||
:doc:`/x86/boot` for additional information.
|
||||
Documentation/x86/boot.rst for additional information.
|
||||
|
||||
|
||||
bpf_stats_enabled
|
||||
|
|
@ -269,7 +270,7 @@ see the ``hostname(1)`` man page.
|
|||
firmware_config
|
||||
===============
|
||||
|
||||
See :doc:`/driver-api/firmware/fallback-mechanisms`.
|
||||
See Documentation/driver-api/firmware/fallback-mechanisms.rst.
|
||||
|
||||
The entries in this directory allow the firmware loader helper
|
||||
fallback to be controlled:
|
||||
|
|
@ -297,7 +298,7 @@ crashes and outputting them to a serial console.
|
|||
ftrace_enabled, stack_tracer_enabled
|
||||
====================================
|
||||
|
||||
See :doc:`/trace/ftrace`.
|
||||
See Documentation/trace/ftrace.rst.
|
||||
|
||||
|
||||
hardlockup_all_cpu_backtrace
|
||||
|
|
@ -325,7 +326,7 @@ when a hard lockup is detected.
|
|||
1 Panic on hard lockup.
|
||||
= ===========================
|
||||
|
||||
See :doc:`/admin-guide/lockup-watchdogs` for more information.
|
||||
See Documentation/admin-guide/lockup-watchdogs.rst for more information.
|
||||
This can also be set using the nmi_watchdog kernel parameter.
|
||||
|
||||
|
||||
|
|
@ -586,7 +587,8 @@ in a KVM virtual machine. This default can be overridden by adding::
|
|||
|
||||
nmi_watchdog=1
|
||||
|
||||
to the guest kernel command line (see :doc:`/admin-guide/kernel-parameters`).
|
||||
to the guest kernel command line (see
|
||||
Documentation/admin-guide/kernel-parameters.rst).
|
||||
|
||||
|
||||
numa_balancing
|
||||
|
|
@ -1071,7 +1073,7 @@ that support this feature.
|
|||
real-root-dev
|
||||
=============
|
||||
|
||||
See :doc:`/admin-guide/initrd`.
|
||||
See Documentation/admin-guide/initrd.rst.
|
||||
|
||||
|
||||
reboot-cmd (SPARC only)
|
||||
|
|
@ -1158,7 +1160,7 @@ will take effect.
|
|||
seccomp
|
||||
=======
|
||||
|
||||
See :doc:`/userspace-api/seccomp_filter`.
|
||||
See Documentation/userspace-api/seccomp_filter.rst.
|
||||
|
||||
|
||||
sg-big-buff
|
||||
|
|
@ -1329,7 +1331,7 @@ the boot PROM.
|
|||
sysrq
|
||||
=====
|
||||
|
||||
See :doc:`/admin-guide/sysrq`.
|
||||
See Documentation/admin-guide/sysrq.rst.
|
||||
|
||||
|
||||
tainted
|
||||
|
|
@ -1359,15 +1361,16 @@ ORed together. The letters are seen in "Tainted" line of Oops reports.
|
|||
131072 `(T)` The kernel was built with the struct randomization plugin
|
||||
====== ===== ==============================================================
|
||||
|
||||
See :doc:`/admin-guide/tainted-kernels` for more information.
|
||||
See Documentation/admin-guide/tainted-kernels.rst for more information.
|
||||
|
||||
Note:
|
||||
writes to this sysctl interface will fail with ``EINVAL`` if the kernel is
|
||||
booted with the command line option ``panic_on_taint=<bitmask>,nousertaint``
|
||||
and any of the ORed together values being written to ``tainted`` match with
|
||||
the bitmask declared on panic_on_taint.
|
||||
See :doc:`/admin-guide/kernel-parameters` for more details on that particular
|
||||
kernel command line option and its optional ``nousertaint`` switch.
|
||||
See Documentation/admin-guide/kernel-parameters.rst for more details on
|
||||
that particular kernel command line option and its optional
|
||||
``nousertaint`` switch.
|
||||
|
||||
threads-max
|
||||
===========
|
||||
|
|
@ -1391,7 +1394,7 @@ If a value outside of this range is written to ``threads-max`` an
|
|||
traceoff_on_warning
|
||||
===================
|
||||
|
||||
When set, disables tracing (see :doc:`/trace/ftrace`) when a
|
||||
When set, disables tracing (see Documentation/trace/ftrace.rst) when a
|
||||
``WARN()`` is hit.
|
||||
|
||||
|
||||
|
|
@ -1411,8 +1414,8 @@ will send them to printk() again.
|
|||
|
||||
This only works if the kernel was booted with ``tp_printk`` enabled.
|
||||
|
||||
See :doc:`/admin-guide/kernel-parameters` and
|
||||
:doc:`/trace/boottime-trace`.
|
||||
See Documentation/admin-guide/kernel-parameters.rst and
|
||||
Documentation/trace/boottime-trace.rst.
|
||||
|
||||
|
||||
.. _unaligned-dump-stack:
|
||||
|
|
|
|||
|
|
@ -196,7 +196,7 @@ a virtual address mapping (unlike the earlier scheme of virtual address
|
|||
do not have a corresponding kernel virtual address space mapping) and
|
||||
low-memory pages.
|
||||
|
||||
Note: Please refer to :doc:`/core-api/dma-api-howto` for a discussion
|
||||
Note: Please refer to Documentation/core-api/dma-api-howto.rst for a discussion
|
||||
on PCI high mem DMA aspects and mapping of scatter gather lists, and support
|
||||
for 64 bit PCI.
|
||||
|
||||
|
|
|
|||
|
|
@ -20,10 +20,10 @@ LSM hook:
|
|||
Other LSM hooks which can be instrumented can be found in
|
||||
``include/linux/lsm_hooks.h``.
|
||||
|
||||
eBPF programs that use :doc:`/bpf/btf` do not need to include kernel headers
|
||||
for accessing information from the attached eBPF program's context. They can
|
||||
simply declare the structures in the eBPF program and only specify the fields
|
||||
that need to be accessed.
|
||||
eBPF programs that use Documentation/bpf/btf.rst do not need to include kernel
|
||||
headers for accessing information from the attached eBPF program's context.
|
||||
They can simply declare the structures in the eBPF program and only specify
|
||||
the fields that need to be accessed.
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
|
|
@ -88,8 +88,9 @@ example:
|
|||
|
||||
The ``__attribute__((preserve_access_index))`` is a clang feature that allows
|
||||
the BPF verifier to update the offsets for the access at runtime using the
|
||||
:doc:`/bpf/btf` information. Since the BPF verifier is aware of the types, it
|
||||
also validates all the accesses made to the various types in the eBPF program.
|
||||
Documentation/bpf/btf.rst information. Since the BPF verifier is aware of the
|
||||
types, it also validates all the accesses made to the various types in the
|
||||
eBPF program.
|
||||
|
||||
Loading
|
||||
-------
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ How to access I/O mapped memory from within device drivers
|
|||
|
||||
The virt_to_bus() and bus_to_virt() functions have been
|
||||
superseded by the functionality provided by the PCI DMA interface
|
||||
(see :doc:`/core-api/dma-api-howto`). They continue
|
||||
(see Documentation/core-api/dma-api-howto.rst). They continue
|
||||
to be documented below for historical purposes, but new code
|
||||
must not use them. --davidm 00/12/12
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Dynamic DMA mapping using the generic device
|
|||
:Author: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
|
||||
|
||||
This document describes the DMA API. For a more gentle introduction
|
||||
of the API (and actual examples), see :doc:`/core-api/dma-api-howto`.
|
||||
of the API (and actual examples), see Documentation/core-api/dma-api-howto.rst.
|
||||
|
||||
This API is split into two pieces. Part I describes the basic API.
|
||||
Part II describes extensions for supporting non-consistent memory
|
||||
|
|
@ -479,7 +479,8 @@ without the _attrs suffixes, except that they pass an optional
|
|||
dma_attrs.
|
||||
|
||||
The interpretation of DMA attributes is architecture-specific, and
|
||||
each attribute should be documented in :doc:`/core-api/dma-attributes`.
|
||||
each attribute should be documented in
|
||||
Documentation/core-api/dma-attributes.rst.
|
||||
|
||||
If dma_attrs are 0, the semantics of each of these functions
|
||||
is identical to those of the corresponding function
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ To do ISA style DMA you need to include two headers::
|
|||
#include <asm/dma.h>
|
||||
|
||||
The first is the generic DMA API used to convert virtual addresses to
|
||||
bus addresses (see :doc:`/core-api/dma-api` for details).
|
||||
bus addresses (see Documentation/core-api/dma-api.rst for details).
|
||||
|
||||
The second contains the routines specific to ISA DMA transfers. Since
|
||||
this is not present on all platforms make sure you construct your
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ Concurrency primitives
|
|||
======================
|
||||
|
||||
How Linux keeps everything from happening at the same time. See
|
||||
:doc:`/locking/index` for more related documentation.
|
||||
Documentation/locking/index.rst for more related documentation.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
|
@ -77,7 +77,7 @@ Memory management
|
|||
=================
|
||||
|
||||
How to allocate and use memory in the kernel. Note that there is a lot
|
||||
more memory-management documentation in :doc:`/vm/index`.
|
||||
more memory-management documentation in Documentation/vm/index.rst.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ API Reference
|
|||
This section documents the KUnit kernel testing API. It is divided into the
|
||||
following sections:
|
||||
|
||||
================================= ==============================================
|
||||
:doc:`test` documents all of the standard testing API
|
||||
excluding mocking or mocking related features.
|
||||
================================= ==============================================
|
||||
Documentation/dev-tools/kunit/api/test.rst
|
||||
|
||||
- documents all of the standard testing API excluding mocking
|
||||
or mocking related features.
|
||||
|
|
|
|||
|
|
@ -97,7 +97,7 @@ things to try.
|
|||
modules will automatically execute associated tests when loaded. Test results
|
||||
can be collected from ``/sys/kernel/debug/kunit/<test suite>/results``, and
|
||||
can be parsed with ``kunit.py parse``. For more details, see "KUnit on
|
||||
non-UML architectures" in :doc:`usage`.
|
||||
non-UML architectures" in Documentation/dev-tools/kunit/usage.rst.
|
||||
|
||||
If none of the above tricks help, you are always welcome to email any issues to
|
||||
kunit-dev@googlegroups.com.
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ To make running these tests (and reading the results) easier, KUnit offers
|
|||
results. This provides a quick way of running KUnit tests during development,
|
||||
without requiring a virtual machine or separate hardware.
|
||||
|
||||
Get started now: :doc:`start`
|
||||
Get started now: Documentation/dev-tools/kunit/start.rst
|
||||
|
||||
Why KUnit?
|
||||
==========
|
||||
|
|
@ -88,9 +88,9 @@ it takes to read their test log?
|
|||
How do I use it?
|
||||
================
|
||||
|
||||
* :doc:`start` - for new users of KUnit
|
||||
* :doc:`tips` - for short examples of best practices
|
||||
* :doc:`usage` - for a more detailed explanation of KUnit features
|
||||
* :doc:`api/index` - for the list of KUnit APIs used for testing
|
||||
* :doc:`kunit-tool` - for more information on the kunit_tool helper script
|
||||
* :doc:`faq` - for answers to some common questions about KUnit
|
||||
* Documentation/dev-tools/kunit/start.rst - for new users of KUnit
|
||||
* Documentation/dev-tools/kunit/tips.rst - for short examples of best practices
|
||||
* Documentation/dev-tools/kunit/usage.rst - for a more detailed explanation of KUnit features
|
||||
* Documentation/dev-tools/kunit/api/index.rst - for the list of KUnit APIs used for testing
|
||||
* Documentation/dev-tools/kunit/kunit-tool.rst - for more information on the kunit_tool helper script
|
||||
* Documentation/dev-tools/kunit/faq.rst - for answers to some common questions about KUnit
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ The wrapper can be run with:
|
|||
./tools/testing/kunit/kunit.py run
|
||||
|
||||
For more information on this wrapper (also called kunit_tool) check out the
|
||||
:doc:`kunit-tool` page.
|
||||
Documentation/dev-tools/kunit/kunit-tool.rst page.
|
||||
|
||||
Creating a .kunitconfig
|
||||
-----------------------
|
||||
|
|
@ -234,7 +234,7 @@ Congrats! You just wrote your first KUnit test!
|
|||
|
||||
Next Steps
|
||||
==========
|
||||
* Check out the :doc:`tips` page for tips on
|
||||
* Check out the Documentation/dev-tools/kunit/tips.rst page for tips on
|
||||
writing idiomatic KUnit tests.
|
||||
* Optional: see the :doc:`usage` page for a more
|
||||
in-depth explanation of KUnit.
|
||||
|
|
|
|||
|
|
@ -125,7 +125,8 @@ Here's a slightly in-depth example of how one could implement "mocking":
|
|||
|
||||
|
||||
Note: here we're able to get away with using ``test->priv``, but if you wanted
|
||||
something more flexible you could use a named ``kunit_resource``, see :doc:`api/test`.
|
||||
something more flexible you could use a named ``kunit_resource``, see
|
||||
Documentation/dev-tools/kunit/api/test.rst.
|
||||
|
||||
Failing the current test
|
||||
------------------------
|
||||
|
|
@ -185,5 +186,5 @@ Alternatively, one can take full control over the error message by using ``KUNIT
|
|||
|
||||
Next Steps
|
||||
==========
|
||||
* Optional: see the :doc:`usage` page for a more
|
||||
* Optional: see the Documentation/dev-tools/kunit/usage.rst page for a more
|
||||
in-depth explanation of KUnit.
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ understand it. This guide assumes a working knowledge of the Linux kernel and
|
|||
some basic knowledge of testing.
|
||||
|
||||
For a high level introduction to KUnit, including setting up KUnit for your
|
||||
project, see :doc:`start`.
|
||||
project, see Documentation/dev-tools/kunit/start.rst.
|
||||
|
||||
Organization of this document
|
||||
=============================
|
||||
|
|
@ -99,7 +99,8 @@ violated; however, the test will continue running, potentially trying other
|
|||
expectations until the test case ends or is otherwise terminated. This is as
|
||||
opposed to *assertions* which are discussed later.
|
||||
|
||||
To learn about more expectations supported by KUnit, see :doc:`api/test`.
|
||||
To learn about more expectations supported by KUnit, see
|
||||
Documentation/dev-tools/kunit/api/test.rst.
|
||||
|
||||
.. note::
|
||||
A single test case should be pretty short, pretty easy to understand,
|
||||
|
|
@ -216,7 +217,8 @@ test suite in a special linker section so that it can be run by KUnit either
|
|||
after late_init, or when the test module is loaded (depending on whether the
|
||||
test was built in or not).
|
||||
|
||||
For more information on these types of things see the :doc:`api/test`.
|
||||
For more information on these types of things see the
|
||||
Documentation/dev-tools/kunit/api/test.rst.
|
||||
|
||||
Common Patterns
|
||||
===============
|
||||
|
|
|
|||
|
|
@ -71,15 +71,15 @@ can be used to verify that a test is executing particular functions or lines
|
|||
of code. This is useful for determining how much of the kernel is being tested,
|
||||
and for finding corner-cases which are not covered by the appropriate test.
|
||||
|
||||
:doc:`gcov` is GCC's coverage testing tool, which can be used with the kernel
|
||||
to get global or per-module coverage. Unlike KCOV, it does not record per-task
|
||||
coverage. Coverage data can be read from debugfs, and interpreted using the
|
||||
usual gcov tooling.
|
||||
Documentation/dev-tools/gcov.rst is GCC's coverage testing tool, which can be
|
||||
used with the kernel to get global or per-module coverage. Unlike KCOV, it
|
||||
does not record per-task coverage. Coverage data can be read from debugfs,
|
||||
and interpreted using the usual gcov tooling.
|
||||
|
||||
:doc:`kcov` is a feature which can be built in to the kernel to allow
|
||||
capturing coverage on a per-task level. It's therefore useful for fuzzing and
|
||||
other situations where information about code executed during, for example, a
|
||||
single syscall is useful.
|
||||
Documentation/dev-tools/kcov.rst is a feature which can be built in to the
|
||||
kernel to allow capturing coverage on a per-task level. It's therefore useful
|
||||
for fuzzing and other situations where information about code executed during,
|
||||
for example, a single syscall is useful.
|
||||
|
||||
|
||||
Dynamic Analysis Tools
|
||||
|
|
|
|||
|
|
@ -7,8 +7,8 @@ Submitting Devicetree (DT) binding patches
|
|||
I. For patch submitters
|
||||
=======================
|
||||
|
||||
0) Normal patch submission rules from Documentation/process/submitting-patches.rst
|
||||
applies.
|
||||
0) Normal patch submission rules from
|
||||
Documentation/process/submitting-patches.rst applies.
|
||||
|
||||
1) The Documentation/ and include/dt-bindings/ portion of the patch should
|
||||
be a separate patch. The preferred subject prefix for binding patches is::
|
||||
|
|
@ -25,8 +25,8 @@ I. For patch submitters
|
|||
|
||||
make dt_binding_check
|
||||
|
||||
See Documentation/devicetree/bindings/writing-schema.rst for more details about
|
||||
schema and tools setup.
|
||||
See Documentation/devicetree/bindings/writing-schema.rst for more details
|
||||
about schema and tools setup.
|
||||
|
||||
3) DT binding files should be dual licensed. The preferred license tag is
|
||||
(GPL-2.0-only OR BSD-2-Clause).
|
||||
|
|
@ -84,7 +84,8 @@ II. For kernel maintainers
|
|||
III. Notes
|
||||
==========
|
||||
|
||||
0) Please see :doc:`ABI` for details regarding devicetree ABI.
|
||||
0) Please see Documentation/devicetree/bindings/ABI.rst for details
|
||||
regarding devicetree ABI.
|
||||
|
||||
1) This document is intended as a general familiarization with the process as
|
||||
decided at the 2013 Kernel Summit. When in doubt, the current word of the
|
||||
|
|
|
|||
|
|
@ -237,10 +237,10 @@ We have been trying to improve the situation through the creation of
|
|||
a set of "books" that group documentation for specific readers. These
|
||||
include:
|
||||
|
||||
- :doc:`../admin-guide/index`
|
||||
- :doc:`../core-api/index`
|
||||
- :doc:`../driver-api/index`
|
||||
- :doc:`../userspace-api/index`
|
||||
- Documentation/admin-guide/index.rst
|
||||
- Documentation/core-api/index.rst
|
||||
- Documentation/driver-api/index.rst
|
||||
- Documentation/userspace-api/index.rst
|
||||
|
||||
As well as this book on documentation itself.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,13 +9,13 @@ with them.
|
|||
|
||||
For examples of already existing generic drivers that will also be good
|
||||
examples for any other kernel drivers you want to author, refer to
|
||||
:doc:`drivers-on-gpio`
|
||||
Documentation/driver-api/gpio/drivers-on-gpio.rst
|
||||
|
||||
For any kind of mass produced system you want to support, such as servers,
|
||||
laptops, phones, tablets, routers, and any consumer or office or business goods
|
||||
using appropriate kernel drivers is paramount. Submit your code for inclusion
|
||||
in the upstream Linux kernel when you feel it is mature enough and you will get
|
||||
help to refine it, see :doc:`../../process/submitting-patches`.
|
||||
help to refine it, see Documentation/process/submitting-patches.rst.
|
||||
|
||||
In Linux GPIO lines also have a userspace ABI.
|
||||
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ _IO/_IOR/_IOW/_IOWR
|
|||
|
||||
type
|
||||
An 8-bit number, often a character literal, specific to a subsystem
|
||||
or driver, and listed in :doc:`../userspace-api/ioctl/ioctl-number`
|
||||
or driver, and listed in Documentation/userspace-api/ioctl/ioctl-number.rst
|
||||
|
||||
nr
|
||||
An 8-bit number identifying the specific command, unique for a give
|
||||
|
|
|
|||
|
|
@ -217,7 +217,7 @@ system-wide transition to a sleep state even though its :c:member:`runtime_auto`
|
|||
flag is clear.
|
||||
|
||||
For more information about the runtime power management framework, refer to
|
||||
:file:`Documentation/power/runtime_pm.rst`.
|
||||
Documentation/power/runtime_pm.rst.
|
||||
|
||||
|
||||
Calling Drivers to Enter and Leave System Sleep States
|
||||
|
|
@ -655,7 +655,7 @@ been thawed. Generally speaking, the PM notifiers are suitable for performing
|
|||
actions that either require user space to be available, or at least won't
|
||||
interfere with user space.
|
||||
|
||||
For details refer to :doc:`notifiers`.
|
||||
For details refer to Documentation/driver-api/pm/notifiers.rst.
|
||||
|
||||
|
||||
Device Low-Power (suspend) States
|
||||
|
|
@ -726,7 +726,7 @@ it into account in any way.
|
|||
|
||||
Devices may be defined as IRQ-safe which indicates to the PM core that their
|
||||
runtime PM callbacks may be invoked with disabled interrupts (see
|
||||
:file:`Documentation/power/runtime_pm.rst` for more information). If an
|
||||
Documentation/power/runtime_pm.rst for more information). If an
|
||||
IRQ-safe device belongs to a PM domain, the runtime PM of the domain will be
|
||||
disallowed, unless the domain itself is defined as IRQ-safe. However, it
|
||||
makes sense to define a PM domain as IRQ-safe only if all the devices in it
|
||||
|
|
@ -805,7 +805,7 @@ The ``DPM_FLAG_MAY_SKIP_RESUME`` Driver Flag
|
|||
--------------------------------------------
|
||||
|
||||
During system-wide resume from a sleep state it's easiest to put devices into
|
||||
the full-power state, as explained in :file:`Documentation/power/runtime_pm.rst`.
|
||||
the full-power state, as explained in Documentation/power/runtime_pm.rst.
|
||||
[Refer to that document for more information regarding this particular issue as
|
||||
well as for information on the device runtime power management framework in
|
||||
general.] However, it often is desirable to leave devices in suspend after
|
||||
|
|
|
|||
|
|
@ -5,7 +5,8 @@ Client Driver Documentation
|
|||
===========================
|
||||
|
||||
This is the documentation for client drivers themselves. Refer to
|
||||
:doc:`../client` for documentation on how to write client drivers.
|
||||
Documentation/driver-api/surface_aggregator/client.rst for documentation
|
||||
on how to write client drivers.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
|
|
|||
|
|
@ -87,10 +87,11 @@ native SSAM devices, i.e. devices that are not defined in ACPI and not
|
|||
implemented as platform devices, via |ssam_device| and |ssam_device_driver|
|
||||
simplify management of client devices and client drivers.
|
||||
|
||||
Refer to :doc:`client` for documentation regarding the client device/driver
|
||||
API and interface options for other kernel drivers. It is recommended to
|
||||
familiarize oneself with that chapter and the :doc:`ssh` before continuing
|
||||
with the architectural overview below.
|
||||
Refer to Documentation/driver-api/surface_aggregator/client.rst for
|
||||
documentation regarding the client device/driver API and interface options
|
||||
for other kernel drivers. It is recommended to familiarize oneself with
|
||||
that chapter and the Documentation/driver-api/surface_aggregator/ssh.rst
|
||||
before continuing with the architectural overview below.
|
||||
|
||||
|
||||
Packet Transport Layer
|
||||
|
|
@ -190,9 +191,9 @@ with success on the transmitter thread.
|
|||
|
||||
Transmission of sequenced packets is limited by the number of concurrently
|
||||
pending packets, i.e. a limit on how many packets may be waiting for an ACK
|
||||
from the EC in parallel. This limit is currently set to one (see :doc:`ssh`
|
||||
for the reasoning behind this). Control packets (i.e. ACK and NAK) can
|
||||
always be transmitted.
|
||||
from the EC in parallel. This limit is currently set to one (see
|
||||
Documentation/driver-api/surface_aggregator/ssh.rst for the reasoning behind
|
||||
this). Control packets (i.e. ACK and NAK) can always be transmitted.
|
||||
|
||||
Receiver Thread
|
||||
---------------
|
||||
|
|
|
|||
|
|
@ -73,5 +73,7 @@ being a direct response to a previous request. We may also refer to requests
|
|||
without response as commands. In general, events need to be enabled via one
|
||||
of multiple dedicated requests before they are sent by the EC.
|
||||
|
||||
See :doc:`ssh` for a more technical protocol documentation and
|
||||
:doc:`internal` for an overview of the internal driver architecture.
|
||||
See Documentation/driver-api/surface_aggregator/ssh.rst for a
|
||||
more technical protocol documentation and
|
||||
Documentation/driver-api/surface_aggregator/internal.rst for an
|
||||
overview of the internal driver architecture.
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ API overview
|
|||
|
||||
The big picture is that USB drivers can continue to ignore most DMA issues,
|
||||
though they still must provide DMA-ready buffers (see
|
||||
:doc:`/core-api/dma-api-howto`). That's how they've worked through
|
||||
Documentation/core-api/dma-api-howto.rst). That's how they've worked through
|
||||
the 2.4 (and earlier) kernels, or they can now be DMA-aware.
|
||||
|
||||
DMA-aware usb drivers:
|
||||
|
|
@ -60,7 +60,7 @@ and effects like cache-trashing can impose subtle penalties.
|
|||
force a consistent memory access ordering by using memory barriers. It's
|
||||
not using a streaming DMA mapping, so it's good for small transfers on
|
||||
systems where the I/O would otherwise thrash an IOMMU mapping. (See
|
||||
:doc:`/core-api/dma-api-howto` for definitions of "coherent" and
|
||||
Documentation/core-api/dma-api-howto.rst for definitions of "coherent" and
|
||||
"streaming" DMA mappings.)
|
||||
|
||||
Asking for 1/Nth of a page (as well as asking for N pages) is reasonably
|
||||
|
|
@ -91,7 +91,7 @@ Working with existing buffers
|
|||
Existing buffers aren't usable for DMA without first being mapped into the
|
||||
DMA address space of the device. However, most buffers passed to your
|
||||
driver can safely be used with such DMA mapping. (See the first section
|
||||
of :doc:`/core-api/dma-api-howto`, titled "What memory is DMA-able?")
|
||||
of Documentation/core-api/dma-api-howto.rst, titled "What memory is DMA-able?")
|
||||
|
||||
- When you're using scatterlists, you can map everything at once. On some
|
||||
systems, this kicks in an IOMMU and turns the scatterlists into single
|
||||
|
|
|
|||
|
|
@ -79,7 +79,8 @@ the ANOD object which is also the final target node of the reference.
|
|||
})
|
||||
}
|
||||
|
||||
Please also see a graph example in :doc:`graph`.
|
||||
Please also see a graph example in
|
||||
Documentation/firmware-guide/acpi/dsd/graph.rst.
|
||||
|
||||
References
|
||||
==========
|
||||
|
|
|
|||
|
|
@ -174,4 +174,4 @@ References
|
|||
referenced 2016-10-04.
|
||||
|
||||
[7] _DSD Device Properties Usage Rules.
|
||||
:doc:`../DSD-properties-rules`
|
||||
Documentation/firmware-guide/acpi/DSD-properties-rules.rst
|
||||
|
|
|
|||
|
|
@ -339,8 +339,8 @@ a code like this::
|
|||
There are also devm_* versions of these functions which release the
|
||||
descriptors once the device is released.
|
||||
|
||||
See Documentation/firmware-guide/acpi/gpio-properties.rst for more information about the
|
||||
_DSD binding related to GPIOs.
|
||||
See Documentation/firmware-guide/acpi/gpio-properties.rst for more information
|
||||
about the _DSD binding related to GPIOs.
|
||||
|
||||
MFD devices
|
||||
===========
|
||||
|
|
@ -460,7 +460,8 @@ the _DSD of the device object itself or the _DSD of its ancestor in the
|
|||
Otherwise, the _DSD itself is regarded as invalid and therefore the "compatible"
|
||||
property returned by it is meaningless.
|
||||
|
||||
Refer to :doc:`DSD-properties-rules` for more information.
|
||||
Refer to Documentation/firmware-guide/acpi/DSD-properties-rules.rst for more
|
||||
information.
|
||||
|
||||
PCI hierarchy representation
|
||||
============================
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ Declare the I2C devices via ACPI
|
|||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
ACPI can also describe I2C devices. There is special documentation for this
|
||||
which is currently located at :doc:`../firmware-guide/acpi/enumeration`.
|
||||
which is currently located at Documentation/firmware-guide/acpi/enumeration.rst.
|
||||
|
||||
|
||||
Declare the I2C devices in board files
|
||||
|
|
|
|||
|
|
@ -17,7 +17,8 @@ address), ``force`` (to forcibly attach the driver to a given device) and
|
|||
With the conversion of the I2C subsystem to the standard device driver
|
||||
binding model, it became clear that these per-module parameters were no
|
||||
longer needed, and that a centralized implementation was possible. The new,
|
||||
sysfs-based interface is described in :doc:`instantiating-devices`, section
|
||||
sysfs-based interface is described in
|
||||
Documentation/i2c/instantiating-devices.rst, section
|
||||
"Method 4: Instantiate from user-space".
|
||||
|
||||
Below is a mapping from the old module parameters to the new interface.
|
||||
|
|
|
|||
|
|
@ -27,8 +27,8 @@ a different protocol operation entirely.
|
|||
Each transaction type corresponds to a functionality flag. Before calling a
|
||||
transaction function, a device driver should always check (just once) for
|
||||
the corresponding functionality flag to ensure that the underlying I2C
|
||||
adapter supports the transaction in question. See :doc:`functionality` for
|
||||
the details.
|
||||
adapter supports the transaction in question. See
|
||||
Documentation/i2c/functionality.rst for the details.
|
||||
|
||||
|
||||
Key to symbols
|
||||
|
|
|
|||
|
|
@ -601,7 +601,7 @@ Defined in ``include/linux/export.h``
|
|||
|
||||
This is the variant of `EXPORT_SYMBOL()` that allows specifying a symbol
|
||||
namespace. Symbol Namespaces are documented in
|
||||
:doc:`../core-api/symbol-namespaces`
|
||||
Documentation/core-api/symbol-namespaces.rst
|
||||
|
||||
:c:func:`EXPORT_SYMBOL_NS_GPL()`
|
||||
--------------------------------
|
||||
|
|
@ -610,7 +610,7 @@ Defined in ``include/linux/export.h``
|
|||
|
||||
This is the variant of `EXPORT_SYMBOL_GPL()` that allows specifying a symbol
|
||||
namespace. Symbol Namespaces are documented in
|
||||
:doc:`../core-api/symbol-namespaces`
|
||||
Documentation/core-api/symbol-namespaces.rst
|
||||
|
||||
Routines and Conventions
|
||||
========================
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ The major benefit to creating a region is to provide access to internal
|
|||
address regions that are otherwise inaccessible to the user.
|
||||
|
||||
Regions may also be used to provide an additional way to debug complex error
|
||||
states, but see also :doc:`devlink-health`
|
||||
states, but see also Documentation/networking/devlink/devlink-health.rst
|
||||
|
||||
Regions may optionally support capturing a snapshot on demand via the
|
||||
``DEVLINK_CMD_REGION_NEW`` netlink message. A driver wishing to allow
|
||||
|
|
|
|||
|
|
@ -495,8 +495,8 @@ help debug packet drops caused by these exceptions. The following list includes
|
|||
links to the description of driver-specific traps registered by various device
|
||||
drivers:
|
||||
|
||||
* :doc:`netdevsim`
|
||||
* :doc:`mlxsw`
|
||||
* Documentation/networking/devlink/netdevsim.rst
|
||||
* Documentation/networking/devlink/mlxsw.rst
|
||||
|
||||
.. _Generic-Packet-Trap-Groups:
|
||||
|
||||
|
|
|
|||
|
|
@ -10,10 +10,11 @@ can greatly increase the chances of your change being accepted.
|
|||
|
||||
This document contains a large number of suggestions in a relatively terse
|
||||
format. For detailed information on how the kernel development process
|
||||
works, see :doc:`development-process`. Also, read :doc:`submit-checklist`
|
||||
works, see Documentation/process/development-process.rst. Also, read
|
||||
Documentation/process/submit-checklist.rst
|
||||
for a list of items to check before submitting code. If you are submitting
|
||||
a driver, also read :doc:`submitting-drivers`; for device tree binding patches,
|
||||
read :doc:`submitting-patches`.
|
||||
a driver, also read Documentation/process/submitting-drivers.rst; for device
|
||||
tree binding patches, read Documentation/process/submitting-patches.rst.
|
||||
|
||||
This documentation assumes that you're using ``git`` to prepare your patches.
|
||||
If you're unfamiliar with ``git``, you would be well-advised to learn how to
|
||||
|
|
@ -178,8 +179,7 @@ Style-check your changes
|
|||
------------------------
|
||||
|
||||
Check your patch for basic style violations, details of which can be
|
||||
found in
|
||||
:ref:`Documentation/process/coding-style.rst <codingstyle>`.
|
||||
found in Documentation/process/coding-style.rst.
|
||||
Failure to do so simply wastes
|
||||
the reviewers time and will get your patch rejected, probably
|
||||
without even being read.
|
||||
|
|
@ -238,7 +238,7 @@ If you have a patch that fixes an exploitable security bug, send that patch
|
|||
to security@kernel.org. For severe bugs, a short embargo may be considered
|
||||
to allow distributors to get the patch out to users; in such cases,
|
||||
obviously, the patch should not be sent to any public lists. See also
|
||||
:doc:`/admin-guide/security-bugs`.
|
||||
Documentation/admin-guide/security-bugs.rst.
|
||||
|
||||
Patches that fix a severe bug in a released kernel should be directed
|
||||
toward the stable maintainers by putting a line like this::
|
||||
|
|
@ -246,9 +246,8 @@ toward the stable maintainers by putting a line like this::
|
|||
Cc: stable@vger.kernel.org
|
||||
|
||||
into the sign-off area of your patch (note, NOT an email recipient). You
|
||||
should also read
|
||||
:ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
|
||||
in addition to this file.
|
||||
should also read Documentation/process/stable-kernel-rules.rst
|
||||
in addition to this document.
|
||||
|
||||
If changes affect userland-kernel interfaces, please send the MAN-PAGES
|
||||
maintainer (as listed in the MAINTAINERS file) a man-pages patch, or at
|
||||
|
|
@ -305,8 +304,8 @@ decreasing the likelihood of your MIME-attached change being accepted.
|
|||
Exception: If your mailer is mangling patches then someone may ask
|
||||
you to re-send them using MIME.
|
||||
|
||||
See :doc:`/process/email-clients` for hints about configuring your e-mail
|
||||
client so that it sends your patches untouched.
|
||||
See Documentation/process/email-clients.rst for hints about configuring
|
||||
your e-mail client so that it sends your patches untouched.
|
||||
|
||||
Respond to review comments
|
||||
--------------------------
|
||||
|
|
@ -324,7 +323,7 @@ for their time. Code review is a tiring and time-consuming process, and
|
|||
reviewers sometimes get grumpy. Even in that case, though, respond
|
||||
politely and address the problems they have pointed out.
|
||||
|
||||
See :doc:`email-clients` for recommendations on email
|
||||
See Documentation/process/email-clients.rst for recommendations on email
|
||||
clients and mailing list etiquette.
|
||||
|
||||
|
||||
|
|
@ -562,10 +561,10 @@ method for indicating a bug fixed by the patch. See :ref:`describe_changes`
|
|||
for more details.
|
||||
|
||||
Note: Attaching a Fixes: tag does not subvert the stable kernel rules
|
||||
process nor the requirement to Cc: stable@vger.kernel.org on all stable
|
||||
process nor the requirement to Cc: stable@vger.kernel.org on all stable
|
||||
patch candidates. For more information, please read
|
||||
:ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
|
||||
|
||||
Documentation/process/stable-kernel-rules.rst.
|
||||
|
||||
.. _the_canonical_patch_format:
|
||||
|
||||
The canonical patch format
|
||||
|
|
@ -824,8 +823,7 @@ Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
|
|||
NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
|
||||
<https://lore.kernel.org/r/20050711.125305.08322243.davem@davemloft.net>
|
||||
|
||||
Kernel Documentation/process/coding-style.rst:
|
||||
:ref:`Documentation/process/coding-style.rst <codingstyle>`
|
||||
Kernel Documentation/process/coding-style.rst
|
||||
|
||||
Linus Torvalds's mail on the canonical patch format:
|
||||
<https://lore.kernel.org/r/Pine.LNX.4.58.0504071023190.28951@ppc970.osdl.org>
|
||||
|
|
|
|||
|
|
@ -25,7 +25,8 @@ Any user can enforce Landlock rulesets on their processes. They are merged and
|
|||
evaluated according to the inherited ones in a way that ensures that only more
|
||||
constraints can be added.
|
||||
|
||||
User space documentation can be found here: :doc:`/userspace-api/landlock`.
|
||||
User space documentation can be found here:
|
||||
Documentation/userspace-api/landlock.rst.
|
||||
|
||||
Guiding principles for safe access controls
|
||||
===========================================
|
||||
|
|
|
|||
|
|
@ -315,7 +315,8 @@ intermediate links as required.
|
|||
|
||||
Note: ``cti_sys0`` appears in two of the connections lists above.
|
||||
CTIs can connect to multiple devices and are arranged in a star topology
|
||||
via the CTM. See (:doc:`coresight-ect`) [#fourth]_ for further details.
|
||||
via the CTM. See (Documentation/trace/coresight/coresight-ect.rst)
|
||||
[#fourth]_ for further details.
|
||||
Looking at this device we see 4 connections::
|
||||
|
||||
linaro-developer:~# ls -l /sys/bus/coresight/devices/cti_sys0/connections
|
||||
|
|
@ -606,7 +607,8 @@ interface provided for that purpose by the generic STM API::
|
|||
crw------- 1 root root 10, 61 Jan 3 18:11 /dev/stm0
|
||||
root@genericarmv8:~#
|
||||
|
||||
Details on how to use the generic STM API can be found here:- :doc:`../stm` [#second]_.
|
||||
Details on how to use the generic STM API can be found here:
|
||||
- Documentation/trace/stm.rst [#second]_.
|
||||
|
||||
The CTI & CTM Modules
|
||||
---------------------
|
||||
|
|
@ -616,7 +618,7 @@ individual CTIs and components, and can propagate these between all CTIs via
|
|||
channels on the CTM (Cross Trigger Matrix).
|
||||
|
||||
A separate documentation file is provided to explain the use of these devices.
|
||||
(:doc:`coresight-ect`) [#fourth]_.
|
||||
(Documentation/trace/coresight/coresight-ect.rst) [#fourth]_.
|
||||
|
||||
|
||||
.. [#first] Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ See events.rst for more information.
|
|||
Implementation Details
|
||||
----------------------
|
||||
|
||||
See :doc:`ftrace-design` for details for arch porters and such.
|
||||
See Documentation/trace/ftrace-design.rst for details for arch porters and such.
|
||||
|
||||
|
||||
The File System
|
||||
|
|
|
|||
|
|
@ -145,7 +145,8 @@ Bind mounts and OverlayFS
|
|||
|
||||
Landlock enables to restrict access to file hierarchies, which means that these
|
||||
access rights can be propagated with bind mounts (cf.
|
||||
:doc:`/filesystems/sharedsubtree`) but not with :doc:`/filesystems/overlayfs`.
|
||||
Documentation/filesystems/sharedsubtree.rst) but not with
|
||||
Documentation/filesystems/overlayfs.rst.
|
||||
|
||||
A bind mount mirrors a source file hierarchy to a destination. The destination
|
||||
hierarchy is then composed of the exact same files, on which Landlock rules can
|
||||
|
|
@ -170,8 +171,8 @@ Inheritance
|
|||
|
||||
Every new thread resulting from a :manpage:`clone(2)` inherits Landlock domain
|
||||
restrictions from its parent. This is similar to the seccomp inheritance (cf.
|
||||
:doc:`/userspace-api/seccomp_filter`) or any other LSM dealing with task's
|
||||
:manpage:`credentials(7)`. For instance, one process's thread may apply
|
||||
Documentation/userspace-api/seccomp_filter.rst) or any other LSM dealing with
|
||||
task's :manpage:`credentials(7)`. For instance, one process's thread may apply
|
||||
Landlock rules to itself, but they will not be automatically applied to other
|
||||
sibling threads (unlike POSIX thread credential changes, cf.
|
||||
:manpage:`nptl(7)`).
|
||||
|
|
@ -278,7 +279,7 @@ Memory usage
|
|||
------------
|
||||
|
||||
Kernel memory allocated to create rulesets is accounted and can be restricted
|
||||
by the :doc:`/admin-guide/cgroup-v1/memory`.
|
||||
by the Documentation/admin-guide/cgroup-v1/memory.rst.
|
||||
|
||||
Questions and answers
|
||||
=====================
|
||||
|
|
@ -303,7 +304,7 @@ issues, especially when untrusted processes can manipulate them (cf.
|
|||
Additional documentation
|
||||
========================
|
||||
|
||||
* :doc:`/security/landlock`
|
||||
* Documentation/security/landlock.rst
|
||||
* https://landlock.io
|
||||
|
||||
.. Links
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ The memory of Protected Virtual Machines (PVMs) is not accessible to
|
|||
I/O or the hypervisor. In those cases where the hypervisor needs to
|
||||
access the memory of a PVM, that memory must be made accessible.
|
||||
Memory made accessible to the hypervisor will be encrypted. See
|
||||
:doc:`s390-pv` for details."
|
||||
Documentation/virt/kvm/s390-pv.rst for details."
|
||||
|
||||
On IPL (boot) a small plaintext bootloader is started, which provides
|
||||
information about the encrypted components and necessary metadata to
|
||||
|
|
|
|||
|
|
@ -1343,7 +1343,7 @@ follow::
|
|||
In addition to read/modify/write the setup header of the struct
|
||||
boot_params as that of 16-bit boot protocol, the boot loader should
|
||||
also fill the additional fields of the struct boot_params as
|
||||
described in chapter :doc:`zero-page`.
|
||||
described in chapter Documentation/x86/zero-page.rst.
|
||||
|
||||
After setting up the struct boot_params, the boot loader can load the
|
||||
32/64-bit kernel in the same way as that of 16-bit boot protocol.
|
||||
|
|
@ -1379,7 +1379,7 @@ can be calculated as follows::
|
|||
In addition to read/modify/write the setup header of the struct
|
||||
boot_params as that of 16-bit boot protocol, the boot loader should
|
||||
also fill the additional fields of the struct boot_params as described
|
||||
in chapter :doc:`zero-page`.
|
||||
in chapter Documentation/x86/zero-page.rst.
|
||||
|
||||
After setting up the struct boot_params, the boot loader can load
|
||||
64-bit kernel in the same way as that of 16-bit boot protocol, but
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ are aligned with platform MTRR setup. If MTRRs are only set up by the platform
|
|||
firmware code though and the OS does not make any specific MTRR mapping
|
||||
requests mtrr_type_lookup() should always return MTRR_TYPE_INVALID.
|
||||
|
||||
For details refer to :doc:`pat`.
|
||||
For details refer to Documentation/x86/pat.rst.
|
||||
|
||||
.. tip::
|
||||
On Intel P6 family processors (Pentium Pro, Pentium II and later)
|
||||
|
|
|
|||
Loading…
Reference in a new issue