Commit 5b9b4161 authored by Linus Torvalds's avatar Linus Torvalds

Merge tag 'docs-6.8' of git://git.lwn.net/linux

Pull documentation update from Jonathan Corbet:
 "Another moderately busy cycle for documentation, including:

   - The minimum Sphinx requirement has been raised to 2.4.4, following
     a warning that was added in 6.2

   - Some reworking of the Documentation/process front page to,
     hopefully, make it more useful

   - Various kernel-doc tweaks to, for example, make it deal properly
     with __counted_by annotations

   - We have also restored a warning for documentation of nonexistent
     structure members that disappeared a while back. That had the
     delightful consequence of adding some 600 warnings to the docs
     build. A sustained effort by Randy, Vegard, and myself has
     addressed almost all of those, bringing the documentation back into
     sync with the code. The fixes are going through the appropriate
     maintainer trees

   - Various improvements to the HTML rendered docs, including automatic
     links to Git revisions and a nice new pulldown to make translations
     easy to access

   - Speaking of translations, more of those for Spanish and Chinese

  ... plus the usual stream of documentation updates and typo fixes"

* tag 'docs-6.8' of git://git.lwn.net/linux: (57 commits)
  MAINTAINERS: use tabs for indent of CONFIDENTIAL COMPUTING THREAT MODEL
  A reworked process/index.rst
  ring-buffer/Documentation: Add documentation on buffer_percent file
  Translated the RISC-V architecture boot documentation.
  Docs: remove mentions of fdformat from util-linux
  Docs/zh_CN: Fix the meaning of DEBUG to pr_debug()
  Documentation: move driver-api/dcdbas to userspace-api/
  Documentation: move driver-api/isapnp to userspace-api/
  Documentation/core-api : fix typo in workqueue
  Documentation/trace: Fixed typos in the ftrace FLAGS section
  kernel-doc: handle a void function without producing a warning
  scripts/get_abi.pl: ignore some temp files
  docs: kernel_abi.py: fix command injection
  scripts/get_abi: fix source path leak
  CREDITS, MAINTAINERS, docs/process/howto: Update man-pages' maintainer
  docs: translations: add translations links when they exist
  kernel-doc: Align quick help and the code
  MAINTAINERS: add reviewer for Spanish translations
  docs: ignore __counted_by attribute in structure definitions
  scripts: kernel-doc: Clarify missing struct member description
  ..
parents 22d29f11 2d179e8a
......@@ -1835,6 +1835,13 @@ S: K osmidomkum 723
S: 160 00 Praha 6
S: Czech Republic
N: Michael Kerrisk
E: mtk.manpages@gmail.com
W: https://man7.org/
P: 4096R/3A35CE5E E522 595B 52ED A4E6 BFCC CB5E 8561 9911 3A35 CE5E
D: Maintainer of the Linux man-pages project
D: Linux man pages online, at <https://man7.org/linux/man-pages/>
N: Niels Kristian Bech Jensen
E: nkbj1970@hotmail.com
D: Miscellaneous kernel updates and fixes.
......
......@@ -7,5 +7,5 @@ marked to be removed at some later point in time.
The description of the interface will document the reason why it is
obsolete and when it can be expected to be removed.
.. kernel-abi:: $srctree/Documentation/ABI/obsolete
.. kernel-abi:: ABI/obsolete
:rst:
ABI removed symbols
===================
.. kernel-abi:: $srctree/Documentation/ABI/removed
.. kernel-abi:: ABI/removed
:rst:
......@@ -10,5 +10,5 @@ for at least 2 years.
Most interfaces (like syscalls) are expected to never change and always
be available.
.. kernel-abi:: $srctree/Documentation/ABI/stable
.. kernel-abi:: ABI/stable
:rst:
......@@ -16,5 +16,5 @@ Programs that use these interfaces are strongly encouraged to add their
name to the description of these interfaces, so that the kernel
developers can easily notify them if any changes occur.
.. kernel-abi:: $srctree/Documentation/ABI/testing
.. kernel-abi:: ABI/testing
:rst:
......@@ -321,13 +321,13 @@ Examples
:#> ddcmd 'format "nfsd: READ" +p'
// enable messages in files of which the paths include string "usb"
:#> ddcmd 'file *usb* +p' > /proc/dynamic_debug/control
:#> ddcmd 'file *usb* +p'
// enable all messages
:#> ddcmd '+p' > /proc/dynamic_debug/control
:#> ddcmd '+p'
// add module, function to all enabled messages
:#> ddcmd '+mf' > /proc/dynamic_debug/control
:#> ddcmd '+mf'
// boot-args example, with newlines and comments for readability
Kernel command line: ...
......
accept_memory= [MM]
Format: { eager | lazy }
default: lazy
By default, unaccepted memory is accepted lazily to
avoid prolonged boot times. The lazy option will add
some runtime overhead until all memory is eventually
accepted. In most cases the overhead is negligible.
For some workloads or for debugging purposes
accept_memory=eager can be used to accept all memory
at once during boot.
acpi= [HW,ACPI,X86,ARM64,RISCV64]
Advanced Configuration and Power Interface
Format: { force | on | off | strict | noirq | rsdt |
......
......@@ -20,16 +20,8 @@ Documentation/driver-api/media/index.rst
- for driver development information and Kernel APIs used by
media devices;
The media subsystem
===================
.. only:: html
.. class:: toc-title
Table of Contents
.. toctree::
:caption: Table of Contents
:maxdepth: 2
:numbered:
......
......@@ -71,7 +71,7 @@ Protocol 2.13 (Kernel 3.14) Support 32- and 64-bit flags being set in
Protocol 2.14 BURNT BY INCORRECT COMMIT
ae7e1238e68f2a472a125673ab506d49158c1889
(x86/boot: Add ACPI RSDP address to setup_header)
("x86/boot: Add ACPI RSDP address to setup_header")
DO NOT USE!!! ASSUME SAME AS 2.13.
Protocol 2.15 (Kernel 5.5) Added the kernel_info and kernel_info.setup_type_max.
......
......@@ -272,10 +272,8 @@ In this case, if the base type is an int type, it must be a regular int type:
* ``BTF_INT_OFFSET()`` must be 0.
* ``BTF_INT_BITS()`` must be equal to ``{1,2,4,8,16} * 8``.
The following kernel patch introduced ``kind_flag`` and explained why both
modes exist:
https://github.com/torvalds/linux/commit/9d5f9f701b1891466fb3dbb1806ad97716f95cc3#diff-fa650a64fdd3968396883d2fe8215ff3
Commit 9d5f9f701b18 introduced ``kind_flag`` and explains why both modes
exist.
2.2.6 BTF_KIND_ENUM
~~~~~~~~~~~~~~~~~~~
......
......@@ -47,7 +47,7 @@ from load_config import loadConfig
# -- General configuration ------------------------------------------------
# If your documentation needs a minimal Sphinx version, state it here.
needs_sphinx = '1.7'
needs_sphinx = '2.4.4'
# Add any Sphinx extension module names here, as strings. They can be
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
......@@ -55,7 +55,7 @@ needs_sphinx = '1.7'
extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include',
'kfigure', 'sphinx.ext.ifconfig', 'automarkup',
'maintainers_include', 'sphinx.ext.autosectionlabel',
'kernel_abi', 'kernel_feat']
'kernel_abi', 'kernel_feat', 'translations']
if major >= 3:
if (major > 3) or (minor > 0 or patch >= 2):
......@@ -106,6 +106,7 @@ if major >= 3:
"__weak",
"noinline",
"__fix_address",
"__counted_by",
# include/linux/memblock.h:
"__init_memblock",
......@@ -357,6 +358,10 @@ html_sidebars = { '**': ['searchbox.html', 'kernel-toc.html', 'sourcelink.html']
if html_theme == 'alabaster':
html_sidebars['**'].insert(0, 'about.html')
# The name of an image file (relative to this directory) to place at the top
# of the sidebar.
html_logo = 'images/logo.svg'
# Output file base name for HTML help builder.
htmlhelp_basename = 'TheLinuxKerneldoc'
......
......@@ -8,7 +8,7 @@ Dynamic DMA mapping Guide
This is a guide to device driver writers on how to use the DMA API
with example pseudo-code. For a concise description of the API, see
DMA-API.txt.
Documentation/core-api/dma-api.rst.
CPU and DMA addresses
=====================
......
......@@ -448,7 +448,7 @@ DMA address entries returned.
Synchronise a single contiguous or scatter/gather mapping for the CPU
and device. With the sync_sg API, all the parameters must be the same
as those passed into the single mapping API. With the sync_single API,
as those passed into the sg mapping API. With the sync_single API,
you can use dma_handle and size parameters that aren't identical to
those passed into the single mapping API to do a partial sync.
......
......@@ -379,7 +379,7 @@ Workqueue currently supports the following affinity scopes.
cases. This is the default affinity scope.
``numa``
CPUs are grouped according to NUMA bounaries.
CPUs are grouped according to NUMA boundaries.
``system``
All CPUs are put in the same group. Workqueue makes no effort to process a
......
Programming Interface
=====================
.. class:: toc-title
Table of contents
.. toctree::
:caption: Table of contents
:maxdepth: 2
api-skcipher
......
......@@ -9,11 +9,8 @@ This documentation outlines the Linux kernel crypto API with its
concepts, details about developing cipher implementations, employment of the API
for cryptographic use cases, as well as programming examples.
.. class:: toc-title
Table of contents
.. toctree::
:caption: Table of contents
:maxdepth: 2
intro
......
......@@ -10,11 +10,8 @@ whole; patches welcome!
A brief overview of testing-specific tools can be found in
Documentation/dev-tools/testing-overview.rst
.. class:: toc-title
Table of contents
.. toctree::
:caption: Table of contents
:maxdepth: 2
testing-overview
......
......@@ -28,7 +28,7 @@ Sphinx Install
==============
The ReST markups currently used by the Documentation/ files are meant to be
built with ``Sphinx`` version 1.7 or higher.
built with ``Sphinx`` version 2.4.4 or higher.
There's a script that checks for the Sphinx requirements. Please see
:ref:`sphinx-pre-install` for further details.
......@@ -435,6 +435,15 @@ path.
For information on cross-referencing to kernel-doc functions or types, see
Documentation/doc-guide/kernel-doc.rst.
Referencing commits
~~~~~~~~~~~~~~~~~~~
References to git commits are automatically hyperlinked given that they are
written in one of these formats::
commit 72bf4f1767f0
commit 72bf4f1767f0 ("net: do not leave an empty skb in write queue")
.. _sphinx_kfigure:
Figures & Images
......
......@@ -9,11 +9,8 @@ of device drivers. This document is an only somewhat organized collection
of some of those interfaces — it will hopefully get better over time! The
available subsections can be seen below.
.. class:: toc-title
Table of contents
.. toctree::
:caption: Table of contents
:maxdepth: 2
driver-model/index
......@@ -81,10 +78,8 @@ available subsections can be seen below.
backlight/lp855x-driver.rst
connector
console
dcdbas
eisa
isa
isapnp
io-mapping
io_ordering
generic-counter
......@@ -117,6 +112,7 @@ available subsections can be seen below.
dpll
wbrf
crypto/index
tee
.. only:: subproject and html
......
......@@ -20,13 +20,8 @@ Documentation/userspace-api/media/index.rst
- for the userspace APIs used on media devices.
.. only:: html
.. class:: toc-title
Table of Contents
.. toctree::
:caption: Table of Contents
:maxdepth: 5
:numbered:
......
......@@ -9,13 +9,8 @@ Intel(R) Management Engine Interface (Intel(R) MEI)
**Copyright** |copy| 2019 Intel Corporation
.. only:: html
.. class:: toc-title
Table of Contents
.. toctree::
:caption: Table of Contents
:maxdepth: 3
mei
......
......@@ -41,7 +41,7 @@ A NVMEM provider can register with NVMEM core by supplying relevant
nvmem configuration to nvmem_register(), on success core would return a valid
nvmem_device pointer.
nvmem_unregister(nvmem) is used to unregister a previously registered provider.
nvmem_unregister() is used to unregister a previously registered provider.
For example, a simple nvram case::
......@@ -200,3 +200,9 @@ and let you add cells dynamically.
Another use case for layouts is the post processing of cells. With layouts,
it is possible to associate a custom post processing hook to a cell. It
even possible to add this hook to cells not created by the layout itself.
9. Internal kernel API
======================
.. kernel-doc:: drivers/nvmem/core.c
:export:
......@@ -4,11 +4,8 @@
The Linux PCI driver implementer's API guide
============================================
.. class:: toc-title
Table of contents
.. toctree::
:caption: Table of contents
:maxdepth: 2
pci
......
.. SPDX-License-Identifier: GPL-2.0
===============================================
TEE (Trusted Execution Environment) driver API
===============================================
Kernel provides a TEE bus infrastructure where a Trusted Application is
represented as a device identified via Universally Unique Identifier (UUID) and
client drivers register a table of supported device UUIDs.
TEE bus infrastructure registers following APIs:
match():
iterates over the client driver UUID table to find a corresponding
match for device UUID. If a match is found, then this particular device is
probed via corresponding probe API registered by the client driver. This
process happens whenever a device or a client driver is registered with TEE
bus.
uevent():
notifies user-space (udev) whenever a new device is registered on
TEE bus for auto-loading of modularized client drivers.
TEE bus device enumeration is specific to underlying TEE implementation, so it
is left open for TEE drivers to provide corresponding implementation.
Then TEE client driver can talk to a matched Trusted Application using APIs
listed in include/linux/tee_drv.h.
TEE client driver example
-------------------------
Suppose a TEE client driver needs to communicate with a Trusted Application
having UUID: ``ac6a4085-0e82-4c33-bf98-8eb8e118b6c2``, so driver registration
snippet would look like::
static const struct tee_client_device_id client_id_table[] = {
{UUID_INIT(0xac6a4085, 0x0e82, 0x4c33,
0xbf, 0x98, 0x8e, 0xb8, 0xe1, 0x18, 0xb6, 0xc2)},
{}
};
MODULE_DEVICE_TABLE(tee, client_id_table);
static struct tee_client_driver client_driver = {
.id_table = client_id_table,
.driver = {
.name = DRIVER_NAME,
.bus = &tee_bus_type,
.probe = client_probe,
.remove = client_remove,
},
};
static int __init client_init(void)
{
return driver_register(&client_driver.driver);
}
static void __exit client_exit(void)
{
driver_unregister(&client_driver.driver);
}
module_init(client_init);
module_exit(client_exit);
......@@ -437,7 +437,7 @@ field. This is a pointer to a "struct inode_operations" which describes
the methods that can be performed on individual inodes.
struct xattr_handlers
struct xattr_handler
---------------------
On filesystems that support extended attributes (xattrs), the s_xattr
......
......@@ -4,11 +4,8 @@
Linux Input Subsystem kernel API
################################
.. class:: toc-title
Table of Contents
.. toctree::
:caption: Table of Contents
:maxdepth: 2
:numbered:
......
......@@ -4,11 +4,8 @@
Linux Input Subsystem userspace API
###################################
.. class:: toc-title
Table of Contents
.. toctree::
:caption: Table of Contents
:maxdepth: 2
:numbered:
......
......@@ -6,11 +6,8 @@ Linux Joystick support
:Copyright: |copy| 1996-2000 Vojtech Pavlik <vojtech@ucw.cz> - Sponsored by SuSE
.. class:: toc-title
Table of Contents
.. toctree::
:caption: Table of Contents
:maxdepth: 3
joystick
......
......@@ -110,7 +110,7 @@ Global data update
------------------
A pre-patch callback can be useful to update a global variable. For
example, 75ff39ccc1bd ("tcp: make challenge acks less predictable")
example, commit 75ff39ccc1bd ("tcp: make challenge acks less predictable")
changes a global sysctl, as well as patches the tcp_send_challenge_ack()
function.
......@@ -126,7 +126,7 @@ Although __init and probe functions are not directly livepatch-able, it
may be possible to implement similar updates via pre/post-patch
callbacks.
The commit ``48900cb6af42 ("virtio-net: drop NETIF_F_FRAGLIST")`` change the way that
The commit 48900cb6af42 ("virtio-net: drop NETIF_F_FRAGLIST") change the way that
virtnet_probe() initialized its driver's net_device features. A
pre/post-patch callback could iterate over all such devices, making a
similar change to their hw_features value. (Client functions of the
......
......@@ -7,11 +7,8 @@ Assorted Miscellaneous Devices Documentation
This documentation contains information for assorted devices that do not
fit into other categories.
.. class:: toc-title
Table of contents
.. toctree::
:caption: Table of contents
:maxdepth: 2
ad525x_dpot
......
......@@ -313,7 +313,7 @@ https://lwn.net/Articles/576263/
* TcpExtTCPOrigDataSent
This counter is explained by `kernel commit f19c29e3e391`_, I pasted the
This counter is explained by kernel commit f19c29e3e391, I pasted the
explanation below::
TCPOrigDataSent: number of outgoing packets with original data (excluding
......@@ -323,7 +323,7 @@ explanation below::
* TCPSynRetrans
This counter is explained by `kernel commit f19c29e3e391`_, I pasted the
This counter is explained by kernel commit f19c29e3e391, I pasted the
explanation below::
TCPSynRetrans: number of SYN and SYN/ACK retransmits to break down
......@@ -331,14 +331,12 @@ explanation below::
* TCPFastOpenActiveFail
This counter is explained by `kernel commit f19c29e3e391`_, I pasted the
This counter is explained by kernel commit f19c29e3e391, I pasted the
explanation below::
TCPFastOpenActiveFail: Fast Open attempts (SYN/data) failed because
the remote does not accept it or the attempts timed out.
.. _kernel commit f19c29e3e391: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f19c29e3e391a66a273e9afebaf01917245148cd
* TcpExtListenOverflows and TcpExtListenDrops
When kernel receives a SYN from a client, and if the TCP accept queue
......@@ -698,11 +696,9 @@ number of the SACK block. For more details, please refer the comment
of the function tcp_is_sackblock_valid in the kernel source code. A
SACK option could have up to 4 blocks, they are checked
individually. E.g., if 3 blocks of a SACk is invalid, the
corresponding counter would be updated 3 times. The comment of the
`Add counters for discarded SACK blocks`_ patch has additional
explanation:
.. _Add counters for discarded SACK blocks: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=18f02545a9a16c9a89778b91a162ad16d510bb32
corresponding counter would be updated 3 times. The comment of commit
18f02545a9a1 ("[TCP] MIB: Add counters for discarded SACK blocks")
has additional explanation:
* TcpExtTCPSACKDiscard
......
......@@ -39,7 +39,7 @@ binutils 2.25 ld -v
flex 2.5.35 flex --version
bison 2.0 bison --version
pahole 1.16 pahole --version
util-linux 2.10o fdformat --version
util-linux 2.10o mount --version
kmod 13 depmod -V
e2fsprogs 1.41.4 e2fsck -V
jfsutils 1.1.3 fsck.jfs -V
......@@ -58,7 +58,7 @@ mcelog 0.6 mcelog --version
iptables 1.4.2 iptables -V
openssl & libcrypto 1.0.0 openssl version
bc 1.06.95 bc --version
Sphinx\ [#f1]_ 1.7 sphinx-build --version
Sphinx\ [#f1]_ 2.4.4 sphinx-build --version
cpio any cpio --version
GNU tar 1.28 tar --version
gtags (optional) 6.6.5 gtags --version
......@@ -213,7 +213,7 @@ Util-linux
New versions of util-linux provide ``fdisk`` support for larger disks,
support new options to mount, recognize more supported partition
types, have a fdformat which works with 2.4 kernels, and similar goodies.
types, and similar goodies.
You'll probably want to upgrade.
Ksymoops
......
......@@ -3,9 +3,17 @@
A guide to the Kernel Development Process
=========================================
Contents:
The purpose of this document is to help developers (and their managers)
work with the development community with a minimum of frustration. It is
an attempt to document how this community works in a way which is
accessible to those who are not intimately familiar with Linux kernel
development (or, indeed, free software development in general). While
there is some technical material here, this is very much a process-oriented
discussion which does not require a deep knowledge of kernel programming to
understand.
.. toctree::
:caption: Contents
:numbered:
:maxdepth: 2
......@@ -17,12 +25,3 @@ Contents:
6.Followthrough
7.AdvancedTopics
8.Conclusion
The purpose of this document is to help developers (and their managers)
work with the development community with a minimum of frustration. It is
an attempt to document how this community works in a way which is
accessible to those who are not intimately familiar with Linux kernel
development (or, indeed, free software development in general). While
there is some technical material here, this is very much a process-oriented
discussion which does not require a deep knowledge of kernel programming to
understand.
......@@ -82,8 +82,7 @@ documentation files are also added which explain how to use the feature.
When a kernel change causes the interface that the kernel exposes to
userspace to change, it is recommended that you send the information or
a patch to the manual pages explaining the change to the manual pages
maintainer at mtk.manpages@gmail.com, and CC the list
linux-api@vger.kernel.org.
maintainer at alx@kernel.org, and CC the list linux-api@vger.kernel.org.
Here is a list of files that are in the kernel source tree that are
required reading:
......
......@@ -15,49 +15,96 @@ to learn about how our community works. Reading these documents will make
it much easier for you to get your changes merged with a minimum of
trouble.
Below are the essential guides that every developer should read.
An introduction to how kernel development works
-----------------------------------------------
Read these documents first: an understanding of the material here will ease
your entry into the kernel community.
.. toctree::
:maxdepth: 1
license-rules
howto
code-of-conduct
code-of-conduct-interpretation
development-process
submitting-patches
handling-regressions
submit-checklist
Tools and technical guides for kernel developers
------------------------------------------------
This is a collection of material that kernel developers should be familiar
with.
.. toctree::
:maxdepth: 1
changes
programming-language
coding-style
maintainer-handbooks
maintainer-pgp-guide
email-clients
applying-patches
backporting
adding-syscalls
volatile-considered-harmful
botching-up-ioctls
Policy guides and developer statements
--------------------------------------
These are the rules that we try to live by in the kernel community (and
beyond).
.. toctree::
:maxdepth: 1
license-rules
code-of-conduct
code-of-conduct-interpretation
contribution-maturity-model
kernel-enforcement-statement
kernel-driver-statement
stable-api-nonsense
stable-kernel-rules
management-style
researcher-guidelines
For security issues, see:
Dealing with bugs
-----------------
Bugs are a fact of life; it is important that we handle them properly.
The documents below describe our policies around the handling of a couple
of special classes of bugs: regressions and security problems.
.. toctree::
:maxdepth: 1
handling-regressions
security-bugs
embargoed-hardware-issues
Other guides to the community that are of interest to most developers are:
Maintainer information
----------------------
How to find the people who will accept your patches.
.. toctree::
:maxdepth: 1
maintainer-handbooks
maintainers
Other material
--------------
Here are some other guides to the community that are of interest to most
developers:
.. toctree::
:maxdepth: 1
changes
stable-api-nonsense
management-style
stable-kernel-rules
submit-checklist
kernel-docs
deprecated
maintainers
researcher-guidelines
contribution-maturity-model
These are some overall technical guides that have been put here for now for
lack of a better place.
......@@ -65,12 +112,7 @@ lack of a better place.
.. toctree::
:maxdepth: 1
applying-patches
backporting
adding-syscalls
magic-number
volatile-considered-harmful
botching-up-ioctls
clang-format
../arch/riscv/patch-acceptance
../core-api/unaligned-memory-access
......
......@@ -790,10 +790,14 @@ Providing base tree information
-------------------------------
When other developers receive your patches and start the review process,
it is often useful for them to know where in the tree history they
should place your work. This is particularly useful for automated CI
processes that attempt to run a series of tests in order to establish
the quality of your submission before the maintainer starts the review.
it is absolutely necessary for them to know what is the base
commit/branch your work applies on, considering the sheer amount of
maintainer trees present nowadays. Note again the **T:** entry in the
MAINTAINERS file explained above.
This is even more important for automated CI processes that attempt to
run a series of tests in order to establish the quality of your
submission before the maintainer starts the review.
If you are using ``git format-patch`` to generate your patches, you can
automatically include the base tree information in your submission by
......@@ -836,6 +840,9 @@ letter or in the first patch of the series and it should be placed
either below the ``---`` line or at the very bottom of all other
content, right before your email signature.
Make sure that base commit is in an official maintainer/mainline tree
and not in some internal, accessible only to you tree - otherwise it
would be worthless.
References
----------
......
......@@ -88,7 +88,7 @@ safe.
(2) TEE
TEEs have well-documented, standardized client interface and APIs. For
more details refer to ``Documentation/staging/tee.rst``.
more details refer to ``Documentation/driver-api/tee.rst``.
(3) CAAM
......
......@@ -7,6 +7,10 @@
div.body h1 { font-size: 180%; }
div.body h2 { font-size: 150%; }
div.body h3 { font-size: 130%; }
div.body h4 { font-size: 110%; }
/* toctree captions are styled like h2 */
div.toctree-wrapper p.caption[role=heading] { font-size: 150%; }
/* Tighten up the layout slightly */
div.body { padding: 0 15px 0 10px; }
......@@ -20,6 +24,12 @@ div.document {
width: auto;
}
/* Size the logo appropriately */
img.logo {
width: 104px;
margin-bottom: 20px;
}
/*
* Parameters for the display of function prototypes and such included
* from C source files.
......@@ -73,3 +83,56 @@ input.kernel-toc-toggle { display: none; }
h3.kernel-toc-contents { display: inline; }
div.kerneltoc a { color: black; }
}
/* Language selection menu */
div.admonition {
/*
* Make sure we don't overlap notes and warnings at the top of the
* document.
*/
clear: both;
}
div.language-selection {
background: #eeeeee;
border: 1px solid #cccccc;
margin-bottom: 1em;
padding: .5em;
position: relative;
float: right;
}
div.language-selection a {
display: block;
padding: 0.5em;
color: #333333;
text-decoration: none;
}
div.language-selection ul {
display: none;
position: absolute;
/* Align with the parent div */
top: 100%;
right: 0;
margin: 0;
list-style: none;
background: #fafafa;
border: 1px solid #cccccc;
/* Never break menu item lines */
white-space: nowrap;
}
div.language-selection:hover ul {
display: block;
}
div.language-selection ul li:hover {
background: #dddddd;
}
......@@ -81,11 +81,6 @@ div[class^="highlight"] pre {
* - hide the permalink symbol as long as link is not hovered
*/
.toc-title {
font-size: 150%;
font-weight: bold;
}
caption, .wy-table caption, .rst-content table.field-list caption {
font-size: 100%;
}
......
......@@ -7,11 +7,7 @@
from docutils import nodes
import sphinx
from sphinx import addnodes
if sphinx.version_info[0] < 2 or \
sphinx.version_info[0] == 2 and sphinx.version_info[1] < 1:
from sphinx.environment import NoUri
else:
from sphinx.errors import NoUri
from sphinx.errors import NoUri
import re
from itertools import chain
......@@ -74,6 +70,12 @@ Skipfuncs = [ 'open', 'close', 'read', 'write', 'fcntl', 'mmap',
c_namespace = ''
#
# Detect references to commits.
#
RE_git = re.compile(r'commit\s+(?P<rev>[0-9a-f]{12,40})(?:\s+\(".*?"\))?',
flags=re.IGNORECASE | re.DOTALL)
def markup_refs(docname, app, node):
t = node.astext()
done = 0
......@@ -90,7 +92,8 @@ def markup_refs(docname, app, node):
RE_struct: markup_c_ref,
RE_union: markup_c_ref,
RE_enum: markup_c_ref,
RE_typedef: markup_c_ref}
RE_typedef: markup_c_ref,
RE_git: markup_git}
if sphinx.version_info[0] >= 3:
markup_func = markup_func_sphinx3
......@@ -276,6 +279,17 @@ def get_c_namespace(app, docname):
return match.group(1)
return ''
def markup_git(docname, app, match):
# While we could probably assume that we are running in a git
# repository, we can't know for sure, so let's just mechanically
# turn them into git.kernel.org links without checking their
# validity. (Maybe we can do something in the future to warn about
# these references if this is explicitly requested.)
text = match.group(0)
rev = match.group('rev')
return nodes.reference('', nodes.Text(text),
refuri=f'https://git.kernel.org/torvalds/c/{rev}')
def auto_markup(app, doctree, name):
global c_namespace
c_namespace = get_c_namespace(app, name)
......
......@@ -127,11 +127,7 @@ def setup(app):
# Handle easy Sphinx 3.1+ simple new tags: :c:expr and .. c:namespace::
app.connect('source-read', c_markups)
if (major == 1 and minor < 8):
app.override_domain(CDomain)
else:
app.add_domain(CDomain, override=True)
app.add_domain(CDomain, override=True)
return dict(
version = __version__,
......
......@@ -39,8 +39,6 @@ import sys
import re
import kernellog
from os import path
from docutils import nodes, statemachine
from docutils.statemachine import ViewList
from docutils.parsers.rst import directives, Directive
......@@ -73,60 +71,26 @@ class KernelCmd(Directive):
}
def run(self):
doc = self.state.document
if not doc.settings.file_insertion_enabled:
raise self.warning("docutils: file insertion disabled")
env = doc.settings.env
cwd = path.dirname(doc.current_source)
cmd = "get_abi.pl rest --enable-lineno --dir "
cmd += self.arguments[0]
if 'rst' in self.options:
cmd += " --rst-source"
srctree = os.path.abspath(os.environ["srctree"])
srctree = path.abspath(os.environ["srctree"])
args = [
os.path.join(srctree, 'scripts/get_abi.pl'),
'rest',
'--enable-lineno',
'--dir', os.path.join(srctree, 'Documentation', self.arguments[0]),
]
fname = cmd
# extend PATH with $(srctree)/scripts
path_env = os.pathsep.join([
srctree + os.sep + "scripts",
os.environ["PATH"]
])
shell_env = os.environ.copy()
shell_env["PATH"] = path_env
shell_env["srctree"] = srctree
if 'rst' in self.options:
args.append('--rst-source')
lines = self.runCmd(cmd, shell=True, cwd=cwd, env=shell_env)
lines = subprocess.check_output(args, cwd=os.path.dirname(doc.current_source)).decode('utf-8')
nodeList = self.nestedParse(lines, self.arguments[0])
return nodeList
def runCmd(self, cmd, **kwargs):
u"""Run command ``cmd`` and return its stdout as unicode."""
try:
proc = subprocess.Popen(
cmd
, stdout = subprocess.PIPE
, stderr = subprocess.PIPE
, **kwargs
)
out, err = proc.communicate()
out, err = codecs.decode(out, 'utf-8'), codecs.decode(err, 'utf-8')
if proc.returncode != 0:
raise self.severe(
u"command '%s' failed with return code %d"
% (cmd, proc.returncode)
)
except OSError as exc:
raise self.severe(u"problems with '%s' directive: %s."
% (self.name, ErrorString(exc)))
return out
def nestedParse(self, lines, fname):
env = self.state.document.settings.env
content = ViewList()
......
......@@ -61,13 +61,7 @@ import sphinx
from sphinx.util.nodes import clean_astext
import kernellog
# Get Sphinx version
major, minor, patch = sphinx.version_info[:3]
if major == 1 and minor > 3:
# patches.Figure only landed in Sphinx 1.4
from sphinx.directives.patches import Figure # pylint: disable=C0413
else:
Figure = images.Figure
Figure = images.Figure
__version__ = '1.0.0'
......
<!-- SPDX-License-Identifier: GPL-2.0 -->
<!-- Copyright © 2023, Oracle and/or its affiliates. -->
{# Create a language menu for translations #}
{% if languages|length > 0: %}
<div class="language-selection">
{{ current_language }}
<ul>
{% for ref in languages: %}
<li><a href="{{ ref.refuri }}">{{ ref.astext() }}</a></li>
{% endfor %}
</ul>
</div>
{% endif %}
# SPDX-License-Identifier: GPL-2.0
#
# Copyright © 2023, Oracle and/or its affiliates.
# Author: Vegard Nossum <vegard.nossum@oracle.com>
#
# Add translation links to the top of the document.
#
import os
from docutils import nodes
from docutils.transforms import Transform
import sphinx
from sphinx import addnodes
from sphinx.errors import NoUri
all_languages = {
# English is always first
None: 'English',
# Keep the rest sorted alphabetically
'zh_CN': 'Chinese (Simplified)',
'zh_TW': 'Chinese (Traditional)',
'it_IT': 'Italian',
'ja_JP': 'Japanese',
'ko_KR': 'Korean',
'sp_SP': 'Spanish',
}
class LanguagesNode(nodes.Element):
def __init__(self, current_language, *args, **kwargs):
super().__init__(*args, **kwargs)
self.current_language = current_language
class TranslationsTransform(Transform):
default_priority = 900
def apply(self):
app = self.document.settings.env.app
docname = self.document.settings.env.docname
this_lang_code = None
components = docname.split(os.sep)
if components[0] == 'translations' and len(components) > 2:
this_lang_code = components[1]
# normalize docname to be the untranslated one
docname = os.path.join(*components[2:])
new_nodes = LanguagesNode(all_languages[this_lang_code])
for lang_code, lang_name in all_languages.items():
if lang_code == this_lang_code:
continue
if lang_code is None:
target_name = docname
else:
target_name = os.path.join('translations', lang_code, docname)
pxref = addnodes.pending_xref('', refdomain='std',
reftype='doc', reftarget='/' + target_name, modname=None,
classname=None, refexplicit=True)
pxref += nodes.Text(lang_name)
new_nodes += pxref
self.document.insert(0, new_nodes)
def process_languages(app, doctree, docname):
for node in doctree.traverse(LanguagesNode):
if app.builder.format not in ['html']:
node.parent.remove(node)
continue
languages = []
# Iterate over the child nodes; any resolved links will have
# the type 'nodes.reference', while unresolved links will be
# type 'nodes.Text'.
languages = list(filter(lambda xref:
isinstance(xref, nodes.reference), node.children))
html_content = app.builder.templates.render('translations.html',
context={
'current_language': node.current_language,
'languages': languages,
})
node.replace_self(nodes.raw('', html_content, format='html'))
def setup(app):
app.add_node(LanguagesNode)
app.add_transform(TranslationsTransform)
app.connect('doctree-resolved', process_languages)
return {
'parallel_read_safe': True,
'parallel_write_safe': True,
}
......@@ -12,5 +12,4 @@ Unsorted Documentation
rpmsg
speculation
static-keys
tee
xz
......@@ -86,3 +86,4 @@ Storage interfaces
misc-devices/index
peci/index
wmi/index
tee/index
.. SPDX-License-Identifier: GPL-2.0
=============================================
AMD-TEE (AMD's Trusted Execution Environment)
=============================================
The AMD-TEE driver handles the communication with AMD's TEE environment. The
TEE environment is provided by AMD Secure Processor.
The AMD Secure Processor (formerly called Platform Security Processor or PSP)
is a dedicated processor that features ARM TrustZone technology, along with a
software-based Trusted Execution Environment (TEE) designed to enable
third-party Trusted Applications. This feature is currently enabled only for
APUs.
The following picture shows a high level overview of AMD-TEE::
|
x86 |
|
User space (Kernel space) | AMD Secure Processor (PSP)
~~~~~~~~~~ ~~~~~~~~~~~~~~ | ~~~~~~~~~~~~~~~~~~~~~~~~~~
|
+--------+ | +-------------+
| Client | | | Trusted |
+--------+ | | Application |
/\ | +-------------+
|| | /\
|| | ||
|| | \/
|| | +----------+
|| | | TEE |
|| | | Internal |
\/ | | API |
+---------+ +-----------+---------+ +----------+
| TEE | | TEE | AMD-TEE | | AMD-TEE |
| Client | | subsystem | driver | | Trusted |
| API | | | | | OS |
+---------+-----------+----+------+---------+---------+----------+
| Generic TEE API | | ASP | Mailbox |
| IOCTL (TEE_IOC_*) | | driver | Register Protocol |
+--------------------------+ +---------+--------------------+
At the lowest level (in x86), the AMD Secure Processor (ASP) driver uses the
CPU to PSP mailbox register to submit commands to the PSP. The format of the
command buffer is opaque to the ASP driver. It's role is to submit commands to
the secure processor and return results to AMD-TEE driver. The interface
between AMD-TEE driver and AMD Secure Processor driver can be found in [1].
The AMD-TEE driver packages the command buffer payload for processing in TEE.
The command buffer format for the different TEE commands can be found in [2].
The TEE commands supported by AMD-TEE Trusted OS are:
* TEE_CMD_ID_LOAD_TA - loads a Trusted Application (TA) binary into
TEE environment.
* TEE_CMD_ID_UNLOAD_TA - unloads TA binary from TEE environment.
* TEE_CMD_ID_OPEN_SESSION - opens a session with a loaded TA.
* TEE_CMD_ID_CLOSE_SESSION - closes session with loaded TA
* TEE_CMD_ID_INVOKE_CMD - invokes a command with loaded TA
* TEE_CMD_ID_MAP_SHARED_MEM - maps shared memory
* TEE_CMD_ID_UNMAP_SHARED_MEM - unmaps shared memory
AMD-TEE Trusted OS is the firmware running on AMD Secure Processor.
The AMD-TEE driver registers itself with TEE subsystem and implements the
following driver function callbacks:
* get_version - returns the driver implementation id and capability.
* open - sets up the driver context data structure.
* release - frees up driver resources.
* open_session - loads the TA binary and opens session with loaded TA.
* close_session - closes session with loaded TA and unloads it.
* invoke_func - invokes a command with loaded TA.
cancel_req driver callback is not supported by AMD-TEE.
The GlobalPlatform TEE Client API [3] can be used by the user space (client) to
talk to AMD's TEE. AMD's TEE provides a secure environment for loading, opening
a session, invoking commands and closing session with TA.
References
==========
[1] include/linux/psp-tee.h
[2] drivers/tee/amdtee/amdtee_if.h
[3] http://www.globalplatform.org/specificationsdevice.asp look for
"TEE Client API Specification v1.0" and click download.
.. SPDX-License-Identifier: GPL-2.0
=============
TEE Subsystem
=============
.. toctree::
:maxdepth: 1
tee
op-tee
amd-tee
.. only:: subproject and html
Indices
=======
* :ref:`genindex`
=============
TEE subsystem
=============
.. SPDX-License-Identifier: GPL-2.0
This document describes the TEE subsystem in Linux.
A TEE (Trusted Execution Environment) is a trusted OS running in some
secure environment, for example, TrustZone on ARM CPUs, or a separate
secure co-processor etc. A TEE driver handles the details needed to
communicate with the TEE.
This subsystem deals with:
- Registration of TEE drivers
- Managing shared memory between Linux and the TEE
- Providing a generic API to the TEE
The TEE interface
=================
include/uapi/linux/tee.h defines the generic interface to a TEE.
User space (the client) connects to the driver by opening /dev/tee[0-9]* or
/dev/teepriv[0-9]*.
- TEE_IOC_SHM_ALLOC allocates shared memory and returns a file descriptor
which user space can mmap. When user space doesn't need the file
descriptor any more, it should be closed. When shared memory isn't needed
any longer it should be unmapped with munmap() to allow the reuse of
memory.
- TEE_IOC_VERSION lets user space know which TEE this driver handles and
its capabilities.
- TEE_IOC_OPEN_SESSION opens a new session to a Trusted Application.
- TEE_IOC_INVOKE invokes a function in a Trusted Application.
- TEE_IOC_CANCEL may cancel an ongoing TEE_IOC_OPEN_SESSION or TEE_IOC_INVOKE.
- TEE_IOC_CLOSE_SESSION closes a session to a Trusted Application.
There are two classes of clients, normal clients and supplicants. The latter is
a helper process for the TEE to access resources in Linux, for example file
system access. A normal client opens /dev/tee[0-9]* and a supplicant opens
/dev/teepriv[0-9].
Much of the communication between clients and the TEE is opaque to the
driver. The main job for the driver is to receive requests from the
clients, forward them to the TEE and send back the results. In the case of
supplicants the communication goes in the other direction, the TEE sends
requests to the supplicant which then sends back the result.
The TEE kernel interface
========================
Kernel provides a TEE bus infrastructure where a Trusted Application is
represented as a device identified via Universally Unique Identifier (UUID) and
client drivers register a table of supported device UUIDs.
TEE bus infrastructure registers following APIs:
match():
iterates over the client driver UUID table to find a corresponding
match for device UUID. If a match is found, then this particular device is
probed via corresponding probe API registered by the client driver. This
process happens whenever a device or a client driver is registered with TEE
bus.
uevent():
notifies user-space (udev) whenever a new device is registered on
TEE bus for auto-loading of modularized client drivers.
TEE bus device enumeration is specific to underlying TEE implementation, so it
is left open for TEE drivers to provide corresponding implementation.
Then TEE client driver can talk to a matched Trusted Application using APIs
listed in include/linux/tee_drv.h.
TEE client driver example
-------------------------
Suppose a TEE client driver needs to communicate with a Trusted Application
having UUID: ``ac6a4085-0e82-4c33-bf98-8eb8e118b6c2``, so driver registration
snippet would look like::
static const struct tee_client_device_id client_id_table[] = {
{UUID_INIT(0xac6a4085, 0x0e82, 0x4c33,
0xbf, 0x98, 0x8e, 0xb8, 0xe1, 0x18, 0xb6, 0xc2)},
{}
};
MODULE_DEVICE_TABLE(tee, client_id_table);
static struct tee_client_driver client_driver = {
.id_table = client_id_table,
.driver = {
.name = DRIVER_NAME,
.bus = &tee_bus_type,
.probe = client_probe,
.remove = client_remove,
},
};
static int __init client_init(void)
{
return driver_register(&client_driver.driver);
}
static void __exit client_exit(void)
{
driver_unregister(&client_driver.driver);
}
module_init(client_init);
module_exit(client_exit);
OP-TEE driver
=============
====================================================
OP-TEE (Open Portable Trusted Execution Environment)
====================================================
The OP-TEE driver handles OP-TEE [1] based TEEs. Currently it is only the ARM
TrustZone based OP-TEE solution that is supported.
......@@ -221,7 +105,7 @@ The OPTEE_INSECURE_LOAD_IMAGE Kconfig option enables the ability to load the
BL32 OP-TEE image from the kernel after the kernel boots, rather than loading
it from the firmware before the kernel boots. This also requires enabling the
corresponding option in Trusted Firmware for Arm. The Trusted Firmware for Arm
documentation [8] explains the security threat associated with enabling this as
documentation [6] explains the security threat associated with enabling this as
well as mitigations at the firmware and platform level.
There are additional attack vectors/mitigations for the kernel that should be
......@@ -265,84 +149,6 @@ addressed when using this option.
rather than as a module to prevent exploits that may cause the module to
not be loaded.
AMD-TEE driver
==============
The AMD-TEE driver handles the communication with AMD's TEE environment. The
TEE environment is provided by AMD Secure Processor.
The AMD Secure Processor (formerly called Platform Security Processor or PSP)
is a dedicated processor that features ARM TrustZone technology, along with a
software-based Trusted Execution Environment (TEE) designed to enable
third-party Trusted Applications. This feature is currently enabled only for
APUs.
The following picture shows a high level overview of AMD-TEE::
|
x86 |
|
User space (Kernel space) | AMD Secure Processor (PSP)
~~~~~~~~~~ ~~~~~~~~~~~~~~ | ~~~~~~~~~~~~~~~~~~~~~~~~~~
|
+--------+ | +-------------+
| Client | | | Trusted |
+--------+ | | Application |
/\ | +-------------+
|| | /\
|| | ||
|| | \/
|| | +----------+
|| | | TEE |
|| | | Internal |
\/ | | API |
+---------+ +-----------+---------+ +----------+
| TEE | | TEE | AMD-TEE | | AMD-TEE |
| Client | | subsystem | driver | | Trusted |
| API | | | | | OS |
+---------+-----------+----+------+---------+---------+----------+
| Generic TEE API | | ASP | Mailbox |
| IOCTL (TEE_IOC_*) | | driver | Register Protocol |
+--------------------------+ +---------+--------------------+
At the lowest level (in x86), the AMD Secure Processor (ASP) driver uses the
CPU to PSP mailbox register to submit commands to the PSP. The format of the
command buffer is opaque to the ASP driver. It's role is to submit commands to
the secure processor and return results to AMD-TEE driver. The interface
between AMD-TEE driver and AMD Secure Processor driver can be found in [6].
The AMD-TEE driver packages the command buffer payload for processing in TEE.
The command buffer format for the different TEE commands can be found in [7].
The TEE commands supported by AMD-TEE Trusted OS are:
* TEE_CMD_ID_LOAD_TA - loads a Trusted Application (TA) binary into
TEE environment.
* TEE_CMD_ID_UNLOAD_TA - unloads TA binary from TEE environment.
* TEE_CMD_ID_OPEN_SESSION - opens a session with a loaded TA.
* TEE_CMD_ID_CLOSE_SESSION - closes session with loaded TA
* TEE_CMD_ID_INVOKE_CMD - invokes a command with loaded TA
* TEE_CMD_ID_MAP_SHARED_MEM - maps shared memory
* TEE_CMD_ID_UNMAP_SHARED_MEM - unmaps shared memory
AMD-TEE Trusted OS is the firmware running on AMD Secure Processor.
The AMD-TEE driver registers itself with TEE subsystem and implements the
following driver function callbacks:
* get_version - returns the driver implementation id and capability.
* open - sets up the driver context data structure.
* release - frees up driver resources.
* open_session - loads the TA binary and opens session with loaded TA.
* close_session - closes session with loaded TA and unloads it.
* invoke_func - invokes a command with loaded TA.
cancel_req driver callback is not supported by AMD-TEE.
The GlobalPlatform TEE Client API [5] can be used by the user space (client) to
talk to AMD's TEE. AMD's TEE provides a secure environment for loading, opening
a session, invoking commands and closing session with TA.
References
==========
......@@ -357,8 +163,4 @@ References
[5] http://www.globalplatform.org/specificationsdevice.asp look for
"TEE Client API Specification v1.0" and click download.
[6] include/linux/psp-tee.h
[7] drivers/tee/amdtee/amdtee_if.h
[8] https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_model.html
[6] https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_model.html
.. SPDX-License-Identifier: GPL-2.0
===================================
TEE (Trusted Execution Environment)
===================================
This document describes the TEE subsystem in Linux.
Overview
========
A TEE is a trusted OS running in some secure environment, for example,
TrustZone on ARM CPUs, or a separate secure co-processor etc. A TEE driver
handles the details needed to communicate with the TEE.
This subsystem deals with:
- Registration of TEE drivers
- Managing shared memory between Linux and the TEE
- Providing a generic API to the TEE
......@@ -182,7 +182,7 @@ FTRACE_OPS_FL_SAVE_REGS_IF_SUPPORTED
FTRACE_OPS_FL_RECURSION
By default, it is expected that the callback can handle recursion.
But if the callback is not that worried about overehead, then
But if the callback is not that worried about overhead, then
setting this bit will add the recursion protection around the
callback by calling a helper function that will do the recursion
protection and only call the callback if it did not recurse.
......@@ -190,7 +190,7 @@ FTRACE_OPS_FL_RECURSION
Note, if this flag is not set, and recursion does occur, it could
cause the system to crash, and possibly reboot via a triple fault.
Not, if this flag is set, then the callback will always be called
Note, if this flag is set, then the callback will always be called
with preemption disabled. If it is not set, then it is possible
(but not guaranteed) that the callback will be called in
preemptable context.
......
......@@ -180,6 +180,21 @@ of ftrace. Here is a list of some of the key files:
Only active when the file contains a number greater than 0.
(in microseconds)
buffer_percent:
This is the watermark for how much the ring buffer needs to be filled
before a waiter is woken up. That is, if an application calls a
blocking read syscall on one of the per_cpu trace_pipe_raw files, it
will block until the given amount of data specified by buffer_percent
is in the ring buffer before it wakes the reader up. This also
controls how the splice system calls are blocked on this file::
0 - means to wake up as soon as there is any data in the ring buffer.
50 - means to wake up when roughly half of the ring buffer sub-buffers
are full.
100 - means to block until the ring buffer is totally full and is
about to start overwriting the older data.
buffer_size_kb:
This sets or displays the number of kilobytes each CPU
......@@ -2574,7 +2589,7 @@ want, depending on your needs.
- The cpu number on which the function executed is default
enabled. It is sometimes better to only trace one cpu (see
tracing_cpu_mask file) or you might sometimes see unordered
tracing_cpumask file) or you might sometimes see unordered
function calls while cpu tracing switch.
- hide: echo nofuncgraph-cpu > trace_options
......
......@@ -8,9 +8,17 @@
Una guida al processo di sviluppo del Kernel
============================================
Contenuti:
Lo scopo di questo documento è quello di aiutare gli sviluppatori (ed i loro
supervisori) a lavorare con la communità di sviluppo con il minimo sforzo. È
un tentativo di documentare il funzionamento di questa communità in modo che
sia accessibile anche a coloro che non hanno famigliarità con lo sviluppo del
Kernel Linux (o, anzi, con lo sviluppo di software libero in generale). Benchè
qui sia presente del materiale tecnico, questa è una discussione rivolta in
particolare al procedimento, e quindi per essere compreso non richiede una
conoscenza approfondità sullo sviluppo del kernel.
.. toctree::
:caption: Contenuti
:numbered:
:maxdepth: 2
......@@ -22,12 +30,3 @@ Contenuti:
6.Followthrough
7.AdvancedTopics
8.Conclusion
Lo scopo di questo documento è quello di aiutare gli sviluppatori (ed i loro
supervisori) a lavorare con la communità di sviluppo con il minimo sforzo. È
un tentativo di documentare il funzionamento di questa communità in modo che
sia accessibile anche a coloro che non hanno famigliarità con lo sviluppo del
Kernel Linux (o, anzi, con lo sviluppo di software libero in generale). Benchè
qui sia presente del materiale tecnico, questa è una discussione rivolta in
particolare al procedimento, e quindi per essere compreso non richiede una
conoscenza approfondità sullo sviluppo del kernel.
......@@ -4,3 +4,6 @@
Si tiene alguna duda sobre la exactitud del contenido de esta
traducción, la única referencia válida es la documentación oficial en
inglés.
Además, por defecto, los enlaces a documentos redirigen a la
documentación en inglés, incluso si existe una versión traducida.
Consulte el índice para más información.
......@@ -76,6 +76,5 @@ Traducciones al español
.. toctree::
:maxdepth: 1
howto
process/index
wrappers/memory-barriers
.. include:: ./disclaimer-sp.rst
.. include:: ../disclaimer-sp.rst
:Original: :ref:`Documentation/process/howto.rst <process_howto>`
:Translator: Carlos Bilbao <carlos.bilbao@amd.com>
......
......@@ -24,3 +24,7 @@
contribution-maturity-model
security-bugs
embargoed-hardware-issues
handling-regressions
management-style
submit-checklist
howto
This diff is collapsed.
.. include:: ../disclaimer-sp.rst
:Original: Documentation/process/submit-checklist.rst
:Translator: Avadhut Naik <avadhut.naik@amd.com>
.. _sp_submitchecklist:
Lista de comprobación para enviar parches del kernel de Linux
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Aquí hay algunas cosas básicas que los desarrolladores deben hacer si
quieren que sus envíos de parches del kernel sean aceptados más
rápidamente.
Todo esto está más allá de la documentación que se proporciona en
:ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_submittingpatches>`
y en otros lugares con respecto al envío de parches del kernel de Linux.
1) Si utiliza una funcionalidad, #include el archivo que define/declara
esa funcionalidad. No dependa de otros archivos de encabezado que
extraigan los que utiliza.
2) Compile limpiamente:
a) Con las opciones ``CONFIG`` aplicables o modificadas ``=y``, ``=m``,
y ``=n``. Sin advertencias/errores del compilador ``gcc``, ni
advertencias/errores del linker.
b) Aprobar ``allnoconfig``, ``allmodconfig``
c) Compila correctamente cuando se usa ``O=builddir``
d) Cualquier documentación o cambios se compilan correctamente sin
nuevas advertencias/errores. Utilice ``make htmldocs`` o
``make pdfdocs`` para comprobar la compilación y corregir cualquier
problema.
3) Se compila en varias arquitecturas de CPU mediante herramientas de
compilación cruzada locales o alguna otra granja de compilación.
4) ppc64 es una buena arquitectura para verificar la compilación cruzada
por que tiende a usar ``unsigned long`` para cantidades de 64-bits.
5) Verifique su parche para el estilo general según se detalla en
:ref:`Documentation/translations/sp_SP/process/coding-style.rst <sp_codingstyle>`.
Verifique las infracciones triviales con el verificador de estilo de
parches antes de la entrega (``scripts/checkpatch.pl``).
Debería ser capaz de justificar todas las infracciones que permanezcan
en su parche.
6) Cualquier opción ``CONFIG`` nueva o modificada no altera el menú de
configuración y se desactiva por defecto, a menos que cumpla con los
criterios de excepción documentados en
``Documentation/kbuild/kconfig-language.rst`` Atributos del menú: valor por defecto.
7) Todas las nuevas opciones de ``Kconfig`` tienen texto de ayuda.
8) Ha sido revisado cuidadosamente con respecto a las combinaciones
relevantes de ``Kconfig``. Esto es muy difícil de hacer correctamente
con las pruebas -- la concentración mental da resultados aquí.
9) Verifique limpiamente con sparse.
10) Use ``make checkstack`` y solucione cualquier problema que encuentre.
.. note::
``checkstack`` no señala los problemas explícitamente, pero
cualquier función que use más de 512 bytes en la pila es
candidata para el cambio.
11) Incluya :ref:`kernel-doc <kernel_doc>` para documentar las API
globales del kernel. (No es necesario para funciones estáticas, pero
también está bien.) Utilice ``make htmldocs`` o ``make pdfdocs``
para comprobar el :ref:`kernel-doc <kernel_doc>` y solucionar
cualquier problema.
12) Ha sido probado con ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``,
``CONFIG_DEBUG_SLAB``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``,
``CONFIG_DEBUG_SPINLOCK``, ``CONFIG_DEBUG_ATOMIC_SLEEP``
``CONFIG_PROVE_RCU`` y ``CONFIG_DEBUG_OBJECTS_RCU_HEAD`` todos
habilitados simultáneamente.
13) Ha sido probado en tiempo de compilación y ejecución con y sin
``CONFIG_SMP`` y ``CONFIG_PREEMPT``.
14) Todas las rutas de código se han ejercido con todas las
características de lockdep habilitadas.
15) Todas las nuevas entradas de ``/proc`` están documentadas en
``Documentation/``.
16) Todos los nuevos parámetros de arranque del kernel están documentados
en ``Documentation/admin-guide/kernel-parameters.rst``.
17) Todos los nuevos parámetros del módulo están documentados con
``MODULE_PARM_DESC()``.
18) Todas las nuevas interfaces de espacio de usuario están documentadas
en ``Documentation/ABI/``. Consulte ``Documentation/ABI/README`` para
obtener más información. Los parches que cambian las interfaces del
espacio de usuario deben ser CCed a linux-api@vger.kernel.org.
19) Se ha comprobado con la inyección de al menos errores de asignación
de slab y página. Consulte ``Documentation/fault-injection/``.
Si el nuevo código es sustancial, la adición de la inyección de
errores específica del subsistema podría ser apropiada.
20) El nuevo código añadido ha sido compilado con ``gcc -W`` (use
``make KCFLAGS=-W``). Esto generara mucho ruido per es buena para
encontrar errores como "warning: comparison between signed and unsigned".
21) Se prueba después de que se haya fusionado en el conjunto de
parches -mm para asegurarse de que siga funcionando con todos los
demás parches en cola y varios cambios en VM, VFS y otros subsistemas.
22) Todas las barreras de memoria {p.ej., ``barrier()``, ``rmb()``,
``wmb()``} necesitan un comentario en el código fuente que explique
la lógica de lo que están haciendo y por qué.
23) Si se añaden algún ioctl en el parche, actualice también
``Documentation/userspace-api/ioctl/ioctl-number.rst``.
24) Si su código fuente modificado depende o utiliza cualquiera de las
API o características del kernel que están relacionadas con los
siguientes símbolos ``Kconfig`` entonces pruebe varias compilaciones
con los símbolos ``Kconfig`` relacionados deshabilitados y/o ``=m``
(si esa opción esta disponible) [no todos estos al mismo tiempo, solo
varias/aleatorias combinaciones de ellos]:
``CONFIG_SMP``, ``CONFIG_SYSFS``, ``CONFIG_PROC_FS``, ``CONFIG_INPUT``, ``CONFIG_PCI``, ``CONFIG_BLOCK``, ``CONFIG_PM``, ``CONFIG_MAGIC_SYSRQ``
``CONFIG_NET``, ``CONFIG_INET=n`` (pero luego con ``CONFIG_NET=y``).
.. SPDX-License-Identifier: GPL-2.0
.. include:: ../../disclaimer-zh_CN.rst
:Original: Documentation/arch/riscv/boot.rst
:翻译:
龙进 Jin Long <longjin@dragonos.org>
========================
RISC-V内核启动要求和限制
========================
:Author: Alexandre Ghiti <alexghiti@rivosinc.com>
:Date: 23 May 2023
这份文档描述了RISC-V内核对引导加载程序和固件的期望,以及任何开发者在接触
早期启动过程时必须牢记的约束。在这份文档中, ``早期启动过程`` 指的是在最
终虚拟映射设置之前运行的任何代码。
内核预加载的要求和限制
======================
RISC-V内核对引导加载程序和平台固件有以下要求:
寄存器状态
----------
RISC-V内核期望:
* ``$a0`` 应包含当前核心的hartid。
* ``$a1`` 应包含内存中设备树的地址。
CSR 寄存器状态
--------------
RISC-V内核期望:
* ``$satp = 0``: 如果存在MMU,必须将其禁用。
为常驻固件保留的内存
--------------------
RISC-V内核在直接映射中不能映射任何常驻内存或用PMPs保护的内存,
因此固件必须根据设备树规范 和/或 UEFI规范正确标记这些区域。
内核的位置
----------
RISC-V内核期望被放置在PMD边界(对于rv64为2MB对齐,对于rv32为4MB对齐)。
请注意,如果不是这样,EFI stub 将重定位内核。
硬件描述
--------
固件可以将设备树或ACPI表传递给RISC-V内核。
设备树可以直接从前一阶段通过$a1寄存器传递给内核,或者在使用UEFI启动时,
可以通过EFI配置表传递。
ACPI表通过EFI配置表传递给内核。在这种情况下,EFI stub 仍然会创建一个
小的设备树。请参阅下面的"EFI stub 和设备树"部分,了解这个设备树的详细
信息。
内核入口
--------
在SMP系统中,有两种方法可以进入内核:
- ``RISCV_BOOT_SPINWAIT``:固件在内核中释放所有的hart,一个hart赢
得抽奖并执行早期启动代码,而其他的hart则停在那里等待初始化完成。这种
方法主要用于支持没有SBI HSM扩展和M模式RISC-V内核的旧固件。
- ``有序启动``:固件只释放一个将执行初始化阶段的hart,然后使用SBI HSM
扩展启动所有其他的hart。有序启动方法是启动RISC-V内核的首选启动方法,
因为它可以支持CPU热插拔和kexec。
UEFI
----
UEFI 内存映射
~~~~~~~~~~~~~
使用UEFI启动时,RISC-V内核将只使用EFI内存映射来填充系统内存。
UEFI固件必须解析 ``/reserved-memory`` 设备树节点的子节点,并遵守设备
树规范,将这些子节点的属性( ``no-map`` 和 ``reusable`` )转换为其正
确的EFI等价物(参见设备树规范v0.4-rc1的"3.5.4/reserved-memory和
UEFI"部分)。
RISCV_EFI_BOOT_PROTOCOL
~~~~~~~~~~~~~~~~~~~~~~~
使用UEFI启动时,EFI stub 需要引导hartid以便将其传递给 ``$a1`` 中的
RISC-V内核。EFI stub使用以下方法之一获取引导hartid:
- ``RISCV_EFI_BOOT_PROTOCOL`` (**首选**)。
- ``boot-hartid`` 设备树子节点(**已弃用**)。
任何新的固件都必须实现 ``RISCV_EFI_BOOT_PROTOCOL``,因为基于设备树
的方法现已被弃用。
早期启动的要求和约束
====================
RISC-V内核的早期启动过程遵循以下约束:
EFI stub 和设备树
-----------------
使用UEFI启动时,EFI stub 会用与arm64相同的参数补充(或创建)设备树,
这些参数在Documentation/arch/arm/uefi.rst中的
"UEFI kernel supporton ARM"段落中有描述。
虚拟映射安装
------------
在RISC-V内核中,虚拟映射的安装分为两步进行:
1. ``setup_vm()`` 在 ``early_pg_dir`` 中安装一个临时的内核映射,这
允许发现系统内存。 此时只有内核文本/数据被映射。在建立这个映射时,
不能进行分配(因为系统内存还未知),所以``early_pg_dir``页表是静
态分配的(每个级别只使用一个表)。
2. ``setup_vm_final()`` 在 ``swapper_pg_dir`` 中创建最终的内核映
射,并利用发现的系统内存 创建线性映射。在建立这个映射时,内核可以
分配内存,但不能直接访问它(因为直接映射还不存在),所以它使用fixmap
区域的临时映射来访问新分配的页表级别。
为了让 ``virt_to_phys()`` 和 ``phys_to_virt()`` 能够正确地将直接
映射地址转换为物理地址,它们需要知道DRAM的起始位置。这发生在步骤1之后,
就在步骤2安装直接映射之前(参见arch/riscv/mm/init.c中的
``setup_bootmem()`` 函数)。在安装最终虚拟映射之前使用这些宏时必须
仔细检查。
通过fixmap进行设备树映射
------------------------
由于 ``reserved_mem`` 数组是用 ``setup_vm()`` 建立的虚拟地址初始化
的,并且与``setup_vm_final()``建立的映射一起使用,RISC-V内核使用
fixmap区域来映射设备树。这确保设备树可以通过两种虚拟映射访问。
Pre-MMU执行
-----------
在建立第一个虚拟映射之前,需要运行一些代码。这些包括第一个虚拟映射的安装本身,
早期替代方案的修补,以及内核命令行的早期解析。这些代码必须非常小心地编译,因为:
- ``-fno-pie``:这对于使用``-fPIE``的可重定位内核是必需的,否则,任何对
全局符号的访问都将通过 GOT进行,而GOT只是虚拟地重新定位。
- ``-mcmodel=medany``:任何对全局符号的访问都必须是PC相对的,以避免在设
置MMU之前发生任何重定位。
- *所有* 的仪表化功能也必须被禁用(包括KASAN,ftrace和其他)。
由于使用来自不同编译单元的符号需要用这些标志编译该单元,我们建议尽可能不要使用
外部符号。
......@@ -17,6 +17,7 @@ RISC-V 体系结构
.. toctree::
:maxdepth: 1
boot
boot-image-header
vm-layout
patch-acceptance
......
......@@ -100,7 +100,7 @@ printk()的用法通常是这样的::
为了调试,还有两个有条件编译的宏:
pr_debug()和pr_devel(),除非定义了 ``DEBUG`` (或者在pr_debug()的情况下定义了
``CONFIG_DYNAMIC_DEBUG`` ),否则它们会被编译。
``CONFIG_DYNAMIC_DEBUG`` ),否则它们会被编译。
函数接口
......
......@@ -14,11 +14,8 @@
有关测试专用工具的简要概述,参见
Documentation/translations/zh_CN/dev-tools/testing-overview.rst
.. class:: toc-title
目录
.. toctree::
:caption: 目录
:maxdepth: 2
testing-overview
......
......@@ -3,7 +3,7 @@
.. include:: ../disclaimer-zh_CN.rst
:Original: Documentation/dev-tools/testing-overview.rst
:Translator: 胡皓文 Hu Haowen <src.res.211@gmail.com>
:Translator: 胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
============
内核测试指南
......
......@@ -14,9 +14,8 @@
通用型输入/输出(GPIO)
=======================
目录:
.. toctree::
:caption: 目录
:maxdepth: 2
legacy
......
......@@ -17,11 +17,8 @@ Linux驱动实现者的API指南
内核提供了各种各样的接口来支持设备驱动的开发。这份文档只是对其中一些接口进行了
一定程度的整理——希望随着时间的推移,它能变得更好!可用的小节可以在下面看到。
.. class:: toc-title
目录列表:
.. toctree::
:caption: 目录列表
:maxdepth: 2
gpio/index
......
......@@ -8,9 +8,10 @@
内核开发过程指南
================
内容:
本文档的目的是帮助开发人员(及其经理)以最小的挫折感与开发社区合作。它试图记录这个社区如何以一种不熟悉Linux内核开发(或者实际上是自由软件开发)的人可以访问的方式工作。虽然这里有一些技术资料,但这是一个面向过程的讨论,不需要深入了解内核编程就可以理解。
.. toctree::
:caption: 内容
:numbered:
:maxdepth: 2
......@@ -22,5 +23,3 @@
6.Followthrough
7.AdvancedTopics
8.Conclusion
本文档的目的是帮助开发人员(及其经理)以最小的挫折感与开发社区合作。它试图记录这个社区如何以一种不熟悉Linux内核开发(或者实际上是自由软件开发)的人可以访问的方式工作。虽然这里有一些技术资料,但这是一个面向过程的讨论,不需要深入了解内核编程就可以理解。
......@@ -5,10 +5,11 @@
.. include:: ../disclaimer-zh_CN.rst
:Original: :ref:`Documentation/process/index.rst <process_index>`
:Translator: Alex Shi <alex.shi@linux.alibaba.com>
:Original: Documentation/process/index.rst
.. _cn_process_index:
:翻译:
Alex Shi <alex.shi@linux.alibaba.com>
========================
与Linux 内核社区一起工作
......@@ -23,29 +24,55 @@
.. toctree::
:maxdepth: 1
license-rules
howto
code-of-conduct
code-of-conduct-interpretation
development-process
submitting-patches
programming-language
coding-style
development-process
maintainer-pgp-guide
email-clients
license-rules
kernel-enforcement-statement
kernel-driver-statement
TODOLIST:
* handling-regressions
* maintainer-handbooks
安全方面, 请阅读:
.. toctree::
:maxdepth: 1
embargoed-hardware-issues
TODOLIST:
* security-bugs
其它大多数开发人员感兴趣的社区指南:
.. toctree::
:maxdepth: 1
submit-checklist
stable-api-nonsense
stable-kernel-rules
management-style
embargoed-hardware-issues
stable-kernel-rules
submit-checklist
TODOLIST:
* changes
* kernel-docs
* deprecated
* maintainers
* researcher-guidelines
* contribution-maturity-model
这些是一些总体性技术指南,由于不大好分类而放在这里:
......@@ -54,6 +81,16 @@
magic-number
volatile-considered-harmful
../arch/riscv/patch-acceptance
../core-api/unaligned-memory-access
TODOLIST:
* applying-patches
* backporting
* adding-syscalls
* botching-up-ioctls
* clang-format
.. only:: subproject and html
......
.. _cn_magicnumbers:
.. include:: ../disclaimer-zh_CN.rst
:Original: :ref:`Documentation/process/magic-number.rst <magicnumbers>`
:Original: Documentation/process/magic-number.rst
:翻译:
如果想评论或更新本文的内容,请直接发信到LKML。如果你使用英文交流有困难的话,也可
以向中文版维护者求助。如果本翻译更新不及时或者翻译存在问题,请联系中文版维护者::
贾威威 Jia Wei Wei <harryxiyou@gmail.com>
中文版维护者: 贾威威 Jia Wei Wei <harryxiyou@gmail.com>
中文版翻译者: 贾威威 Jia Wei Wei <harryxiyou@gmail.com>
中文版校译者: 贾威威 Jia Wei Wei <harryxiyou@gmail.com>
:校译:
司延腾 Yanteng Si <siyanteng@loongson.cn>
Linux 魔术数
============
这个文件是有关当前使用的魔术值注册表。当你给一个结构添加了一个魔术值,你也应该把这个魔术值添加到这个文件,因为我们最好把用于各种结构的魔术值统一起来。
这个文件是有关当前使用的魔术值注册表。当你给一个结构体添加了一个魔术值,你也
应该把这个魔术值添加到这个文件,因为我们最好把用于各种结构体的魔术值统一起来。
使用魔术值来保护内核数据结构是一个非常好的主意。这就允许你在运行期检查(a)一个结构是否已经被攻击,或者(b)你已经给一个例行程序通过了一个错误的结构。后一种情况特别地有用---特别是当你通过一个空指针指向结构体的时候。tty源码,例如,经常通过特定驱动使用这种方法并且反复地排列特定方面的结构。
使用魔术值来保护内核数据结构是一个 **非常好的主意** 。这就允许你在运行时检
查一个结构体(a)是否已经被攻击,或者(b)你已经给一个例程传递了一个错误的结构
体。最后一种情况特别地有用---特别是当你通过一个空指针指向结构体的时候。例如,
tty源码经常通过特定驱动使用这种方法用来反复地排列特定方面的结构体。
使用魔术值的方法是在结构的开始处声明的,如下::
使用魔术值的方法是在结构体的开头声明它们,如下::
struct tty_ldisc {
int magic;
...
};
当你以后给内核添加增强功能的时候,请遵守这条规则!这样就会节省数不清的调试时间,特别是一些古怪的情况,例如,数组超出范围并且重新写了超出部分。遵守这个规则,这些情况可以被快速地,安全地避免。
当你以后给内核添加增强功能的时候,请遵守这条规则!这样就会节省数不清的调试
时间,特别是一些古怪的情况,例如,数组超出范围并且覆盖写了超出部分。利用这
个规则,这些情况可以被快速地,安全地检测到这些案例。
变更日志::
Theodore Ts'o
31 Mar 94
Theodore Ts'o
31 Mar 94
给当前的Linux 2.1.55添加魔术表。
给当前的Linux 2.1.55添加魔术表。
Michael Chastain
<mailto:mec@shout.net>
22 Sep 1997
Michael Chastain
<mailto:mec@shout.net>
22 Sep 1997
现在应该最新的Linux 2.1.112.因为在特性冻结期间,不能在2.2.x前改变任何东西。这些条目被数域所排序。
现在应该最新的Linux 2.1.112.因为在特性冻结期间,不能在2.2.x前改变任
何东西。这些条目被数域所排序。
Krzysztof G.Baranowski
<mailto: kgb@knm.org.pl>
29 Jul 1998
Krzysztof G.Baranowski
<mailto: kgb@knm.org.pl>
29 Jul 1998
更新魔术表到Linux 2.5.45。刚好越过特性冻结,但是有可能还会有一些新的魔术值在2.6.x之前融入到内核中。
更新魔术表到Linux 2.5.45。刚好越过特性冻结,但是有可能还会有一些新的魔
术值在2.6.x之前融入到内核中。
Petr Baudis
<pasky@ucw.cz>
03 Nov 2002
Petr Baudis
<pasky@ucw.cz>
03 Nov 2002
更新魔术表到Linux 2.5.74。
更新魔术表到Linux 2.5.74。
Fabian Frederick
<ffrederick@users.sourceforge.net>
09 Jul 2003
Fabian Frederick
<ffrederick@users.sourceforge.net>
09 Jul 2003
===================== ================ ======================== ==========================================
魔术数名 数字 结构 文件
......
......@@ -17,11 +17,8 @@ Linux 内核用户空间API指南
在代码树中仍然可以找到有关用户空间的部分信息。这个手册意在成为这些信息
聚集的地方。
.. class:: toc-title
目录
.. toctree::
:caption: 目录
:maxdepth: 2
no_new_privs
......
......@@ -7,7 +7,7 @@ help. Contact the Chinese maintainer if this translation is outdated
or if there is a problem with the translation.
Maintainer: Eric W. Biederman <ebiederman@xmission.com>
Traditional Chinese maintainer: Hu Haowen <src.res.211@gmail.com>
Traditional Chinese maintainer: Hu Haowen <2023002089@link.tyut.edu.cn>
---------------------------------------------------------------------
Documentation/core-api/irq/index.rst 的繁體中文翻譯
......@@ -16,9 +16,9 @@ Documentation/core-api/irq/index.rst 的繁體中文翻譯
者翻譯存在問題,請聯繫繁體中文版維護者。
英文版維護者: Eric W. Biederman <ebiederman@xmission.com>
繁體中文版維護者: 胡皓文 Hu Haowen <src.res.211@gmail.com>
繁體中文版翻譯者: 胡皓文 Hu Haowen <src.res.211@gmail.com>
繁體中文版校譯者: 胡皓文 Hu Haowen <src.res.211@gmail.com>
繁體中文版維護者: 胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
繁體中文版翻譯者: 胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
繁體中文版校譯者: 胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
以下爲正文
......
......@@ -7,7 +7,7 @@
:譯者:
吳想成 Wu XiangCheng <bobwxc@email.cn>
胡皓文 Hu Haowen <src.res.211@gmail.com>
胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
Linux內核6.x版本 <http://kernel.org/>
=========================================
......
......@@ -7,7 +7,7 @@
:譯者:
吳想成 Wu XiangCheng <bobwxc@email.cn>
胡皓文 Hu Haowen <src.res.211@gmail.com>
胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
二分(bisect)缺陷
+++++++++++++++++++
......
......@@ -7,7 +7,7 @@
:譯者:
吳想成 Wu XiangCheng <bobwxc@email.cn>
胡皓文 Hu Haowen <src.res.211@gmail.com>
胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
追蹤缺陷
=========
......
......@@ -2,7 +2,7 @@
.. include:: ../disclaimer-zh_TW.rst
:Translator: 胡皓文 Hu Haowen <src.res.211@gmail.com>
:Translator: 胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
清除 WARN_ONCE
--------------
......
......@@ -2,7 +2,7 @@
.. include:: ../disclaimer-zh_TW.rst
:Translator: 胡皓文 Hu Haowen <src.res.211@gmail.com>
:Translator: 胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
========
CPU 負載
......
......@@ -4,7 +4,7 @@
:Original: :doc:`../../../admin-guide/index`
:Translator: Alex Shi <alex.shi@linux.alibaba.com>
胡皓文 Hu Haowen <src.res.211@gmail.com>
胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
Linux 內核用戶和管理員指南
==========================
......
......@@ -7,7 +7,7 @@
:譯者:
吳想成 Wu XiangCheng <bobwxc@email.cn>
胡皓文 Hu Haowen <src.res.211@gmail.com>
胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
解釋“No working init found.”啓動掛起消息
=========================================
......
......@@ -9,7 +9,7 @@
:譯者:
吳想成 Wu XiangCheng <bobwxc@email.cn>
胡皓文 Hu Haowen <src.res.211@gmail.com>
胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
報告問題
......
......@@ -7,7 +7,7 @@
:譯者:
吳想成 Wu XiangCheng <bobwxc@email.cn>
胡皓文 Hu Haowen <src.res.211@gmail.com>
胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
安全缺陷
=========
......
......@@ -7,7 +7,7 @@
:譯者:
吳想成 Wu XiangCheng <bobwxc@email.cn>
胡皓文 Hu Haowen <src.res.211@gmail.com>
胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
受污染的內核
-------------
......
......@@ -7,7 +7,7 @@
:譯者:
吳想成 Wu XiangCheng <bobwxc@email.cn>
胡皓文 Hu Haowen <src.res.211@gmail.com>
胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
Unicode(統一碼)支持
======================
......
......@@ -5,7 +5,7 @@
:Original: :ref:`Documentation/arch/arm64/amu.rst <amu_index>`
Translator: Bailu Lin <bailu.lin@vivo.com>
Hu Haowen <src.res.211@gmail.com>
Hu Haowen <2023002089@link.tyut.edu.cn>
==================================
AArch64 Linux 中擴展的活動監控單元
......
......@@ -10,7 +10,7 @@ or if there is a problem with the translation.
M: Will Deacon <will.deacon@arm.com>
zh_CN: Fu Wei <wefu@redhat.com>
zh_TW: Hu Haowen <src.res.211@gmail.com>
zh_TW: Hu Haowen <2023002089@link.tyut.edu.cn>
C: 55f058e7574c3615dea4615573a19bdb258696c6
---------------------------------------------------------------------
Documentation/arch/arm64/booting.rst 的中文翻譯
......@@ -23,7 +23,7 @@ Documentation/arch/arm64/booting.rst 的中文翻譯
中文版維護者: 傅煒 Fu Wei <wefu@redhat.com>
中文版翻譯者: 傅煒 Fu Wei <wefu@redhat.com>
中文版校譯者: 傅煒 Fu Wei <wefu@redhat.com>
繁體中文版校譯者: 胡皓文 Hu Haowen <src.res.211@gmail.com>
繁體中文版校譯者: 胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
本文翻譯提交時的 Git 檢出點爲: 55f058e7574c3615dea4615573a19bdb258696c6
以下爲正文
......
......@@ -5,7 +5,7 @@
:Original: :ref:`Documentation/arch/arm64/elf_hwcaps.rst <elf_hwcaps_index>`
Translator: Bailu Lin <bailu.lin@vivo.com>
Hu Haowen <src.res.211@gmail.com>
Hu Haowen <2023002089@link.tyut.edu.cn>
================
ARM64 ELF hwcaps
......
......@@ -5,7 +5,7 @@
:Original: :ref:`Documentation/arch/arm64/hugetlbpage.rst <hugetlbpage_index>`
Translator: Bailu Lin <bailu.lin@vivo.com>
Hu Haowen <src.res.211@gmail.com>
Hu Haowen <2023002089@link.tyut.edu.cn>
=====================
ARM64中的 HugeTLBpage
......
......@@ -4,7 +4,7 @@
:Original: :ref:`Documentation/arch/arm64/index.rst <arm64_index>`
:Translator: Bailu Lin <bailu.lin@vivo.com>
Hu Haowen <src.res.211@gmail.com>
Hu Haowen <2023002089@link.tyut.edu.cn>
.. _tw_arm64_index:
......
......@@ -11,7 +11,7 @@ or if there is a problem with the translation.
Maintainer: Punit Agrawal <punit.agrawal@arm.com>
Suzuki K. Poulose <suzuki.poulose@arm.com>
Chinese maintainer: Fu Wei <wefu@redhat.com>
Traditional Chinese maintainer: Hu Haowen <src.res.211@gmail.com>
Traditional Chinese maintainer: Hu Haowen <2023002089@link.tyut.edu.cn>
---------------------------------------------------------------------
Documentation/arch/arm64/legacy_instructions.rst 的中文翻譯
......@@ -26,7 +26,7 @@ Documentation/arch/arm64/legacy_instructions.rst 的中文翻譯
中文版維護者: 傅煒 Fu Wei <wefu@redhat.com>
中文版翻譯者: 傅煒 Fu Wei <wefu@redhat.com>
中文版校譯者: 傅煒 Fu Wei <wefu@redhat.com>
繁體中文版校譯者:胡皓文 Hu Haowen <src.res.211@gmail.com>
繁體中文版校譯者:胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
以下爲正文
---------------------------------------------------------------------
......
......@@ -10,7 +10,7 @@ or if there is a problem with the translation.
Maintainer: Catalin Marinas <catalin.marinas@arm.com>
Chinese maintainer: Fu Wei <wefu@redhat.com>
Traditional Chinese maintainer: Hu Haowen <src.res.211@gmail.com>
Traditional Chinese maintainer: Hu Haowen <2023002089@link.tyut.edu.cn>
---------------------------------------------------------------------
Documentation/arch/arm64/memory.rst 的中文翻譯
......@@ -24,7 +24,7 @@ Documentation/arch/arm64/memory.rst 的中文翻譯
中文版維護者: 傅煒 Fu Wei <wefu@redhat.com>
中文版翻譯者: 傅煒 Fu Wei <wefu@redhat.com>
中文版校譯者: 傅煒 Fu Wei <wefu@redhat.com>
繁體中文版校譯者: 胡皓文 Hu Haowen <src.res.211@gmail.com>
繁體中文版校譯者: 胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
以下爲正文
---------------------------------------------------------------------
......
......@@ -5,7 +5,7 @@
:Original: :ref:`Documentation/arch/arm64/perf.rst <perf_index>`
Translator: Bailu Lin <bailu.lin@vivo.com>
Hu Haowen <src.res.211@gmail.com>
Hu Haowen <2023002089@link.tyut.edu.cn>
=============
Perf 事件屬性
......
......@@ -10,7 +10,7 @@ or if there is a problem with the translation.
M: Will Deacon <will.deacon@arm.com>
zh_CN: Fu Wei <wefu@redhat.com>
zh_TW: Hu Haowen <src.res.211@gmail.com>
zh_TW: Hu Haowen <2023002089@link.tyut.edu.cn>
C: 1926e54f115725a9248d0c4c65c22acaf94de4c4
---------------------------------------------------------------------
Documentation/arch/arm64/silicon-errata.rst 的中文翻譯
......@@ -23,7 +23,7 @@ Documentation/arch/arm64/silicon-errata.rst 的中文翻譯
中文版維護者: 傅煒 Fu Wei <wefu@redhat.com>
中文版翻譯者: 傅煒 Fu Wei <wefu@redhat.com>
中文版校譯者: 傅煒 Fu Wei <wefu@redhat.com>
繁體中文版校譯者: 胡皓文 Hu Haowen <src.res.211@gmail.com>
繁體中文版校譯者: 胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
本文翻譯提交時的 Git 檢出點爲: 1926e54f115725a9248d0c4c65c22acaf94de4c4
以下爲正文
......
......@@ -10,7 +10,7 @@ or if there is a problem with the translation.
Maintainer: Will Deacon <will.deacon@arm.com>
Chinese maintainer: Fu Wei <wefu@redhat.com>
Traditional Chinese maintainer: Hu Haowen <src.res.211@gmail.com>
Traditional Chinese maintainer: Hu Haowen <2023002089@link.tyut.edu.cn>
---------------------------------------------------------------------
Documentation/arch/arm64/tagged-pointers.rst 的中文翻譯
......@@ -22,7 +22,7 @@ Documentation/arch/arm64/tagged-pointers.rst 的中文翻譯
中文版維護者: 傅煒 Fu Wei <wefu@redhat.com>
中文版翻譯者: 傅煒 Fu Wei <wefu@redhat.com>
中文版校譯者: 傅煒 Fu Wei <wefu@redhat.com>
繁體中文版校譯者: 胡皓文 Hu Haowen <src.res.211@gmail.com>
繁體中文版校譯者: 胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
以下爲正文
---------------------------------------------------------------------
......
......@@ -6,19 +6,19 @@ communicating in English you can also ask the Chinese maintainer for
help. Contact the Chinese maintainer if this translation is outdated
or if there is a problem with the translation.
Traditional Chinese maintainer: Hu Haowen <src.res.211@gmail.com>
---------------------------------------------------------------------
Traditional Chinese maintainer: Hu Haowen <2023002089@link.tyut.edu.cn>
-------------------------------------------------------------------------
Documentation/dev-tools/sparse.rst 的繁體中文翻譯
如果想評論或更新本文的內容,請直接聯繫原文檔的維護者。如果你使用英文
交流有困難的話,也可以向繁體中文版維護者求助。如果本翻譯更新不及時或
者翻譯存在問題,請聯繫繁體中文版維護者。
繁體中文版維護者: 胡皓文 Hu Haowen <src.res.211@gmail.com>
繁體中文版翻譯者: 胡皓文 Hu Haowen <src.res.211@gmail.com>
繁體中文版維護者: 胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
繁體中文版翻譯者: 胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
以下爲正文
---------------------------------------------------------------------
-------------------------------------------------------------------------
Copyright 2004 Linus Torvalds
Copyright 2004 Pavel Machek <pavel@ucw.cz>
......
......@@ -3,7 +3,7 @@
.. include:: ../disclaimer-zh_TW.rst
:Original: Documentation/dev-tools/testing-overview.rst
:Translator: 胡皓文 Hu Haowen <src.res.211@gmail.com>
:Translator: 胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
============
內核測試指南
......
......@@ -7,5 +7,5 @@
.. note::
如果您發現本文檔與原始文件有任何不同或者有翻譯問題,請聯繫該文件的譯者,
或者發送電子郵件給胡皓文以獲取幫助:<src.res.211@gmail.com>。
或者發送電子郵件給胡皓文以獲取幫助:<2023002089@link.tyut.edu.cn>。
......@@ -14,7 +14,7 @@ Debugfs
中文版維護者: 羅楚成 Chucheng Luo <luochucheng@vivo.com>
中文版翻譯者: 羅楚成 Chucheng Luo <luochucheng@vivo.com>
中文版校譯者: 羅楚成 Chucheng Luo <luochucheng@vivo.com>
繁體中文版校譯者: 胡皓文 Hu Haowen <src.res.211@gmail.com>
繁體中文版校譯者: 胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
......
......@@ -4,7 +4,7 @@
:Original: :ref:`Documentation/filesystems/index.rst <filesystems_index>`
:Translator: Wang Wenhu <wenhu.wang@vivo.com>
Hu Haowen <src.res.211@gmail.com>
Hu Haowen <2023002089@link.tyut.edu.cn>
.. _tw_filesystems_index:
......
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment