diff --git a/.mailmap b/.mailmap
index 0049c0b49056e3217852a1d11be98c7b3fc76962..07a777f9d687eb8a9bc74b4aa53c080af8f3fccb 100644
--- a/.mailmap
+++ b/.mailmap
@@ -16,6 +16,8 @@ Alan Cox <alan@lxorguk.ukuu.org.uk>
Alan Cox <root@hraefn.swansea.linux.org.uk>
Aleksey Gorelov <aleksey_gorelov@phoenix.com>
Aleksandar Markovic <aleksandar.markovic@mips.com> <aleksandar.markovic@imgtec.com>
+Alex Shi <alex.shi@linux.alibaba.com> <alex.shi@intel.com>
+Alex Shi <alex.shi@linux.alibaba.com> <alex.shi@linaro.org>
Alexei Starovoitov <ast@kernel.org> <ast@plumgrid.com>
Alexei Starovoitov <ast@kernel.org> <alexei.starovoitov@gmail.com>
Alexei Starovoitov <ast@kernel.org> <ast@fb.com>
@@ -126,6 +128,8 @@ Leonid I Ananiev <leonid.i.ananiev@intel.com>
Linas Vepstas <linas@austin.ibm.com>
Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@web.de>
Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@ascom.ch>
+Li Yang <leoyang.li@nxp.com> <leo@zh-kernel.org>
+Li Yang <leoyang.li@nxp.com> <leoli@freescale.com>
Maciej W. Rozycki <macro@mips.com> <macro@imgtec.com>
Marcin Nowakowski <marcin.nowakowski@mips.com> <marcin.nowakowski@imgtec.com>
Mark Brown <broonie@sirena.org.uk>
@@ -217,6 +221,8 @@ Tejun Heo <htejun@gmail.com>
Thomas Graf <tgraf@suug.ch>
Thomas Pedersen <twp@codeaurora.org>
Tony Luck <tony.luck@intel.com>
+TripleX Chung <xxx.phy@gmail.com> <zhongyu@18mail.cn>
+TripleX Chung <xxx.phy@gmail.com> <triplex@zh-kernel.org>
Tsuneo Yoshioka <Tsuneo.Yoshioka@f-secure.com>
Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Uwe Kleine-König <ukl@pengutronix.de>
diff --git a/Documentation/ABI/testing/sysfs-kernel-livepatch b/Documentation/ABI/testing/sysfs-kernel-livepatch
index 85db352f68f9a999ee47acc7c515af111cfdbaeb..bea7bd5a1d5fc01124c090ca457eac089f6a3c57 100644
--- a/Documentation/ABI/testing/sysfs-kernel-livepatch
+++ b/Documentation/ABI/testing/sysfs-kernel-livepatch
@@ -45,7 +45,7 @@ Description:
use this feature without a clearance from a patch
distributor. Removal (rmmod) of patch modules is permanently
disabled when the feature is used. See
- Documentation/livepatch/livepatch.txt for more information.
+ Documentation/livepatch/livepatch.rst for more information.
What: /sys/kernel/livepatch/<patch>/<object>
Date: Nov 2014
diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt
index 1a721d0f35c857d38cda0d6572a7facb49059d90..db48c6fd3162bcec973a591bea97af602230148a 100644
--- a/Documentation/DMA-API-HOWTO.txt
+++ b/Documentation/DMA-API-HOWTO.txt
@@ -147,7 +147,7 @@ networking subsystems make sure that the buffers they use are valid
for you to DMA from/to.
DMA addressing capabilities
-==========================
+===========================
By default, the kernel assumes that your device can address 32-bits of DMA
addressing. For a 64-bit capable device, this needs to be increased, and for
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 9786957c6a35a00e8ba4546f95dd87d4eae93742..e889e7cb8511ed3fbc7f076e6bfbc681a27d6130 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -28,8 +28,13 @@ ifeq ($(HAVE_SPHINX),0)
else # HAVE_SPHINX
-# User-friendly check for pdflatex
+# User-friendly check for pdflatex and latexmk
HAVE_PDFLATEX := $(shell if which $(PDFLATEX) >/dev/null 2>&1; then echo 1; else echo 0; fi)
+HAVE_LATEXMK := $(shell if which latexmk >/dev/null 2>&1; then echo 1; else echo 0; fi)
+
+ifeq ($(HAVE_LATEXMK),1)
+ PDFLATEX := latexmk -$(PDFLATEX)
+endif #HAVE_LATEXMK
# Internal variables.
PAPEROPT_a4 = -D latex_paper_size=a4
@@ -82,7 +87,7 @@ pdfdocs:
else # HAVE_PDFLATEX
pdfdocs: latexdocs
- $(foreach var,$(SPHINXDIRS), $(MAKE) PDFLATEX=$(PDFLATEX) LATEXOPTS="$(LATEXOPTS)" -C $(BUILDDIR)/$(var)/latex || exit;)
+ $(foreach var,$(SPHINXDIRS), $(MAKE) PDFLATEX="$(PDFLATEX)" LATEXOPTS="$(LATEXOPTS)" -C $(BUILDDIR)/$(var)/latex || exit;)
endif # HAVE_PDFLATEX
diff --git a/Documentation/atomic_bitops.txt b/Documentation/atomic_bitops.txt
index be70b32c95d918066ffa72dfa4a69e8b4e51a225..093cdaefdb3733ecd076b5ffbfe3ad880b2c3afd 100644
--- a/Documentation/atomic_bitops.txt
+++ b/Documentation/atomic_bitops.txt
@@ -1,6 +1,6 @@
-
-On atomic bitops.
-
+=============
+Atomic bitops
+=============
While our bitmap_{}() functions are non-atomic, we have a number of operations
operating on single bits in a bitmap that are atomic.
diff --git a/Documentation/clearing-warn-once.txt b/Documentation/clearing-warn-once.txt
index c68598b31428d7726816011b8ff4bd1eab33f583..211fd926cf00f5994f322d4edb1f0d45a4fd442a 100644
--- a/Documentation/clearing-warn-once.txt
+++ b/Documentation/clearing-warn-once.txt
@@ -1,3 +1,5 @@
+Clearing WARN_ONCE
+------------------
WARN_ONCE / WARN_ON_ONCE / printk_once only emit a message once.
diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst
index 6870baffef82d470de7cc699a7599e075d3f71b5..ee1bb8983a882c2b349e3573399ffef9b5bf98c2 100644
--- a/Documentation/core-api/index.rst
+++ b/Documentation/core-api/index.rst
@@ -22,7 +22,6 @@ Core utilities
workqueue
genericirq
xarray
- flexible-arrays
librs
genalloc
errseq
diff --git a/Documentation/dev-tools/kselftest.rst b/Documentation/dev-tools/kselftest.rst
index c8c03388b9de62eeda239bda0a687dda759030b8..25604904fa6ed51292b02878691966716a68b140 100644
--- a/Documentation/dev-tools/kselftest.rst
+++ b/Documentation/dev-tools/kselftest.rst
@@ -7,6 +7,11 @@ directory. These are intended to be small tests to exercise individual code
paths in the kernel. Tests are intended to be run after building, installing
and booting a kernel.
+You can find additional information on Kselftest framework, how to
+write new tests using the framework on Kselftest wiki:
+
+https://kselftest.wiki.kernel.org/
+
On some systems, hot-plug tests could hang forever waiting for cpu and
memory to be ready to be offlined. A special hot-plug target is created
to run the full range of hot-plug tests. In default mode, hot-plug tests run
@@ -35,17 +40,32 @@ To build and run the tests with a single command, use::
Note that some tests will require root privileges.
-Build and run from user specific object directory (make O=dir)::
+Kselftest supports saving output files in a separate directory and then
+running tests. To locate output files in a separate directory two syntaxes
+are supported. In both cases the working directory must be the root of the
+kernel src. This is applicable to "Running a subset of selftests" section
+below.
+
+To build, save output files in a separate directory with O= ::
$ make O=/tmp/kselftest kselftest
-Build and run KBUILD_OUTPUT directory (make KBUILD_OUTPUT=)::
+To build, save output files in a separate directory with KBUILD_OUTPUT ::
+
+ $ export KBUILD_OUTPUT=/tmp/kselftest; make kselftest
- $ make KBUILD_OUTPUT=/tmp/kselftest kselftest
+The O= assignment takes precedence over the KBUILD_OUTPUT environment
+variable.
-The above commands run the tests and print pass/fail summary to make it
-easier to understand the test results. Please find the detailed individual
-test results for each test in /tmp/testname file(s).
+The above commands by default run the tests and print full pass/fail report.
+Kselftest supports "summary" option to make it easier to understand the test
+results. Please find the detailed individual test results for each test in
+/tmp/testname file(s) when summary option is specified. This is applicable
+to "Running a subset of selftests" section below.
+
+To run kselftest with summary option enabled ::
+
+ $ make summary=1 kselftest
Running a subset of selftests
=============================
@@ -61,17 +81,13 @@ You can specify multiple tests to build and run::
$ make TARGETS="size timers" kselftest
-Build and run from user specific object directory (make O=dir)::
+To build, save output files in a separate directory with O= ::
$ make O=/tmp/kselftest TARGETS="size timers" kselftest
-Build and run KBUILD_OUTPUT directory (make KBUILD_OUTPUT=)::
-
- $ make KBUILD_OUTPUT=/tmp/kselftest TARGETS="size timers" kselftest
+To build, save output files in a separate directory with KBUILD_OUTPUT ::
-The above commands run the tests and print pass/fail summary to make it
-easier to understand the test results. Please find the detailed individual
-test results for each test in /tmp/testname file(s).
+ $ export KBUILD_OUTPUT=/tmp/kselftest; make TARGETS="size timers" kselftest
See the top-level tools/testing/selftests/Makefile for the list of all
possible targets.
diff --git a/Documentation/doc-guide/index.rst b/Documentation/doc-guide/index.rst
index a7f95d7d3a6355e08c1082b90506d5156f3f73e1..603f3ff55d5ab29587c604afa9eab5c23dba69e8 100644
--- a/Documentation/doc-guide/index.rst
+++ b/Documentation/doc-guide/index.rst
@@ -7,9 +7,9 @@ How to write kernel documentation
.. toctree::
:maxdepth: 1
- sphinx.rst
- kernel-doc.rst
- parse-headers.rst
+ sphinx
+ kernel-doc
+ parse-headers
.. only:: subproject and html
diff --git a/Documentation/dontdiff b/Documentation/dontdiff
index 48e1930fb4a4d895e1822e82062b2a58d747f851..5eba889ea84da0b95728adfb6f82fa9b0213bbdb 100644
--- a/Documentation/dontdiff
+++ b/Documentation/dontdiff
@@ -127,7 +127,7 @@ flask.h
fore200e_mkfirm
fore200e_pca_fw.c*
gconf
-gconf.glade.h
+gconf-cfg
gen-devlist
gen_crc32table
gen_init_cpio
@@ -148,24 +148,22 @@ int32.c
int4.c
int8.c
kallsyms
-kconfig
keywords.c
ksym.c*
ksym.h*
-kxgettext
*lex.c
*lex.*.c
linux
logo_*.c
logo_*_clut224.c
logo_*_mono.c
-lxdialog
mach-types
mach-types.h
machtypes.h
map
map_hugetlb
mconf
+mconf-cfg
miboot*
mk_elfconfig
mkboot
@@ -183,6 +181,7 @@ modules.builtin.modinfo
modules.order
modversions.h*
nconf
+nconf-cfg
ncscope.*
offset.h
oui.c*
@@ -202,6 +201,7 @@ pnmtologo
ppc_defs.h*
pss_boot.h
qconf
+qconf-cfg
r100_reg_safe.h
r200_reg_safe.h
r300_reg_safe.h
diff --git a/Documentation/driver-api/soundwire/stream.rst b/Documentation/driver-api/soundwire/stream.rst
index 26a6064503fdb45523c8c6ef5c5e3b10a9bfc4e1..5351bd2f34a870ec5666cfd24610d4c4814c85a6 100644
--- a/Documentation/driver-api/soundwire/stream.rst
+++ b/Documentation/driver-api/soundwire/stream.rst
@@ -201,7 +201,7 @@ Bus implements below API for allocate a stream which needs to be called once
per stream. From ASoC DPCM framework, this stream state maybe linked to
.startup() operation.
- .. code-block:: c
+.. code-block:: c
int sdw_alloc_stream(char * stream_name);
@@ -228,7 +228,7 @@ the respective Master(s) and Slave(s) associated with stream. These APIs can
only be invoked once by respective Master(s) and Slave(s). From ASoC DPCM
framework, this stream state is linked to .hw_params() operation.
- .. code-block:: c
+.. code-block:: c
int sdw_stream_add_master(struct sdw_bus * bus,
struct sdw_stream_config * stream_config,
@@ -274,7 +274,7 @@ Bus implements below API for PREPARE state which needs to be called once per
stream. From ASoC DPCM framework, this stream state is linked to
.prepare() operation.
- .. code-block:: c
+.. code-block:: c
int sdw_prepare_stream(struct sdw_stream_runtime * stream);
@@ -304,7 +304,7 @@ Bus implements below API for ENABLE state which needs to be called once per
stream. From ASoC DPCM framework, this stream state is linked to
.trigger() start operation.
- .. code-block:: c
+.. code-block:: c
int sdw_enable_stream(struct sdw_stream_runtime * stream);
@@ -332,7 +332,7 @@ Bus implements below API for DISABLED state which needs to be called once
per stream. From ASoC DPCM framework, this stream state is linked to
.trigger() stop operation.
- .. code-block:: c
+.. code-block:: c
int sdw_disable_stream(struct sdw_stream_runtime * stream);
@@ -357,7 +357,7 @@ Bus implements below API for DEPREPARED state which needs to be called once
per stream. From ASoC DPCM framework, this stream state is linked to
.trigger() stop operation.
- .. code-block:: c
+.. code-block:: c
int sdw_deprepare_stream(struct sdw_stream_runtime * stream);
@@ -382,7 +382,7 @@ Bus implements below APIs for RELEASE state which needs to be called by
all the Master(s) and Slave(s) associated with stream. From ASoC DPCM
framework, this stream state is linked to .hw_free() operation.
- .. code-block:: c
+.. code-block:: c
int sdw_stream_remove_master(struct sdw_bus * bus,
struct sdw_stream_runtime * stream);
@@ -395,7 +395,7 @@ stream assigned as part of ALLOCATED state.
In .shutdown() the data structure maintaining stream state are freed up.
- .. code-block:: c
+.. code-block:: c
void sdw_release_stream(struct sdw_stream_runtime * stream);
diff --git a/Documentation/livepatch/callbacks.txt b/Documentation/livepatch/callbacks.rst
similarity index 87%
rename from Documentation/livepatch/callbacks.txt
rename to Documentation/livepatch/callbacks.rst
index 182e31d4abce5ff3f0291eea18cdb6e8cba7f297..470944aa865811e5c49c58245ab49fbe8a3f2ec6 100644
--- a/Documentation/livepatch/callbacks.txt
+++ b/Documentation/livepatch/callbacks.rst
@@ -4,7 +4,7 @@
Livepatch (un)patch-callbacks provide a mechanism for livepatch modules
to execute callback functions when a kernel object is (un)patched. They
-can be considered a "power feature" that extends livepatching abilities
+can be considered a **power feature** that **extends livepatching abilities**
to include:
- Safe updates to global data
@@ -17,6 +17,9 @@ In most cases, (un)patch callbacks will need to be used in conjunction
with memory barriers and kernel synchronization primitives, like
mutexes/spinlocks, or even stop_machine(), to avoid concurrency issues.
+1. Motivation
+=============
+
Callbacks differ from existing kernel facilities:
- Module init/exit code doesn't run when disabling and re-enabling a
@@ -28,21 +31,31 @@ Callbacks are part of the klp_object structure and their implementation
is specific to that klp_object. Other livepatch objects may or may not
be patched, irrespective of the target klp_object's current state.
+2. Callback types
+=================
+
Callbacks can be registered for the following livepatch actions:
- * Pre-patch - before a klp_object is patched
+ * Pre-patch
+ - before a klp_object is patched
- * Post-patch - after a klp_object has been patched and is active
+ * Post-patch
+ - after a klp_object has been patched and is active
across all tasks
- * Pre-unpatch - before a klp_object is unpatched (ie, patched code is
+ * Pre-unpatch
+ - before a klp_object is unpatched (ie, patched code is
active), used to clean up post-patch callback
resources
- * Post-unpatch - after a klp_object has been patched, all code has
+ * Post-unpatch
+ - after a klp_object has been patched, all code has
been restored and no tasks are running patched code,
used to cleanup pre-patch callback resources
+3. How it works
+===============
+
Each callback is optional, omitting one does not preclude specifying any
other. However, the livepatching core executes the handlers in
symmetry: pre-patch callbacks have a post-unpatch counterpart and
@@ -86,11 +99,14 @@ If the object did successfully patch, but the patch transition never
started for some reason (e.g., if another object failed to patch),
only the post-unpatch callback will be called.
+4. Use cases
+============
-Example Use-cases
-=================
+Sample livepatch modules demonstrating the callback API can be found in
+samples/livepatch/ directory. These samples were modified for use in
+kselftests and can be found in the lib/livepatch directory.
-Update global data
+Global data update
------------------
A pre-patch callback can be useful to update a global variable. For
@@ -103,24 +119,15 @@ patch the data *after* patching is complete with a post-patch callback,
so that tcp_send_challenge_ack() could first be changed to read
sysctl_tcp_challenge_ack_limit with READ_ONCE.
-
-Support __init and probe function patches
+__init and probe function patches support
-----------------------------------------
Although __init and probe functions are not directly livepatch-able, it
may be possible to implement similar updates via pre/post-patch
callbacks.
-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
value may need to be updated accordingly.)
-
-
-Other Examples
-==============
-
-Sample livepatch modules demonstrating the callback API can be found in
-samples/livepatch/ directory. These samples were modified for use in
-kselftests and can be found in the lib/livepatch directory.
diff --git a/Documentation/livepatch/cumulative-patches.txt b/Documentation/livepatch/cumulative-patches.rst
similarity index 89%
rename from Documentation/livepatch/cumulative-patches.txt
rename to Documentation/livepatch/cumulative-patches.rst
index 0012808e8d4437d2c85bad4caca5510b0668380c..1931f318976a5c538f6b2b14b4e6f46cef2a5a52 100644
--- a/Documentation/livepatch/cumulative-patches.txt
+++ b/Documentation/livepatch/cumulative-patches.rst
@@ -18,7 +18,7 @@ Usage
-----
The atomic replace can be enabled by setting "replace" flag in struct klp_patch,
-for example:
+for example::
static struct klp_patch patch = {
.mod = THIS_MODULE,
@@ -49,19 +49,19 @@ Features
The atomic replace allows:
- + Atomically revert some functions in a previous patch while
+ - Atomically revert some functions in a previous patch while
upgrading other functions.
- + Remove eventual performance impact caused by core redirection
+ - Remove eventual performance impact caused by core redirection
for functions that are no longer patched.
- + Decrease user confusion about dependencies between livepatches.
+ - Decrease user confusion about dependencies between livepatches.
Limitations:
------------
- + Once the operation finishes, there is no straightforward way
+ - Once the operation finishes, there is no straightforward way
to reverse it and restore the replaced patches atomically.
A good practice is to set .replace flag in any released livepatch.
@@ -74,7 +74,7 @@ Limitations:
only when the transition was not forced.
- + Only the (un)patching callbacks from the _new_ cumulative livepatch are
+ - Only the (un)patching callbacks from the _new_ cumulative livepatch are
executed. Any callbacks from the replaced patches are ignored.
In other words, the cumulative patch is responsible for doing any actions
@@ -93,7 +93,7 @@ Limitations:
enabled patches were called.
- + There is no special handling of shadow variables. Livepatch authors
+ - There is no special handling of shadow variables. Livepatch authors
must create their own rules how to pass them from one cumulative
patch to the other. Especially that they should not blindly remove
them in module_exit() functions.
diff --git a/Documentation/livepatch/index.rst b/Documentation/livepatch/index.rst
new file mode 100644
index 0000000000000000000000000000000000000000..edd291d51847441d2f8cb116449ba51886151500
--- /dev/null
+++ b/Documentation/livepatch/index.rst
@@ -0,0 +1,21 @@
+:orphan:
+
+===================
+Kernel Livepatching
+===================
+
+.. toctree::
+ :maxdepth: 1
+
+ livepatch
+ callbacks
+ cumulative-patches
+ module-elf-format
+ shadow-vars
+
+.. only:: subproject and html
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/Documentation/livepatch/livepatch.txt b/Documentation/livepatch/livepatch.rst
similarity index 93%
rename from Documentation/livepatch/livepatch.txt
rename to Documentation/livepatch/livepatch.rst
index 4627b41ff02ef2ddbac5cdc0d142d69ac3b40741..c2c598c4ead89779709f760de2afc4d5902169b2 100644
--- a/Documentation/livepatch/livepatch.txt
+++ b/Documentation/livepatch/livepatch.rst
@@ -4,22 +4,22 @@ Livepatch
This document outlines basic information about kernel livepatching.
-Table of Contents:
-
-1. Motivation
-2. Kprobes, Ftrace, Livepatching
-3. Consistency model
-4. Livepatch module
- 4.1. New functions
- 4.2. Metadata
-5. Livepatch life-cycle
- 5.1. Loading
- 5.2. Enabling
- 5.3. Replacing
- 5.4. Disabling
- 5.5. Removing
-6. Sysfs
-7. Limitations
+.. Table of Contents:
+
+ 1. Motivation
+ 2. Kprobes, Ftrace, Livepatching
+ 3. Consistency model
+ 4. Livepatch module
+ 4.1. New functions
+ 4.2. Metadata
+ 5. Livepatch life-cycle
+ 5.1. Loading
+ 5.2. Enabling
+ 5.3. Replacing
+ 5.4. Disabling
+ 5.5. Removing
+ 6. Sysfs
+ 7. Limitations
1. Motivation
@@ -40,14 +40,14 @@ There are multiple mechanisms in the Linux kernel that are directly related
to redirection of code execution; namely: kernel probes, function tracing,
and livepatching:
- + The kernel probes are the most generic. The code can be redirected by
+ - The kernel probes are the most generic. The code can be redirected by
putting a breakpoint instruction instead of any instruction.
- + The function tracer calls the code from a predefined location that is
+ - The function tracer calls the code from a predefined location that is
close to the function entry point. This location is generated by the
compiler using the '-pg' gcc option.
- + Livepatching typically needs to redirect the code at the very beginning
+ - Livepatching typically needs to redirect the code at the very beginning
of the function entry before the function parameters or the stack
are in any way modified.
@@ -249,7 +249,7 @@ The patch contains only functions that are really modified. But they
might want to access functions or data from the original source file
that may only be locally accessible. This can be solved by a special
relocation section in the generated livepatch module, see
-Documentation/livepatch/module-elf-format.txt for more details.
+Documentation/livepatch/module-elf-format.rst for more details.
4.2. Metadata
@@ -258,7 +258,7 @@ Documentation/livepatch/module-elf-format.txt for more details.
The patch is described by several structures that split the information
into three levels:
- + struct klp_func is defined for each patched function. It describes
+ - struct klp_func is defined for each patched function. It describes
the relation between the original and the new implementation of a
particular function.
@@ -275,7 +275,7 @@ into three levels:
only for a particular object ( vmlinux or a kernel module ). Note that
kallsyms allows for searching symbols according to the object name.
- + struct klp_object defines an array of patched functions (struct
+ - struct klp_object defines an array of patched functions (struct
klp_func) in the same object. Where the object is either vmlinux
(NULL) or a module name.
@@ -285,7 +285,7 @@ into three levels:
only when they are available.
- + struct klp_patch defines an array of patched objects (struct
+ - struct klp_patch defines an array of patched objects (struct
klp_object).
This structure handles all patched functions consistently and eventually,
@@ -337,14 +337,16 @@ operation fails.
Second, livepatch enters into a transition state where tasks are converging
to the patched state. If an original function is patched for the first
time, a function specific struct klp_ops is created and an universal
-ftrace handler is registered[*]. This stage is indicated by a value of '1'
+ftrace handler is registered\ [#]_. This stage is indicated by a value of '1'
in /sys/kernel/livepatch/<name>/transition. For more information about
this process, see the "Consistency model" section.
Finally, once all tasks have been patched, the 'transition' value changes
to '0'.
-[*] Note that functions might be patched multiple times. The ftrace handler
+.. [#]
+
+ Note that functions might be patched multiple times. The ftrace handler
is registered only once for a given function. Further patches just add
an entry to the list (see field `func_stack`) of the struct klp_ops.
The right implementation is selected by the ftrace handler, see
@@ -368,7 +370,7 @@ the ftrace handler is unregistered and the struct klp_ops is
freed when the related function is not modified by the new patch
and func_stack list becomes empty.
-See Documentation/livepatch/cumulative-patches.txt for more details.
+See Documentation/livepatch/cumulative-patches.rst for more details.
5.4. Disabling
@@ -421,7 +423,7 @@ See Documentation/ABI/testing/sysfs-kernel-livepatch for more details.
The current Livepatch implementation has several limitations:
- + Only functions that can be traced could be patched.
+ - Only functions that can be traced could be patched.
Livepatch is based on the dynamic ftrace. In particular, functions
implementing ftrace or the livepatch ftrace handler could not be
@@ -431,7 +433,7 @@ The current Livepatch implementation has several limitations:
- + Livepatch works reliably only when the dynamic ftrace is located at
+ - Livepatch works reliably only when the dynamic ftrace is located at
the very beginning of the function.
The function need to be redirected before the stack or the function
@@ -445,7 +447,7 @@ The current Livepatch implementation has several limitations:
this is handled on the ftrace level.
- + Kretprobes using the ftrace framework conflict with the patched
+ - Kretprobes using the ftrace framework conflict with the patched
functions.
Both kretprobes and livepatches use a ftrace handler that modifies
@@ -453,7 +455,7 @@ The current Livepatch implementation has several limitations:
is rejected when the handler is already in use by the other.
- + Kprobes in the original function are ignored when the code is
+ - Kprobes in the original function are ignored when the code is
redirected to the new implementation.
There is a work in progress to add warnings about this situation.
diff --git a/Documentation/livepatch/module-elf-format.txt b/Documentation/livepatch/module-elf-format.rst
similarity index 55%
rename from Documentation/livepatch/module-elf-format.txt
rename to Documentation/livepatch/module-elf-format.rst
index f21a5289a09c5142c77e801493f2227fe47327b2..2a591e6f8e6c4539e842ed19c29174578a3add54 100644
--- a/Documentation/livepatch/module-elf-format.txt
+++ b/Documentation/livepatch/module-elf-format.rst
@@ -4,33 +4,21 @@ Livepatch module Elf format
This document outlines the Elf format requirements that livepatch modules must follow.
------------------
-Table of Contents
------------------
-0. Background and motivation
-1. Livepatch modinfo field
-2. Livepatch relocation sections
- 2.1 What are livepatch relocation sections?
- 2.2 Livepatch relocation section format
- 2.2.1 Required flags
- 2.2.2 Required name format
- 2.2.3 Example livepatch relocation section names
- 2.2.4 Example `readelf --sections` output
- 2.2.5 Example `readelf --relocs` output
-3. Livepatch symbols
- 3.1 What are livepatch symbols?
- 3.2 A livepatch module's symbol table
- 3.3 Livepatch symbol format
- 3.3.1 Required flags
- 3.3.2 Required name format
- 3.3.3 Example livepatch symbol names
- 3.3.4 Example `readelf --symbols` output
-4. Architecture-specific sections
-5. Symbol table and Elf section access
-
-----------------------------
-0. Background and motivation
-----------------------------
+
+.. Table of Contents
+
+ 1. Background and motivation
+ 2. Livepatch modinfo field
+ 3. Livepatch relocation sections
+ 3.1 Livepatch relocation section format
+ 4. Livepatch symbols
+ 4.1 A livepatch module's symbol table
+ 4.2 Livepatch symbol format
+ 5. Architecture-specific sections
+ 6. Symbol table and Elf section access
+
+1. Background and motivation
+============================
Formerly, livepatch required separate architecture-specific code to write
relocations. However, arch-specific code to write relocations already
@@ -52,8 +40,8 @@ relocation sections and symbols, which are described in this document. The
Elf constants used to mark livepatch symbols and relocation sections were
selected from OS-specific ranges according to the definitions from glibc.
-0.1 Why does livepatch need to write its own relocations?
----------------------------------------------------------
+Why does livepatch need to write its own relocations?
+-----------------------------------------------------
A typical livepatch module contains patched versions of functions that can
reference non-exported global symbols and non-included local symbols.
Relocations referencing these types of symbols cannot be left in as-is
@@ -72,13 +60,8 @@ relas reference are special livepatch symbols (see section 2 and 3). The
arch-specific livepatch relocation code is replaced by a call to
apply_relocate_add().
-================================
-PATCH MODULE FORMAT REQUIREMENTS
-================================
-
---------------------------
-1. Livepatch modinfo field
---------------------------
+2. Livepatch modinfo field
+==========================
Livepatch modules are required to have the "livepatch" modinfo attribute.
See the sample livepatch module in samples/livepatch/ for how this is done.
@@ -87,22 +70,23 @@ Livepatch modules can be identified by users by using the 'modinfo' command
and looking for the presence of the "livepatch" field. This field is also
used by the kernel module loader to identify livepatch modules.
-Example modinfo output:
------------------------
-% modinfo livepatch-meminfo.ko
-filename: livepatch-meminfo.ko
-livepatch: Y
-license: GPL
-depends:
-vermagic: 4.3.0+ SMP mod_unload
-
---------------------------------
-2. Livepatch relocation sections
---------------------------------
-
--------------------------------------------
-2.1 What are livepatch relocation sections?
--------------------------------------------
+Example:
+--------
+
+**Modinfo output:**
+
+::
+
+ % modinfo livepatch-meminfo.ko
+ filename: livepatch-meminfo.ko
+ livepatch: Y
+ license: GPL
+ depends:
+ vermagic: 4.3.0+ SMP mod_unload
+
+3. Livepatch relocation sections
+================================
+
A livepatch module manages its own Elf relocation sections to apply
relocations to modules as well as to the kernel (vmlinux) at the
appropriate time. For example, if a patch module patches a driver that is
@@ -127,12 +111,9 @@ Every symbol referenced by a rela in a livepatch relocation section is a
livepatch symbol. These must be resolved before livepatch can call
apply_relocate_add(). See Section 3 for more information.
----------------------------------------
-2.2 Livepatch relocation section format
----------------------------------------
+3.1 Livepatch relocation section format
+=======================================
-2.2.1 Required flags
---------------------
Livepatch relocation sections must be marked with the SHF_RELA_LIVEPATCH
section flag. See include/uapi/linux/elf.h for the definition. The module
loader recognizes this flag and will avoid applying those relocation sections
@@ -140,28 +121,39 @@ at patch module load time. These sections must also be marked with SHF_ALLOC,
so that the module loader doesn't discard them on module load (i.e. they will
be copied into memory along with the other SHF_ALLOC sections).
-2.2.2 Required name format
---------------------------
-The name of a livepatch relocation section must conform to the following format:
+The name of a livepatch relocation section must conform to the following
+format::
-.klp.rela.objname.section_name
-^ ^^ ^ ^ ^
-|________||_____| |__________|
- [A] [B] [C]
+ .klp.rela.objname.section_name
+ ^ ^^ ^ ^ ^
+ |________||_____| |__________|
+ [A] [B] [C]
-[A] The relocation section name is prefixed with the string ".klp.rela."
-[B] The name of the object (i.e. "vmlinux" or name of module) to
- which the relocation section belongs follows immediately after the prefix.
-[C] The actual name of the section to which this relocation section applies.
+[A]
+ The relocation section name is prefixed with the string ".klp.rela."
-2.2.3 Example livepatch relocation section names:
--------------------------------------------------
-.klp.rela.ext4.text.ext4_attr_store
-.klp.rela.vmlinux.text.cmdline_proc_show
+[B]
+ The name of the object (i.e. "vmlinux" or name of module) to
+ which the relocation section belongs follows immediately after the prefix.
+
+[C]
+ The actual name of the section to which this relocation section applies.
+
+Examples:
+---------
+
+**Livepatch relocation section names:**
+
+::
+
+ .klp.rela.ext4.text.ext4_attr_store
+ .klp.rela.vmlinux.text.cmdline_proc_show
+
+**`readelf --sections` output for a patch
+module that patches vmlinux and modules 9p, btrfs, ext4:**
+
+::
-2.2.4 Example `readelf --sections` output for a patch
-module that patches vmlinux and modules 9p, btrfs, ext4:
---------------------------------------------------------
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[ snip ]
@@ -175,31 +167,33 @@ module that patches vmlinux and modules 9p, btrfs, ext4:
[ snip ] ^ ^
| |
[*] [*]
-[*] Livepatch relocation sections are SHT_RELA sections but with a few special
-characteristics. Notice that they are marked SHF_ALLOC ("A") so that they will
-not be discarded when the module is loaded into memory, as well as with the
-SHF_RELA_LIVEPATCH flag ("o" - for OS-specific).
-
-2.2.5 Example `readelf --relocs` output for a patch module:
------------------------------------------------------------
-Relocation section '.klp.rela.btrfs.text.btrfs_feature_attr_show' at offset 0x2ba0 contains 4 entries:
- Offset Info Type Symbol's Value Symbol's Name + Addend
-000000000000001f 0000005e00000002 R_X86_64_PC32 0000000000000000 .klp.sym.vmlinux.printk,0 - 4
-0000000000000028 0000003d0000000b R_X86_64_32S 0000000000000000 .klp.sym.btrfs.btrfs_ktype,0 + 0
-0000000000000036 0000003b00000002 R_X86_64_PC32 0000000000000000 .klp.sym.btrfs.can_modify_feature.isra.3,0 - 4
-000000000000004c 0000004900000002 R_X86_64_PC32 0000000000000000 .klp.sym.vmlinux.snprintf,0 - 4
-[ snip ] ^
- |
- [*]
-[*] Every symbol referenced by a relocation is a livepatch symbol.
-
---------------------
-3. Livepatch symbols
---------------------
-
--------------------------------
-3.1 What are livepatch symbols?
--------------------------------
+
+[*]
+ Livepatch relocation sections are SHT_RELA sections but with a few special
+ characteristics. Notice that they are marked SHF_ALLOC ("A") so that they will
+ not be discarded when the module is loaded into memory, as well as with the
+ SHF_RELA_LIVEPATCH flag ("o" - for OS-specific).
+
+**`readelf --relocs` output for a patch module:**
+
+::
+
+ Relocation section '.klp.rela.btrfs.text.btrfs_feature_attr_show' at offset 0x2ba0 contains 4 entries:
+ Offset Info Type Symbol's Value Symbol's Name + Addend
+ 000000000000001f 0000005e00000002 R_X86_64_PC32 0000000000000000 .klp.sym.vmlinux.printk,0 - 4
+ 0000000000000028 0000003d0000000b R_X86_64_32S 0000000000000000 .klp.sym.btrfs.btrfs_ktype,0 + 0
+ 0000000000000036 0000003b00000002 R_X86_64_PC32 0000000000000000 .klp.sym.btrfs.can_modify_feature.isra.3,0 - 4
+ 000000000000004c 0000004900000002 R_X86_64_PC32 0000000000000000 .klp.sym.vmlinux.snprintf,0 - 4
+ [ snip ] ^
+ |
+ [*]
+
+[*]
+ Every symbol referenced by a relocation is a livepatch symbol.
+
+4. Livepatch symbols
+====================
+
Livepatch symbols are symbols referred to by livepatch relocation sections.
These are symbols accessed from new versions of functions for patched
objects, whose addresses cannot be resolved by the module loader (because
@@ -219,9 +213,8 @@ loader can identify and ignore them. Livepatch modules keep these symbols
in their symbol tables, and the symbol table is made accessible through
module->symtab.
--------------------------------------
-3.2 A livepatch module's symbol table
--------------------------------------
+4.1 A livepatch module's symbol table
+=====================================
Normally, a stripped down copy of a module's symbol table (containing only
"core" symbols) is made available through module->symtab (See layout_symtab()
in kernel/module.c). For livepatch modules, the symbol table copied into memory
@@ -231,71 +224,82 @@ relocation section refer to their respective symbols with their symbol indices,
and the original symbol indices (and thus the symtab ordering) must be
preserved in order for apply_relocate_add() to find the right symbol.
-For example, take this particular rela from a livepatch module:
-Relocation section '.klp.rela.btrfs.text.btrfs_feature_attr_show' at offset 0x2ba0 contains 4 entries:
- Offset Info Type Symbol's Value Symbol's Name + Addend
-000000000000001f 0000005e00000002 R_X86_64_PC32 0000000000000000 .klp.sym.vmlinux.printk,0 - 4
-
-This rela refers to the symbol '.klp.sym.vmlinux.printk,0', and the symbol index is encoded
-in 'Info'. Here its symbol index is 0x5e, which is 94 in decimal, which refers to the
-symbol index 94.
-And in this patch module's corresponding symbol table, symbol index 94 refers to that very symbol:
-[ snip ]
-94: 0000000000000000 0 NOTYPE GLOBAL DEFAULT OS [0xff20] .klp.sym.vmlinux.printk,0
-[ snip ]
-
----------------------------
-3.3 Livepatch symbol format
----------------------------
-
-3.3.1 Required flags
---------------------
+For example, take this particular rela from a livepatch module:::
+
+ Relocation section '.klp.rela.btrfs.text.btrfs_feature_attr_show' at offset 0x2ba0 contains 4 entries:
+ Offset Info Type Symbol's Value Symbol's Name + Addend
+ 000000000000001f 0000005e00000002 R_X86_64_PC32 0000000000000000 .klp.sym.vmlinux.printk,0 - 4
+
+ This rela refers to the symbol '.klp.sym.vmlinux.printk,0', and the symbol index is encoded
+ in 'Info'. Here its symbol index is 0x5e, which is 94 in decimal, which refers to the
+ symbol index 94.
+ And in this patch module's corresponding symbol table, symbol index 94 refers to that very symbol:
+ [ snip ]
+ 94: 0000000000000000 0 NOTYPE GLOBAL DEFAULT OS [0xff20] .klp.sym.vmlinux.printk,0
+ [ snip ]
+
+4.2 Livepatch symbol format
+===========================
+
Livepatch symbols must have their section index marked as SHN_LIVEPATCH, so
that the module loader can identify them and not attempt to resolve them.
See include/uapi/linux/elf.h for the actual definitions.
-3.3.2 Required name format
---------------------------
-Livepatch symbol names must conform to the following format:
-
-.klp.sym.objname.symbol_name,sympos
-^ ^^ ^ ^ ^ ^
-|_______||_____| |_________| |
- [A] [B] [C] [D]
-
-[A] The symbol name is prefixed with the string ".klp.sym."
-[B] The name of the object (i.e. "vmlinux" or name of module) to
- which the symbol belongs follows immediately after the prefix.
-[C] The actual name of the symbol.
-[D] The position of the symbol in the object (as according to kallsyms)
- This is used to differentiate duplicate symbols within the same
- object. The symbol position is expressed numerically (0, 1, 2...).
- The symbol position of a unique symbol is 0.
-
-3.3.3 Example livepatch symbol names:
--------------------------------------
-.klp.sym.vmlinux.snprintf,0
-.klp.sym.vmlinux.printk,0
-.klp.sym.btrfs.btrfs_ktype,0
-
-3.3.4 Example `readelf --symbols` output for a patch module:
-------------------------------------------------------------
-Symbol table '.symtab' contains 127 entries:
- Num: Value Size Type Bind Vis Ndx Name
- [ snip ]
- 73: 0000000000000000 0 NOTYPE GLOBAL DEFAULT OS [0xff20] .klp.sym.vmlinux.snprintf,0
- 74: 0000000000000000 0 NOTYPE GLOBAL DEFAULT OS [0xff20] .klp.sym.vmlinux.capable,0
- 75: 0000000000000000 0 NOTYPE GLOBAL DEFAULT OS [0xff20] .klp.sym.vmlinux.find_next_bit,0
- 76: 0000000000000000 0 NOTYPE GLOBAL DEFAULT OS [0xff20] .klp.sym.vmlinux.si_swapinfo,0
- [ snip ] ^
- |
- [*]
-[*] Note that the 'Ndx' (Section index) for these symbols is SHN_LIVEPATCH (0xff20).
- "OS" means OS-specific.
-
----------------------------------
-4. Architecture-specific sections
----------------------------------
+Livepatch symbol names must conform to the following format::
+
+ .klp.sym.objname.symbol_name,sympos
+ ^ ^^ ^ ^ ^ ^
+ |_______||_____| |_________| |
+ [A] [B] [C] [D]
+
+[A]
+ The symbol name is prefixed with the string ".klp.sym."
+
+[B]
+ The name of the object (i.e. "vmlinux" or name of module) to
+ which the symbol belongs follows immediately after the prefix.
+
+[C]
+ The actual name of the symbol.
+
+[D]
+ The position of the symbol in the object (as according to kallsyms)
+ This is used to differentiate duplicate symbols within the same
+ object. The symbol position is expressed numerically (0, 1, 2...).
+ The symbol position of a unique symbol is 0.
+
+Examples:
+---------
+
+**Livepatch symbol names:**
+
+::
+
+ .klp.sym.vmlinux.snprintf,0
+ .klp.sym.vmlinux.printk,0
+ .klp.sym.btrfs.btrfs_ktype,0
+
+**`readelf --symbols` output for a patch module:**
+
+::
+
+ Symbol table '.symtab' contains 127 entries:
+ Num: Value Size Type Bind Vis Ndx Name
+ [ snip ]
+ 73: 0000000000000000 0 NOTYPE GLOBAL DEFAULT OS [0xff20] .klp.sym.vmlinux.snprintf,0
+ 74: 0000000000000000 0 NOTYPE GLOBAL DEFAULT OS [0xff20] .klp.sym.vmlinux.capable,0
+ 75: 0000000000000000 0 NOTYPE GLOBAL DEFAULT OS [0xff20] .klp.sym.vmlinux.find_next_bit,0
+ 76: 0000000000000000 0 NOTYPE GLOBAL DEFAULT OS [0xff20] .klp.sym.vmlinux.si_swapinfo,0
+ [ snip ] ^
+ |
+ [*]
+
+[*]
+ Note that the 'Ndx' (Section index) for these symbols is SHN_LIVEPATCH (0xff20).
+ "OS" means OS-specific.
+
+5. Architecture-specific sections
+=================================
Architectures may override arch_klp_init_object_loaded() to perform
additional arch-specific tasks when a target module loads, such as applying
arch-specific sections. On x86 for example, we must apply per-object
@@ -304,20 +308,19 @@ These sections must be prefixed with ".klp.arch.$objname." so that they can
be easily identified when iterating through a patch module's Elf sections
(See arch/x86/kernel/livepatch.c for a complete example).
---------------------------------------
-5. Symbol table and Elf section access
---------------------------------------
+6. Symbol table and Elf section access
+======================================
A livepatch module's symbol table is accessible through module->symtab.
Since apply_relocate_add() requires access to a module's section headers,
symbol table, and relocation section indices, Elf information is preserved for
livepatch modules and is made accessible by the module loader through
module->klp_info, which is a klp_modinfo struct. When a livepatch module loads,
-this struct is filled in by the module loader. Its fields are documented below:
-
-struct klp_modinfo {
- Elf_Ehdr hdr; /* Elf header */
- Elf_Shdr *sechdrs; /* Section header table */
- char *secstrings; /* String table for the section headers */
- unsigned int symndx; /* The symbol table section index */
-};
+this struct is filled in by the module loader. Its fields are documented below::
+
+ struct klp_modinfo {
+ Elf_Ehdr hdr; /* Elf header */
+ Elf_Shdr *sechdrs; /* Section header table */
+ char *secstrings; /* String table for the section headers */
+ unsigned int symndx; /* The symbol table section index */
+ };
diff --git a/Documentation/livepatch/shadow-vars.txt b/Documentation/livepatch/shadow-vars.rst
similarity index 87%
rename from Documentation/livepatch/shadow-vars.txt
rename to Documentation/livepatch/shadow-vars.rst
index ecc09a7be5dd61cb52e390fde145883bf7b51848..c05715aeafa4e9c844917a8d8a1f2439d34a9c8b 100644
--- a/Documentation/livepatch/shadow-vars.txt
+++ b/Documentation/livepatch/shadow-vars.rst
@@ -27,10 +27,13 @@ A hashtable references all shadow variables. These references are
stored and retrieved through a <obj, id> pair.
* The klp_shadow variable data structure encapsulates both tracking
-meta-data and shadow-data:
+ meta-data and shadow-data:
+
- meta-data
+
- obj - pointer to parent object
- id - data identifier
+
- data[] - storage for shadow data
It is important to note that the klp_shadow_alloc() and
@@ -47,31 +50,43 @@ to do actions that can be done only once when a new variable is allocated.
* klp_shadow_alloc() - allocate and add a new shadow variable
- search hashtable for <obj, id> pair
+
- if exists
+
- WARN and return NULL
+
- if <obj, id> doesn't already exist
+
- allocate a new shadow variable
- initialize the variable using a custom constructor and data when provided
- add <obj, id> to the global hashtable
* klp_shadow_get_or_alloc() - get existing or alloc a new shadow variable
- search hashtable for <obj, id> pair
+
- if exists
+
- return existing shadow variable
+
- if <obj, id> doesn't already exist
+
- allocate a new shadow variable
- initialize the variable using a custom constructor and data when provided
- add <obj, id> pair to the global hashtable
* klp_shadow_free() - detach and free a <obj, id> shadow variable
- find and remove a <obj, id> reference from global hashtable
+
- if found
+
- call destructor function if defined
- free shadow variable
* klp_shadow_free_all() - detach and free all <*, id> shadow variables
- find and remove any <*, id> references from global hashtable
+
- if found
+
- call destructor function if defined
- free shadow variable
@@ -102,12 +117,12 @@ parent "goes live" (ie, any shadow variable get-API requests are made
for this <obj, id> pair.)
For commit 1d147bfa6429, when a parent sta_info structure is allocated,
-allocate a shadow copy of the ps_lock pointer, then initialize it:
+allocate a shadow copy of the ps_lock pointer, then initialize it::
-#define PS_LOCK 1
-struct sta_info *sta_info_alloc(struct ieee80211_sub_if_data *sdata,
- const u8 *addr, gfp_t gfp)
-{
+ #define PS_LOCK 1
+ struct sta_info *sta_info_alloc(struct ieee80211_sub_if_data *sdata,
+ const u8 *addr, gfp_t gfp)
+ {
struct sta_info *sta;
spinlock_t *ps_lock;
@@ -123,10 +138,10 @@ struct sta_info *sta_info_alloc(struct ieee80211_sub_if_data *sdata,
...
When requiring a ps_lock, query the shadow variable API to retrieve one
-for a specific struct sta_info:
+for a specific struct sta_info:::
-void ieee80211_sta_ps_deliver_wakeup(struct sta_info *sta)
-{
+ void ieee80211_sta_ps_deliver_wakeup(struct sta_info *sta)
+ {
spinlock_t *ps_lock;
/* sync with ieee80211_tx_h_unicast_ps_buf */
@@ -136,10 +151,10 @@ void ieee80211_sta_ps_deliver_wakeup(struct sta_info *sta)
...
When the parent sta_info structure is freed, first free the shadow
-variable:
+variable::
-void sta_info_free(struct ieee80211_local *local, struct sta_info *sta)
-{
+ void sta_info_free(struct ieee80211_local *local, struct sta_info *sta)
+ {
klp_shadow_free(sta, PS_LOCK, NULL);
kfree(sta);
...
@@ -155,19 +170,19 @@ these cases, the klp_shadow_get_or_alloc() call can be used to attach
shadow variables to parents already in-flight.
For commit 1d147bfa6429, a good spot to allocate a shadow spinlock is
-inside ieee80211_sta_ps_deliver_wakeup():
+inside ieee80211_sta_ps_deliver_wakeup()::
-int ps_lock_shadow_ctor(void *obj, void *shadow_data, void *ctor_data)
-{
+ int ps_lock_shadow_ctor(void *obj, void *shadow_data, void *ctor_data)
+ {
spinlock_t *lock = shadow_data;
spin_lock_init(lock);
return 0;
-}
+ }
-#define PS_LOCK 1
-void ieee80211_sta_ps_deliver_wakeup(struct sta_info *sta)
-{
+ #define PS_LOCK 1
+ void ieee80211_sta_ps_deliver_wakeup(struct sta_info *sta)
+ {
spinlock_t *ps_lock;
/* sync with ieee80211_tx_h_unicast_ps_buf */
@@ -200,10 +215,12 @@ suggests how to handle the parent object.
=============
* https://github.com/dynup/kpatch
-The livepatch implementation is based on the kpatch version of shadow
-variables.
+
+ The livepatch implementation is based on the kpatch version of shadow
+ variables.
* http://files.mkgnu.net/files/dynamos/doc/papers/dynamos_eurosys_07.pdf
-Dynamic and Adaptive Updates of Non-Quiescent Subsystems in Commodity
-Operating System Kernels (Kritis Makris, Kyung Dong Ryu 2007) presented
-a datatype update technique called "shadow data structures".
+
+ Dynamic and Adaptive Updates of Non-Quiescent Subsystems in Commodity
+ Operating System Kernels (Kritis Makris, Kyung Dong Ryu 2007) presented
+ a datatype update technique called "shadow data structures".
diff --git a/Documentation/ntb.txt b/Documentation/ntb.txt
index a043854d28dfb65932a53709b674ec79493cc2e2..074a423c853cf7f66cc96b80484a2a4c7038d698 100644
--- a/Documentation/ntb.txt
+++ b/Documentation/ntb.txt
@@ -41,9 +41,10 @@ mainly used to perform the proper memory window initialization. Typically
there are two types of memory window interfaces supported by the NTB API:
inbound translation configured on the local ntb port and outbound translation
configured by the peer, on the peer ntb port. The first type is
-depicted on the next figure
+depicted on the next figure::
+
+ Inbound translation:
-Inbound translation:
Memory: Local NTB Port: Peer NTB Port: Peer MMIO:
____________
| dma-mapped |-ntb_mw_set_trans(addr) |
@@ -58,9 +59,10 @@ maps corresponding outbound memory window so to have access to the shared
memory region.
The second type of interface, that implies the shared windows being
-initialized by a peer device, is depicted on the figure:
+initialized by a peer device, is depicted on the figure::
+
+ Outbound translation:
-Outbound translation:
Memory: Local NTB Port: Peer NTB Port: Peer MMIO:
____________ ______________
| dma-mapped | | | MW base addr |<== memory-mapped IO
@@ -75,11 +77,13 @@ outbound memory window so to have access to the shared memory region.
As one can see the described scenarios can be combined in one portable
algorithm.
+
Local device:
1) Allocate memory for a shared window
2) Initialize memory window by translated address of the allocated region
(it may fail if local memory window initialization is unsupported)
3) Send the translated address and memory window index to a peer device
+
Peer device:
1) Initialize memory window with retrieved address of the allocated
by another device memory region (it may fail if peer memory window
@@ -88,6 +92,7 @@ algorithm.
In accordance with this scenario, the NTB Memory Window API can be used as
follows:
+
Local device:
1) ntb_mw_count(pidx) - retrieve number of memory ranges, which can
be allocated for memory windows between local device and peer device
@@ -103,6 +108,7 @@ follows:
5) Send translated base address (usually together with memory window
number) to the peer device using, for instance, scratchpad or message
registers.
+
Peer device:
1) ntb_peer_mw_set_trans(pidx, midx) - try to set received from other
device (related to pidx) translated address for specified memory
diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst
index 4213e580f2739dceb147242551bda729da7443ad..855a70b802694b7bcbda64a9919930d744c78013 100644
--- a/Documentation/process/5.Posting.rst
+++ b/Documentation/process/5.Posting.rst
@@ -216,10 +216,12 @@ The tags in common use are:
which can be found in :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
Code without a proper signoff cannot be merged into the mainline.
- - Co-developed-by: states that the patch was also created by another developer
- along with the original author. This is useful at times when multiple
- people work on a single patch. Note, this person also needs to have a
- Signed-off-by: line in the patch as well.
+ - Co-developed-by: states that the patch was co-created by several developers;
+ it is a used to give attribution to co-authors (in addition to the author
+ attributed by the From: tag) when multiple people work on a single patch.
+ Every Co-developed-by: must be immediately followed by a Signed-off-by: of
+ the associated co-author. Details and examples can be found in
+ :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`.
- Acked-by: indicates an agreement by another developer (often a
maintainer of the relevant code) that the patch is appropriate for
diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
index 8ea913e99fa17d563a970ded48079e0de0d29ab3..fa864a51e6ea0dcbcfb1d74a45c25f9e6b57a5f0 100644
--- a/Documentation/process/coding-style.rst
+++ b/Documentation/process/coding-style.rst
@@ -843,7 +843,8 @@ used.
The kernel provides the following general purpose memory allocators:
kmalloc(), kzalloc(), kmalloc_array(), kcalloc(), vmalloc(), and
vzalloc(). Please refer to the API documentation for further information
-about them.
+about them. :ref:`Documentation/core-api/memory-allocation.rst
+<memory_allocation>`
The preferred form for passing a size of a struct is the following:
@@ -874,6 +875,9 @@ The preferred form for allocating a zeroed array is the following:
Both forms check for overflow on the allocation size n * sizeof(...),
and return NULL if that occurred.
+These generic allocation functions all emit a stack dump on failure when used
+without __GFP_NOWARN so there is no use in emitting an additional failure
+message when NULL is returned.
15) The inline disease
----------------------
diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst
index 0ef5a63c06badb40b5da308847adb44ef0f14776..49e0f64a3427deeec7eebf456e2549085ab378ff 100644
--- a/Documentation/process/deprecated.rst
+++ b/Documentation/process/deprecated.rst
@@ -1,5 +1,7 @@
.. SPDX-License-Identifier: GPL-2.0
+.. _deprecated:
+
=====================================================================
Deprecated Interfaces, Language Features, Attributes, and Conventions
=====================================================================
diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
index ad2b6c852b95cdbaf4d7b0046e82dc15ddfff94a..6ab75c11d2c3bd4bf4de6509a8a73354cb36694d 100644
--- a/Documentation/process/howto.rst
+++ b/Documentation/process/howto.rst
@@ -62,7 +62,7 @@ Legal Issues
The Linux kernel source code is released under the GPL. Please see the file
COPYING in the main directory of the source tree. The Linux kernel licensing
rules and how to use `SPDX <https://spdx.org/>`_ identifiers in source code are
-descibed in :ref:`Documentation/process/license-rules.rst <kernel_licensing>`.
+described in :ref:`Documentation/process/license-rules.rst <kernel_licensing>`.
If you have further questions about the license, please contact a lawyer, and do
not ask on the Linux kernel mailing list. The people on the mailing lists are
not lawyers, and you should not rely on their statements on legal matters.
diff --git a/Documentation/process/kernel-docs.rst b/Documentation/process/kernel-docs.rst
index ab12dddc773e039207a7977a4ca423396b89b9f2..7a45a8e36ea7596c67c268977055b3728b75aff0 100644
--- a/Documentation/process/kernel-docs.rst
+++ b/Documentation/process/kernel-docs.rst
@@ -95,18 +95,6 @@ On-line docs
[...]. This paper examines some common problems for
submitting larger changes and some strategies to avoid problems.
- * Title: **Overview of the Virtual File System**
-
- :Author: Richard Gooch.
- :URL: http://www.mjmwired.net/kernel/Documentation/filesystems/vfs.txt
- :Date: 2007
- :Keywords: VFS, File System, mounting filesystems, opening files,
- dentries, dcache.
- :Description: Brief introduction to the Linux Virtual File System.
- What is it, how it works, operations taken when opening a file or
- mounting a file system and description of important data
- structures explaining the purpose of each of their entries.
-
* Title: **Linux Device Drivers, Third Edition**
:Author: Jonathan Corbet, Alessandro Rubini, Greg Kroah-Hartman
diff --git a/Documentation/process/license-rules.rst b/Documentation/process/license-rules.rst
index 6b09033a8e9e247bba9cbfc06bf36127180fa10d..2ef44ada3f119562c2f955077c6713fab599535f 100644
--- a/Documentation/process/license-rules.rst
+++ b/Documentation/process/license-rules.rst
@@ -234,13 +234,13 @@ kernel, can be broken down into:
|
-2. Not recommended licenses:
+2. Deprecated licenses:
These licenses should only be used for existing code or for importing
code from a different project. These licenses are available from the
directory::
- LICENSES/other/
+ LICENSES/deprecated/
in the kernel source tree.
@@ -250,14 +250,14 @@ kernel, can be broken down into:
Examples::
- LICENSES/other/ISC
+ LICENSES/deprecated/ISC
Contains the Internet Systems Consortium license text and the required
metatags::
- LICENSES/other/ZLib
+ LICENSES/deprecated/GPL-1.0
- Contains the ZLIB license text and the required metatags.
+ Contains the GPL version 1 license text and the required metatags.
Metatags:
@@ -281,7 +281,56 @@ kernel, can be broken down into:
|
-3. _`Exceptions`:
+3. Dual Licensing Only
+
+ These licenses should only be used to dual license code with another
+ license in addition to a preferred license. These licenses are available
+ from the directory::
+
+ LICENSES/dual/
+
+ in the kernel source tree.
+
+ The files in this directory contain the full license text and
+ `Metatags`_. The file names are identical to the SPDX license
+ identifier which shall be used for the license in source files.
+
+ Examples::
+
+ LICENSES/dual/MPL-1.1
+
+ Contains the Mozilla Public License version 1.1 license text and the
+ required metatags::
+
+ LICENSES/dual/Apache-2.0
+
+ Contains the Apache License version 2.0 license text and the required
+ metatags.
+
+ Metatags:
+
+ The metatag requirements for 'other' licenses are identical to the
+ requirements of the `Preferred licenses`_.
+
+ File format example::
+
+ Valid-License-Identifier: MPL-1.1
+ SPDX-URL: https://spdx.org/licenses/MPL-1.1.html
+ Usage-Guide:
+ Do NOT use. The MPL-1.1 is not GPL2 compatible. It may only be used for
+ dual-licensed files where the other license is GPL2 compatible.
+ If you end up using this it MUST be used together with a GPL2 compatible
+ license using "OR".
+ To use the Mozilla Public License version 1.1 put the following SPDX
+ tag/value pair into a comment according to the placement guidelines in
+ the licensing rules documentation:
+ SPDX-License-Identifier: MPL-1.1
+ License-Text:
+ Full license text
+
+|
+
+4. _`Exceptions`:
Some licenses can be amended with exceptions which grant certain rights
which the original license does not. These exceptions are available
diff --git a/Documentation/process/maintainer-pgp-guide.rst b/Documentation/process/maintainer-pgp-guide.rst
index aff9b1a4d77b45ce099dfc08016a997fd2ae14b8..4bab7464ff8cd48174839aac106f9a51f7c75f29 100644
--- a/Documentation/process/maintainer-pgp-guide.rst
+++ b/Documentation/process/maintainer-pgp-guide.rst
@@ -943,7 +943,7 @@ have on your keyring::
Next, open the `PGP pathfinder`_. In the "From" field, paste the key
fingerprint of Linus Torvalds from the output above. In the "To" field,
-paste they key-id you found via ``gpg --search`` of the unknown key, and
+paste the key-id you found via ``gpg --search`` of the unknown key, and
check the results:
- `Finding paths to Linus`_
diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index be7d1829c3af99309a0999521c467dbaf95f01d8..9c4299293c7294402219a7d491b7fa50990f1cce 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -60,8 +60,8 @@ not in any lower subdirectory.
To create a patch for a single file, it is often sufficient to do::
- SRCTREE= linux
- MYFILE= drivers/net/mydriver.c
+ SRCTREE=linux
+ MYFILE=drivers/net/mydriver.c
cd $SRCTREE
cp $MYFILE $MYFILE.orig
@@ -73,7 +73,7 @@ To create a patch for multiple files, you should unpack a "vanilla",
or unmodified kernel source tree, and generate a ``diff`` against your
own source tree. For example::
- MYSRC= /devel/linux
+ MYSRC=/devel/linux
tar xvfz linux-3.19.tar.gz
mv linux-3.19 linux-3.19-vanilla
@@ -545,10 +545,40 @@ person it names - but it should indicate that this person was copied on the
patch. This tag documents that potentially interested parties
have been included in the discussion.
-A Co-developed-by: states that the patch was also created by another developer
-along with the original author. This is useful at times when multiple people
-work on a single patch. Note, this person also needs to have a Signed-off-by:
-line in the patch as well.
+Co-developed-by: states that the patch was co-created by multiple developers;
+it is a used to give attribution to co-authors (in addition to the author
+attributed by the From: tag) when several people work on a single patch. Since
+Co-developed-by: denotes authorship, every Co-developed-by: must be immediately
+followed by a Signed-off-by: of the associated co-author. Standard sign-off
+procedure applies, i.e. the ordering of Signed-off-by: tags should reflect the
+chronological history of the patch insofar as possible, regardless of whether
+the author is attributed via From: or Co-developed-by:. Notably, the last
+Signed-off-by: must always be that of the developer submitting the patch.
+
+Note, the From: tag is optional when the From: author is also the person (and
+email) listed in the From: line of the email header.
+
+Example of a patch submitted by the From: author::
+
+ <changelog>
+
+ Co-developed-by: First Co-Author <first@coauthor.example.org>
+ Signed-off-by: First Co-Author <first@coauthor.example.org>
+ Co-developed-by: Second Co-Author <second@coauthor.example.org>
+ Signed-off-by: Second Co-Author <second@coauthor.example.org>
+ Signed-off-by: From Author <from@author.example.org>
+
+Example of a patch submitted by a Co-developed-by: author::
+
+ From: From Author <from@author.example.org>
+
+ <changelog>
+
+ Co-developed-by: Random Co-Author <random@coauthor.example.org>
+ Signed-off-by: Random Co-Author <random@coauthor.example.org>
+ Signed-off-by: From Author <from@author.example.org>
+ Co-developed-by: Submitting Co-Author <sub@coauthor.example.org>
+ Signed-off-by: Submitting Co-Author <sub@coauthor.example.org>
13) Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: and Fixes:
@@ -696,7 +726,7 @@ A couple of example Subjects::
The ``from`` line must be the very first line in the message body,
and has the form:
- From: Original Author <author@example.com>
+ From: Patch Author <author@example.com>
The ``from`` line specifies who will be credited as the author of the
patch in the permanent changelog. If the ``from`` line is missing,
diff --git a/Documentation/rtc.txt b/Documentation/rtc.txt
index a129acf385373daea60eff6d9d826e8a8acc5f13..688c95b11919e780fcbe006304433f3b9936b7cd 100644
--- a/Documentation/rtc.txt
+++ b/Documentation/rtc.txt
@@ -136,5 +136,5 @@ a high functionality RTC is integrated into the SOC. That system might read
the system clock from the discrete RTC, but use the integrated one for all
other tasks, because of its greater functionality.
-Check out tools/testing/selftests/timers/rtctest.c for an example usage of the
+Check out tools/testing/selftests/rtc/rtctest.c for an example usage of the
ioctl interface.
diff --git a/Documentation/speculation.txt b/Documentation/speculation.txt
index e9e6cbae284164fd38963e3eb57ad7da3f772fb9..50d7ea857cff2102d3e58cc53c26dc309ad169d9 100644
--- a/Documentation/speculation.txt
+++ b/Documentation/speculation.txt
@@ -17,7 +17,7 @@ observed to extract secret information.
For example, in the presence of branch prediction, it is possible for bounds
checks to be ignored by code which is speculatively executed. Consider the
-following code:
+following code::
int load_array(int *array, unsigned int index)
{
@@ -27,7 +27,7 @@ following code:
return array[index];
}
-Which, on arm64, may be compiled to an assembly sequence such as:
+Which, on arm64, may be compiled to an assembly sequence such as::
CMP <index>, #MAX_ARRAY_ELEMS
B.LT less
@@ -44,7 +44,7 @@ microarchitectural state which can be subsequently measured.
More complex sequences involving multiple dependent memory accesses may
result in sensitive information being leaked. Consider the following
-code, building on the prior example:
+code, building on the prior example::
int load_dependent_arrays(int *arr1, int *arr2, int index)
{
@@ -77,7 +77,7 @@ A call to array_index_nospec(index, size) returns a sanitized index
value that is bounded to [0, size) even under cpu speculation
conditions.
-This can be used to protect the earlier load_array() example:
+This can be used to protect the earlier load_array() example::
int load_array(int *array, unsigned int index)
{
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index aa058aa7bf28b79e92fce0f141f0ec1214763262..f0c86fbb3b48dbb8042ae72bbabd8225a2e370fd 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -196,7 +196,7 @@ CAP_LAST_CAP from the kernel.
core_pattern:
core_pattern is used to specify a core dumpfile pattern name.
-. max length 128 characters; default value is "core"
+. max length 127 characters; default value is "core"
. core_pattern is used as a pattern template for the output filename;
certain string patterns (beginning with '%') are substituted with
their actual values.
diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
index 7c5e6d6ab5d17d9843d3ce4b33ee21dce280ed94..c3b9bd2fd512e64451bae4003bbc36ff92c952f8 100644
--- a/Documentation/trace/ftrace.rst
+++ b/Documentation/trace/ftrace.rst
@@ -1404,6 +1404,7 @@ trace has provided some very helpful debugging information.
If we prefer function graph output instead of function, we can set
display-graph option::
+
with echo 1 > options/display-graph
# tracer: irqsoff
diff --git a/Documentation/trace/histogram.rst b/Documentation/trace/histogram.rst
index 0ea59d45aef105f6eab311b9cc89f37f398b967a..f95d94d19c226fc01d5ebb34cdda1be658285c6f 100644
--- a/Documentation/trace/histogram.rst
+++ b/Documentation/trace/histogram.rst
@@ -2133,33 +2133,33 @@ The following commonly-used handler.action pairs are available:
the end the event that triggered the snapshot (in this case you
can verify the timestamps between the sched_waking and
sched_switch events, which should match the time displayed in the
- global maximum):
-
- # cat /sys/kernel/debug/tracing/snapshot
-
- <...>-2103 [005] d..3 309.873125: sched_switch: prev_comm=cyclictest prev_pid=2103 prev_prio=19 prev_state=D ==> next_comm=swapper/5 next_pid=0 next_prio=120
- <idle>-0 [005] d.h3 309.873611: sched_waking: comm=cyclictest pid=2102 prio=19 target_cpu=005
- <idle>-0 [005] dNh4 309.873613: sched_wakeup: comm=cyclictest pid=2102 prio=19 target_cpu=005
- <idle>-0 [005] d..3 309.873616: sched_switch: prev_comm=swapper/5 prev_pid=0 prev_prio=120 prev_state=S ==> next_comm=cyclictest next_pid=2102 next_prio=19
- <...>-2102 [005] d..3 309.873625: sched_switch: prev_comm=cyclictest prev_pid=2102 prev_prio=19 prev_state=D ==> next_comm=swapper/5 next_pid=0 next_prio=120
- <idle>-0 [005] d.h3 309.874624: sched_waking: comm=cyclictest pid=2102 prio=19 target_cpu=005
- <idle>-0 [005] dNh4 309.874626: sched_wakeup: comm=cyclictest pid=2102 prio=19 target_cpu=005
- <idle>-0 [005] dNh3 309.874628: sched_waking: comm=cyclictest pid=2103 prio=19 target_cpu=005
- <idle>-0 [005] dNh4 309.874630: sched_wakeup: comm=cyclictest pid=2103 prio=19 target_cpu=005
- <idle>-0 [005] d..3 309.874633: sched_switch: prev_comm=swapper/5 prev_pid=0 prev_prio=120 prev_state=S ==> next_comm=cyclictest next_pid=2102 next_prio=19
- <idle>-0 [004] d.h3 309.874757: sched_waking: comm=gnome-terminal- pid=1699 prio=120 target_cpu=004
- <idle>-0 [004] dNh4 309.874762: sched_wakeup: comm=gnome-terminal- pid=1699 prio=120 target_cpu=004
- <idle>-0 [004] d..3 309.874766: sched_switch: prev_comm=swapper/4 prev_pid=0 prev_prio=120 prev_state=S ==> next_comm=gnome-terminal- next_pid=1699 next_prio=120
- gnome-terminal--1699 [004] d.h2 309.874941: sched_stat_runtime: comm=gnome-terminal- pid=1699 runtime=180706 [ns] vruntime=1126870572 [ns]
- <idle>-0 [003] d.s4 309.874956: sched_waking: comm=rcu_sched pid=9 prio=120 target_cpu=007
- <idle>-0 [003] d.s5 309.874960: sched_wake_idle_without_ipi: cpu=7
- <idle>-0 [003] d.s5 309.874961: sched_wakeup: comm=rcu_sched pid=9 prio=120 target_cpu=007
- <idle>-0 [007] d..3 309.874963: sched_switch: prev_comm=swapper/7 prev_pid=0 prev_prio=120 prev_state=S ==> next_comm=rcu_sched next_pid=9 next_prio=120
- rcu_sched-9 [007] d..3 309.874973: sched_stat_runtime: comm=rcu_sched pid=9 runtime=13646 [ns] vruntime=22531430286 [ns]
- rcu_sched-9 [007] d..3 309.874978: sched_switch: prev_comm=rcu_sched prev_pid=9 prev_prio=120 prev_state=R+ ==> next_comm=swapper/7 next_pid=0 next_prio=120
- <...>-2102 [005] d..4 309.874994: sched_migrate_task: comm=cyclictest pid=2103 prio=19 orig_cpu=5 dest_cpu=1
- <...>-2102 [005] d..4 309.875185: sched_wake_idle_without_ipi: cpu=1
- <idle>-0 [001] d..3 309.875200: sched_switch: prev_comm=swapper/1 prev_pid=0 prev_prio=120 prev_state=S ==> next_comm=cyclictest next_pid=2103 next_prio=19
+ global maximum)::
+
+ # cat /sys/kernel/debug/tracing/snapshot
+
+ <...>-2103 [005] d..3 309.873125: sched_switch: prev_comm=cyclictest prev_pid=2103 prev_prio=19 prev_state=D ==> next_comm=swapper/5 next_pid=0 next_prio=120
+ <idle>-0 [005] d.h3 309.873611: sched_waking: comm=cyclictest pid=2102 prio=19 target_cpu=005
+ <idle>-0 [005] dNh4 309.873613: sched_wakeup: comm=cyclictest pid=2102 prio=19 target_cpu=005
+ <idle>-0 [005] d..3 309.873616: sched_switch: prev_comm=swapper/5 prev_pid=0 prev_prio=120 prev_state=S ==> next_comm=cyclictest next_pid=2102 next_prio=19
+ <...>-2102 [005] d..3 309.873625: sched_switch: prev_comm=cyclictest prev_pid=2102 prev_prio=19 prev_state=D ==> next_comm=swapper/5 next_pid=0 next_prio=120
+ <idle>-0 [005] d.h3 309.874624: sched_waking: comm=cyclictest pid=2102 prio=19 target_cpu=005
+ <idle>-0 [005] dNh4 309.874626: sched_wakeup: comm=cyclictest pid=2102 prio=19 target_cpu=005
+ <idle>-0 [005] dNh3 309.874628: sched_waking: comm=cyclictest pid=2103 prio=19 target_cpu=005
+ <idle>-0 [005] dNh4 309.874630: sched_wakeup: comm=cyclictest pid=2103 prio=19 target_cpu=005
+ <idle>-0 [005] d..3 309.874633: sched_switch: prev_comm=swapper/5 prev_pid=0 prev_prio=120 prev_state=S ==> next_comm=cyclictest next_pid=2102 next_prio=19
+ <idle>-0 [004] d.h3 309.874757: sched_waking: comm=gnome-terminal- pid=1699 prio=120 target_cpu=004
+ <idle>-0 [004] dNh4 309.874762: sched_wakeup: comm=gnome-terminal- pid=1699 prio=120 target_cpu=004
+ <idle>-0 [004] d..3 309.874766: sched_switch: prev_comm=swapper/4 prev_pid=0 prev_prio=120 prev_state=S ==> next_comm=gnome-terminal- next_pid=1699 next_prio=120
+ gnome-terminal--1699 [004] d.h2 309.874941: sched_stat_runtime: comm=gnome-terminal- pid=1699 runtime=180706 [ns] vruntime=1126870572 [ns]
+ <idle>-0 [003] d.s4 309.874956: sched_waking: comm=rcu_sched pid=9 prio=120 target_cpu=007
+ <idle>-0 [003] d.s5 309.874960: sched_wake_idle_without_ipi: cpu=7
+ <idle>-0 [003] d.s5 309.874961: sched_wakeup: comm=rcu_sched pid=9 prio=120 target_cpu=007
+ <idle>-0 [007] d..3 309.874963: sched_switch: prev_comm=swapper/7 prev_pid=0 prev_prio=120 prev_state=S ==> next_comm=rcu_sched next_pid=9 next_prio=120
+ rcu_sched-9 [007] d..3 309.874973: sched_stat_runtime: comm=rcu_sched pid=9 runtime=13646 [ns] vruntime=22531430286 [ns]
+ rcu_sched-9 [007] d..3 309.874978: sched_switch: prev_comm=rcu_sched prev_pid=9 prev_prio=120 prev_state=R+ ==> next_comm=swapper/7 next_pid=0 next_prio=120
+ <...>-2102 [005] d..4 309.874994: sched_migrate_task: comm=cyclictest pid=2103 prio=19 orig_cpu=5 dest_cpu=1
+ <...>-2102 [005] d..4 309.875185: sched_wake_idle_without_ipi: cpu=1
+ <idle>-0 [001] d..3 309.875200: sched_switch: prev_comm=swapper/1 prev_pid=0 prev_prio=120 prev_state=S ==> next_comm=cyclictest next_pid=2103 next_prio=19
- onchange(var).save(field,.. .)
@@ -2213,9 +2213,10 @@ The following commonly-used handler.action pairs are available:
following the rest of the fields.
If a snaphot was taken, there is also a message indicating that,
- along with the value and event that triggered the snapshot:
+ along with the value and event that triggered the snapshot::
+
+ # cat /sys/kernel/debug/tracing/events/tcp/tcp_probe/hist
- # cat /sys/kernel/debug/tracing/events/tcp/tcp_probe/hist
{ dport: 1521 } hitcount: 8
changed: 10 snd_wnd: 35456 srtt: 154262 rcv_wnd: 42112
@@ -2228,14 +2229,15 @@ The following commonly-used handler.action pairs are available:
{ dport: 443 } hitcount: 211
changed: 10 snd_wnd: 26960 srtt: 17379 rcv_wnd: 28800
- Snapshot taken (see tracing/snapshot). Details:
+ Snapshot taken (see tracing/snapshot). Details::
+
triggering value { onchange($cwnd) }: 10
triggered by event with key: { dport: 80 }
- Totals:
- Hits: 414
- Entries: 4
- Dropped: 0
+ Totals:
+ Hits: 414
+ Entries: 4
+ Dropped: 0
In the above case, the event that triggered the snapshot has the
key with dport == 80. If you look at the bucket that has 80 as
@@ -2245,18 +2247,18 @@ The following commonly-used handler.action pairs are available:
the global snapshot).
And finally, looking at the snapshot data should show at or near
- the end the event that triggered the snapshot:
-
- # cat /sys/kernel/debug/tracing/snapshot
-
- gnome-shell-1261 [006] dN.3 49.823113: sched_stat_runtime: comm=gnome-shell pid=1261 runtime=49347 [ns] vruntime=1835730389 [ns]
- kworker/u16:4-773 [003] d..3 49.823114: sched_switch: prev_comm=kworker/u16:4 prev_pid=773 prev_prio=120 prev_state=R+ ==> next_comm=kworker/3:2 next_pid=135 next_prio=120
- gnome-shell-1261 [006] d..3 49.823114: sched_switch: prev_comm=gnome-shell prev_pid=1261 prev_prio=120 prev_state=R+ ==> next_comm=kworker/6:2 next_pid=387 next_prio=120
- kworker/3:2-135 [003] d..3 49.823118: sched_stat_runtime: comm=kworker/3:2 pid=135 runtime=5339 [ns] vruntime=17815800388 [ns]
- kworker/6:2-387 [006] d..3 49.823120: sched_stat_runtime: comm=kworker/6:2 pid=387 runtime=9594 [ns] vruntime=14589605367 [ns]
- kworker/6:2-387 [006] d..3 49.823122: sched_switch: prev_comm=kworker/6:2 prev_pid=387 prev_prio=120 prev_state=R+ ==> next_comm=gnome-shell next_pid=1261 next_prio=120
- kworker/3:2-135 [003] d..3 49.823123: sched_switch: prev_comm=kworker/3:2 prev_pid=135 prev_prio=120 prev_state=T ==> next_comm=swapper/3 next_pid=0 next_prio=120
- <idle>-0 [004] ..s7 49.823798: tcp_probe: src=10.0.0.10:54326 dest=23.215.104.193:80 mark=0x0 length=32 snd_nxt=0xe3ae2ff5 snd_una=0xe3ae2ecd snd_cwnd=10 ssthresh=2147483647 snd_wnd=28960 srtt=19604 rcv_wnd=29312
+ the end the event that triggered the snapshot::
+
+ # cat /sys/kernel/debug/tracing/snapshot
+
+ gnome-shell-1261 [006] dN.3 49.823113: sched_stat_runtime: comm=gnome-shell pid=1261 runtime=49347 [ns] vruntime=1835730389 [ns]
+ kworker/u16:4-773 [003] d..3 49.823114: sched_switch: prev_comm=kworker/u16:4 prev_pid=773 prev_prio=120 prev_state=R+ ==> next_comm=kworker/3:2 next_pid=135 next_prio=120
+ gnome-shell-1261 [006] d..3 49.823114: sched_switch: prev_comm=gnome-shell prev_pid=1261 prev_prio=120 prev_state=R+ ==> next_comm=kworker/6:2 next_pid=387 next_prio=120
+ kworker/3:2-135 [003] d..3 49.823118: sched_stat_runtime: comm=kworker/3:2 pid=135 runtime=5339 [ns] vruntime=17815800388 [ns]
+ kworker/6:2-387 [006] d..3 49.823120: sched_stat_runtime: comm=kworker/6:2 pid=387 runtime=9594 [ns] vruntime=14589605367 [ns]
+ kworker/6:2-387 [006] d..3 49.823122: sched_switch: prev_comm=kworker/6:2 prev_pid=387 prev_prio=120 prev_state=R+ ==> next_comm=gnome-shell next_pid=1261 next_prio=120
+ kworker/3:2-135 [003] d..3 49.823123: sched_switch: prev_comm=kworker/3:2 prev_pid=135 prev_prio=120 prev_state=T ==> next_comm=swapper/3 next_pid=0 next_prio=120
+ <idle>-0 [004] ..s7 49.823798: tcp_probe: src=10.0.0.10:54326 dest=23.215.104.193:80 mark=0x0 length=32 snd_nxt=0xe3ae2ff5 snd_una=0xe3ae2ecd snd_cwnd=10 ssthresh=2147483647 snd_wnd=28960 srtt=19604 rcv_wnd=29312
3. User space creating a trigger
--------------------------------
diff --git a/Documentation/translations/index.rst b/Documentation/translations/index.rst
index 7f77c52d33aa647647becfcdf827aa7db5c0b2c4..e446e5ed00a6af8e2a2c82f3217c8c06b888a78a 100644
--- a/Documentation/translations/index.rst
+++ b/Documentation/translations/index.rst
@@ -11,3 +11,43 @@ Translations
it_IT/index
ko_KR/index
ja_JP/index
+
+
+.. _translations_disclaimer:
+
+Disclaimer
+----------
+
+Translation's purpose is to ease reading and understanding in languages other
+than English. Its aim is to help people who do not understand English or have
+doubts about its interpretation. Additionally, some people prefer to read
+documentation in their native language, but please bear in mind that the
+*only* official documentation is the English one: :ref:`linux_doc`.
+
+It is very unlikely that an update to :ref:`linux_doc` will be propagated
+immediately to all translations. Translations' maintainers - and
+contributors - follow the evolution of the official documentation and they
+maintain translations aligned as much as they can. For this reason there is
+no guarantee that a translation is up to date. If what you read in a
+translation does not sound right compared to what you read in the code, please
+inform the translation maintainer and - if you can - check also the English
+documentation.
+
+A translation is not a fork of the official documentation, therefore
+translations' users should not find information that differs from the official
+English documentation. Any content addition, removal or update, must be
+applied to the English documents first. Afterwards and when possible, the
+same change should be applied to translations. Translations' maintainers
+accept only contributions that are merely translation related (e.g. new
+translations, updates, fixes).
+
+Translations try to be as accurate as possible but it is not possible to map
+one language directly to all other languages. Each language has its own
+grammar and culture, so the translation of an English statement may need to be
+adapted to fit a different language. For this reason, when viewing
+translations, you may find slight differences that carry the same message but
+in a different form.
+
+If you need to communicate with the Linux community but you do not feel
+comfortable writing in English, you can ask the translation's maintainers
+for help.
diff --git a/Documentation/translations/it_IT/core-api/memory-allocation.rst b/Documentation/translations/it_IT/core-api/memory-allocation.rst
new file mode 100644
index 0000000000000000000000000000000000000000..11d5148f8d6b95888724277cdefb80b23d922b98
--- /dev/null
+++ b/Documentation/translations/it_IT/core-api/memory-allocation.rst
@@ -0,0 +1,13 @@
+.. include:: ../disclaimer-ita.rst
+
+:Original: :ref:`Documentation/core-api/memory-allocation.rst <memory_allocation>`
+
+.. _it_memory_allocation:
+
+================================
+Guida all'allocazione di memoria
+================================
+
+.. warning::
+
+ TODO ancora da tradurre
diff --git a/Documentation/translations/it_IT/disclaimer-ita.rst b/Documentation/translations/it_IT/disclaimer-ita.rst
index d68e52de6a5d9d5528a1e5200d02062e8cee175b..bfe8a384baed96c48795ffb913df0dd8a1445969 100644
--- a/Documentation/translations/it_IT/disclaimer-ita.rst
+++ b/Documentation/translations/it_IT/disclaimer-ita.rst
@@ -1,13 +1,6 @@
:orphan:
-.. note::
- This document is maintained by Federico Vaga <federico.vaga@vaga.pv.it>.
- If you find any difference between this document and the original file or a
- problem with the translation, please contact the maintainer of this file.
- Following people helped to translate or review:
- Alessia Mantegazza <amantegazza@vaga.pv.it>
-
.. warning::
- The purpose of this file is to be easier to read and understand for Italian
- speakers and is not intended as a fork. So, if you have any comments or
- updates for this file please try to update the original English file first.
+ In caso di dubbi sulla correttezza del contenuto di questa traduzione,
+ l'unico riferimento valido è la documentazione ufficiale in inglese.
+ Per maggiori informazioni consultate le :ref:`avvertenze <it_disclaimer>`.
diff --git a/Documentation/translations/it_IT/doc-guide/index.rst b/Documentation/translations/it_IT/doc-guide/index.rst
index 7a6562b547eecde360658cf020ca2fac6d9384f5..9fffff626711729d0b20e267b9b7bddf5c2fd402 100644
--- a/Documentation/translations/it_IT/doc-guide/index.rst
+++ b/Documentation/translations/it_IT/doc-guide/index.rst
@@ -12,9 +12,9 @@ Come scrivere la documentazione del kernel
.. toctree::
:maxdepth: 1
- sphinx.rst
- kernel-doc.rst
- parse-headers.rst
+ sphinx
+ kernel-doc
+ parse-headers
.. only:: subproject and html
diff --git a/Documentation/translations/it_IT/index.rst b/Documentation/translations/it_IT/index.rst
index ea9b2916b3e40e8ede45a1e84a5e3cfcec806274..409eaac03e9febe99a3c9621cdd5030a18e80693 100644
--- a/Documentation/translations/it_IT/index.rst
+++ b/Documentation/translations/it_IT/index.rst
@@ -4,26 +4,49 @@
Traduzione italiana
===================
-L'obiettivo di questa traduzione è di rendere più facile la lettura e
-la comprensione per chi preferisce leggere in lingua italiana.
-Tenete presente che la documentazione di riferimento rimane comunque
-quella in lingua inglese: :ref:`linux_doc`
-
-Questa traduzione cerca di essere il più fedele possibile all'originale ma
-è ovvio che alcune frasi vadano trasformate: non aspettatevi una traduzione
-letterale. Quando possibile, si eviteranno gli inglesismi ed al loro posto
-verranno utilizzate le corrispettive parole italiane.
+:manutentore: Federico Vaga <federico.vaga@vaga.pv.it>
-Se notate che la traduzione non è più aggiornata potete contattare
-direttamente il manutentore della traduzione italiana.
+.. _it_disclaimer:
-Se notate che la documentazione contiene errori o dimenticanze, allora
-verificate la documentazione di riferimento in lingua inglese. Se il problema
-è presente anche nella documentazione di riferimento, contattate il suo
-manutentore. Se avete problemi a scrivere in inglese, potete comunque
-riportare il problema al manutentore della traduzione italiana.
+Avvertenze
+==========
-Manutentore della traduzione italiana: Federico Vaga <federico.vaga@vaga.pv.it>
+L'obiettivo di questa traduzione è di rendere più facile la lettura e
+la comprensione per chi non capisce l'inglese o ha dubbi sulla sua
+interpretazione, oppure semplicemente per chi preferisce leggere in lingua
+italiana. Tuttavia, tenete ben presente che l'*unica* documentazione
+ufficiale è quella in lingua inglese: :ref:`linux_doc`
+
+La propagazione simultanea a tutte le traduzioni di una modifica in
+:ref:`linux_doc` è altamente improbabile. I manutentori delle traduzioni -
+e i contributori - seguono l'evolversi della documentazione ufficiale e
+cercano di mantenere le rispettive traduzioni allineate nel limite del
+possibile. Per questo motivo non c'è garanzia che una traduzione sia
+aggiornata all'ultima modifica. Se quello che leggete in una traduzione
+non corrisponde a quello che leggete nel codice, informate il manutentore
+della traduzione e - se potete - verificate anche la documentazione in
+inglese.
+
+Una traduzione non è un *fork* della documentazione ufficiale, perciò gli
+utenti non vi troveranno alcuna informazione diversa rispetto alla versione
+ufficiale. Ogni aggiunta, rimozione o modifica dei contenuti deve essere
+fatta prima nei documenti in inglese. In seguito, e quando è possibile, la
+stessa modifica dovrebbe essere applicata anche alle traduzioni. I manutentori
+delle traduzioni accettano contributi che interessano prettamente l'attivitÃ
+di traduzione (per esempio, nuove traduzioni, aggiornamenti, correzioni).
+
+Le traduzioni cercano di essere il più possibile accurate ma non è possibile
+mappare direttamente una lingua in un'altra. Ogni lingua ha la sua grammatica
+e una sua cultura alle spalle, quindi la traduzione di una frase in inglese
+potrebbe essere modificata per adattarla all'italiano. Per questo motivo,
+quando leggete questa traduzione, potreste trovare alcune differenze di forma
+ma che trasmettono comunque il messaggio originale. Nonostante la grande
+diffusione di inglesismi nella lingua parlata, quando possibile, questi
+verranno sostituiti dalle corrispettive parole italiane
+
+Se avete bisogno d'aiuto per comunicare con la comunità Linux ma non vi sentite
+a vostro agio nello scrivere in inglese, potete chiedere aiuto al manutentore
+della traduzione.
La documentazione del kernel Linux
==================================
@@ -47,9 +70,7 @@ I seguenti documenti descrivono la licenza usata nei sorgenti del kernel Linux
(GPLv2), come licenziare i singoli file; inoltre troverete i riferimenti al
testo integrale della licenza.
-.. warning::
-
- TODO ancora da tradurre
+* :ref:`it_kernel_licensing`
Documentazione per gli utenti
-----------------------------
@@ -90,10 +111,6 @@ vostre modifiche molto più semplice
doc-guide/index
kernel-hacking/index
-.. warning::
-
- TODO ancora da tradurre
-
Documentazione della API del kernel
-----------------------------------
diff --git a/Documentation/translations/it_IT/networking/netdev-FAQ.rst b/Documentation/translations/it_IT/networking/netdev-FAQ.rst
new file mode 100644
index 0000000000000000000000000000000000000000..8489ead7cff1a4223e1f521a0a7256b79e29de7e
--- /dev/null
+++ b/Documentation/translations/it_IT/networking/netdev-FAQ.rst
@@ -0,0 +1,13 @@
+.. include:: ../disclaimer-ita.rst
+
+:Original: :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
+
+.. _it_netdev-FAQ:
+
+==========
+netdev FAQ
+==========
+
+.. warning::
+
+ TODO ancora da tradurre
diff --git a/Documentation/translations/it_IT/process/5.Posting.rst b/Documentation/translations/it_IT/process/5.Posting.rst
index b979266aa8840713a3275b84487a78a8afbed991..1476d51eb5e53639b492b5b6c815d9621c869cc7 100644
--- a/Documentation/translations/it_IT/process/5.Posting.rst
+++ b/Documentation/translations/it_IT/process/5.Posting.rst
@@ -233,10 +233,12 @@ Le etichette in uso più comuni sono:
:ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`.
Codice che non presenta una firma appropriata non potrà essere integrato.
- - Co-developed-by: indica che la patch è stata sviluppata anche da un altro
- sviluppatore assieme all'autore originale. Questo è utile quando più
- persone lavorano sulla stessa patch. Da notare che questa persona deve
- avere anche una riga "Signed-off-by:" nella patch.
+ - Co-developed-by: indica che la patch è stata cosviluppata da diversi
+ sviluppatori; viene usato per assegnare più autori (in aggiunta a quello
+ associato all'etichetta From:) quando più persone lavorano ad una patch.
+ Ogni Co-developed-by: dev'essere seguito immediatamente da un Signed-off-by:
+ del corrispondente coautore. Maggiori dettagli ed esempi sono disponibili
+ in :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`.
- Acked-by: indica il consenso di un altro sviluppatore (spesso il manutentore
del codice in oggetto) all'integrazione della patch nel kernel.
diff --git a/Documentation/translations/it_IT/process/coding-style.rst b/Documentation/translations/it_IT/process/coding-style.rst
index 2fd0e7f79d551d5d40a097bc751fc663a4e32248..5ef534c95e69e8814b3d813713945b11202a868d 100644
--- a/Documentation/translations/it_IT/process/coding-style.rst
+++ b/Documentation/translations/it_IT/process/coding-style.rst
@@ -859,7 +859,8 @@ racchiusa in #ifdef, potete usare printk(KERN_DEBUG ...).
Il kernel fornisce i seguenti assegnatori ad uso generico:
kmalloc(), kzalloc(), kmalloc_array(), kcalloc(), vmalloc(), e vzalloc().
-Per maggiori informazioni, consultate la documentazione dell'API.
+Per maggiori informazioni, consultate la documentazione dell'API:
+:ref:`Documentation/translations/it_IT/core-api/memory-allocation.rst <it_memory_allocation>`
Il modo preferito per passare la dimensione di una struttura è il seguente:
@@ -890,6 +891,11 @@ Il modo preferito per assegnare un vettore a zero è il seguente:
Entrambe verificano la condizione di overflow per la dimensione
d'assegnamento n * sizeof(...), se accade ritorneranno NULL.
+Questi allocatori generici producono uno *stack dump* in caso di fallimento
+a meno che non venga esplicitamente specificato __GFP_NOWARN. Quindi, nella
+maggior parte dei casi, è inutile stampare messaggi aggiuntivi quando uno di
+questi allocatori ritornano un puntatore NULL.
+
15) Il morbo inline
-------------------
diff --git a/Documentation/translations/it_IT/process/deprecated.rst b/Documentation/translations/it_IT/process/deprecated.rst
new file mode 100644
index 0000000000000000000000000000000000000000..776f26732a94b7ef103e64e10d3fe43b1e5bb9a2
--- /dev/null
+++ b/Documentation/translations/it_IT/process/deprecated.rst
@@ -0,0 +1,129 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../disclaimer-ita.rst
+
+:Original: :ref:`Documentation/process/deprecated.rst <deprecated>`
+:Translator: Federico Vaga <federico.vaga@vaga.pv.it>
+
+.. _it_deprecated:
+
+==============================================================================
+Interfacce deprecate, caratteristiche del linguaggio, attributi, e convenzioni
+==============================================================================
+
+In un mondo perfetto, sarebbe possibile prendere tutti gli usi di
+un'interfaccia deprecata e convertirli in quella nuova, e così sarebbe
+possibile rimuovere la vecchia interfaccia in un singolo ciclo di sviluppo.
+Tuttavia, per via delle dimensioni del kernel, la gerarchia dei manutentori e
+le tempistiche, non è sempre possibile fare questo tipo di conversione tutta
+in una volta. Questo significa che nuove istanze di una vecchia interfaccia
+potrebbero aggiungersi al kernel proprio quando si sta cercando di rimuoverle,
+aumentando così il carico di lavoro. Al fine di istruire gli sviluppatori su
+cosa è considerato deprecato (e perché), è stata create la seguente lista a cui
+fare riferimento quando qualcuno propone modifiche che usano cose deprecate.
+
+__deprecated
+------------
+Nonostante questo attributo marchi visibilmente un interfaccia come deprecata,
+`non produce più alcun avviso durante la compilazione
+<https://git.kernel.org/linus/771c035372a036f83353eef46dbb829780330234>`_
+perché uno degli obiettivi del kernel è quello di compilare senza avvisi;
+inoltre, nessuno stava agendo per rimuovere queste interfacce. Nonostante l'uso
+di `__deprecated` in un file d'intestazione sia opportuno per segnare una
+interfaccia come 'vecchia', questa non è una soluzione completa. L'interfaccia
+deve essere rimossa dal kernel, o aggiunta a questo documento per scoraggiarne
+l'uso.
+
+Calcoli codificati negli argomenti di un allocatore
+----------------------------------------------------
+Il calcolo dinamico delle dimensioni (specialmente le moltiplicazioni) non
+dovrebbero essere fatto negli argomenti di funzioni di allocazione di memoria
+(o simili) per via del rischio di overflow. Questo può portare a valori più
+piccoli di quelli che il chiamante si aspettava. L'uso di questo modo di
+allocare può portare ad un overflow della memoria di heap e altri
+malfunzionamenti. (Si fa eccezione per valori numerici per i quali il
+compilatore può generare avvisi circa un potenziale overflow. Tuttavia usare
+i valori numerici come suggerito di seguito è innocuo).
+
+Per esempio, non usate ``count * size`` come argomento::
+
+ foo = kmalloc(count * size, GFP_KERNEL);
+
+Al suo posto, si dovrebbe usare l'allocatore a due argomenti::
+
+ foo = kmalloc_array(count, size, GFP_KERNEL);
+
+Se questo tipo di allocatore non è disponibile, allora dovrebbero essere usate
+le funzioni del tipo *saturate-on-overflow*::
+
+ bar = vmalloc(array_size(count, size));
+
+Un altro tipico caso da evitare è quello di calcolare la dimensione di una
+struttura seguita da un vettore di altre strutture, come nel seguente caso::
+
+ header = kzalloc(sizeof(*header) + count * sizeof(*header->item),
+ GFP_KERNEL);
+
+Invece, usate la seguente funzione::
+
+ header = kzalloc(struct_size(header, item, count), GFP_KERNEL);
+
+Per maggiori dettagli fate riferimento a :c:func:`array_size`,
+:c:func:`array3_size`, e :c:func:`struct_size`, così come la famiglia di
+funzioni :c:func:`check_add_overflow` e :c:func:`check_mul_overflow`.
+
+simple_strtol(), simple_strtoll(), simple_strtoul(), simple_strtoull()
+----------------------------------------------------------------------
+Le funzioni :c:func:`simple_strtol`, :c:func:`simple_strtoll`,
+:c:func:`simple_strtoul`, e :c:func:`simple_strtoull` ignorano volutamente
+i possibili overflow, e questo può portare il chiamante a generare risultati
+inaspettati. Le rispettive funzioni :c:func:`kstrtol`, :c:func:`kstrtoll`,
+:c:func:`kstrtoul`, e :c:func:`kstrtoull` sono da considerarsi le corrette
+sostitute; tuttavia va notato che queste richiedono che la stringa sia
+terminata con il carattere NUL o quello di nuova riga.
+
+strcpy()
+--------
+La funzione :c:func:`strcpy` non fa controlli agli estremi del buffer
+di destinazione. Questo può portare ad un overflow oltre i limiti del
+buffer e generare svariati tipi di malfunzionamenti. Nonostante l'opzione
+`CONFIG_FORTIFY_SOURCE=y` e svariate opzioni del compilatore aiutano
+a ridurne il rischio, non c'è alcuna buona ragione per continuare ad usare
+questa funzione. La versione sicura da usare è :c:func:`strscpy`.
+
+strncpy() su stringe terminate con NUL
+--------------------------------------
+L'utilizzo di :c:func:`strncpy` non fornisce alcuna garanzia sul fatto che
+il buffer di destinazione verrà terminato con il carattere NUL. Questo
+potrebbe portare a diversi overflow di lettura o altri malfunzionamenti
+causati, appunto, dalla mancanza del terminatore. Questa estende la
+terminazione nel buffer di destinazione quando la stringa d'origine è più
+corta; questo potrebbe portare ad una penalizzazione delle prestazioni per
+chi usa solo stringe terminate. La versione sicura da usare è
+:c:func:`strscpy`. (chi usa :c:func:`strscpy` e necessita di estendere la
+terminazione con NUL deve aggiungere una chiamata a :c:func:`memset`)
+
+Se il chiamate no usa stringhe terminate con NUL, allore :c:func:`strncpy()`
+può continuare ad essere usata, ma i buffer di destinazione devono essere
+marchiati con l'attributo `__nonstring <https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html>`_
+per evitare avvisi durante la compilazione.
+
+strlcpy()
+---------
+La funzione :c:func:`strlcpy`, per prima cosa, legge interamente il buffer di
+origine, magari leggendo più di quanto verrà effettivamente copiato. Questo
+è inefficiente e può portare a overflow di lettura quando la stringa non è
+terminata con NUL. La versione sicura da usare è :c:func:`strscpy`.
+
+Vettori a dimensione variabile (VLA)
+------------------------------------
+
+Usare VLA sullo stack produce codice molto peggiore rispetto a quando si usano
+vettori a dimensione fissa. Questi `problemi di prestazioni <https://git.kernel.org/linus/02361bc77888>`_,
+tutt'altro che banali, sono già un motivo valido per eliminare i VLA; in
+aggiunta sono anche un problema per la sicurezza. La crescita dinamica di un
+vettore nello stack potrebbe eccedere la memoria rimanente in tale segmento.
+Questo può portare a dei malfunzionamenti, potrebbe sovrascrivere
+dati importanti alla fine dello stack (quando il kernel è compilato senza
+`CONFIG_THREAD_INFO_IN_TASK=y`), o sovrascrivere un pezzo di memoria adiacente
+allo stack (quando il kernel è compilato senza `CONFIG_VMAP_STACK=y`).
diff --git a/Documentation/translations/it_IT/process/kernel-enforcement-statement.rst b/Documentation/translations/it_IT/process/kernel-enforcement-statement.rst
index 4ddf5a35b270830f58f713c762ca4bfc069716e5..1f62da622e26415e11d53d1ccd6988fdb9f3ac72 100644
--- a/Documentation/translations/it_IT/process/kernel-enforcement-statement.rst
+++ b/Documentation/translations/it_IT/process/kernel-enforcement-statement.rst
@@ -1,13 +1,175 @@
.. include:: ../disclaimer-ita.rst
:Original: :ref:`Documentation/process/kernel-enforcement-statement.rst <process_statement_kernel>`
-
+:Translator: Federico Vaga <federico.vaga@vaga.pv.it>
.. _it_process_statement_kernel:
Applicazione della licenza sul kernel Linux
===========================================
-.. warning::
+Come sviluppatori del kernel Linux, abbiamo un certo interessa su come il
+nostro software viene usato e su come la sua licenza viene fatta rispettare.
+Il rispetto reciproco degli obblighi di condivisione della GPL-2.0 è
+fondamentale per la sostenibilità di lungo periodo del nostro software e
+della nostra comunità .
+
+Benché ognuno abbia il diritto a far rispettare il diritto d'autore per i
+propri contributi alla nostra comunità , condividiamo l'interesse a far si che
+ogni azione individuale nel far rispettare i propri diritti sia condotta in
+modo da portare beneficio alla comunità e che non abbia, involontariamente,
+impatti negativi sulla salute e la crescita del nostro ecosistema software.
+Al fine di scoraggiare l'esecuzione di azioni inutili, concordiamo che è nel
+migliore interesse della nostra comunità di sviluppo di impegnarci nel
+rispettare i seguenti obblighi nei confronti degli utenti del kernel Linux
+per conto nostro e di qualsiasi successore ai nostri interessi sul diritto
+d'autore:
+
+ Malgrado le clausole di risoluzione della licenza GPL-2.0, abbiamo
+ concordato che è nel migliore interesse della nostra comunità di sviluppo
+ adottare le seguenti disposizioni della GPL-3.0 come permessi aggiuntivi
+ alla nostra licenza nei confronti di qualsiasi affermazione non difensiva
+ di diritti sulla licenza.
+
+ In ogni caso, se cessano tutte le violazioni di questa Licenza, allora
+ la tua licenza da parte di un dato detentore del copyright viene
+ ripristinata (a) in via cautelativa, a meno che e fino a quando il
+ detentore del copyright non cessa esplicitamente e definitivamente
+ la tua licenza, e (b) in via permanente se il detentore del copyright
+ non ti notifica in alcun modo la violazione entro 60 giorni dalla
+ cessazione della licenza.
+
+ Inoltre, la tua licenza da parte di un dato detentore del copyright
+ viene ripristinata in maniera permanente se il detentore del copyright
+ ti notifica la violazione in maniera adeguata, se questa è la prima
+ volta che ricevi una notifica di violazione di questa Licenza (per
+ qualunque Programma) dallo stesso detentore di copyright, e se rimedi
+ alla violazione entro 30 giorni dalla data di ricezione della notifica
+ di violazione.
+
+Fornendo queste garanzie, abbiamo l'intenzione di incoraggiare l'uso del
+software. Vogliamo che le aziende e le persone usino, modifichino e
+distribuiscano a questo software. Vogliamo lavorare con gli utenti in modo
+aperto e trasparente per eliminare ogni incertezza circa le nostre aspettative
+sul rispetto o l'ottemperanza alla licenza che possa limitare l'uso del nostro
+software. Vediamo l'azione legale come ultima spiaggia, da avviare solo quando
+gli altri sforzi della comunità hanno fallito nel risolvere il problema.
+
+Per finire, una volta che un problema di non rispetto della licenza viene
+risolto, speriamo che gli utenti si sentano i benvenuti ad aggregarsi a noi
+nello sviluppo di questo progetto. Lavorando assieme, saremo più forti.
+
+Ad eccezione deve specificato, parliamo per noi stessi, e non per una qualsiasi
+azienda per la quale lavoriamo oggi, o per cui abbiamo lavorato in passato, o
+lavoreremo in futuro.
+
- TODO ancora da tradurre
+ - Laura Abbott
+ - Bjorn Andersson (Linaro)
+ - Andrea Arcangeli
+ - Neil Armstrong
+ - Jens Axboe
+ - Pablo Neira Ayuso
+ - Khalid Aziz
+ - Ralf Baechle
+ - Felipe Balbi
+ - Arnd Bergmann
+ - Ard Biesheuvel
+ - Tim Bird
+ - Paolo Bonzini
+ - Christian Borntraeger
+ - Mark Brown (Linaro)
+ - Paul Burton
+ - Javier Martinez Canillas
+ - Rob Clark
+ - Kees Cook (Google)
+ - Jonathan Corbet
+ - Dennis Dalessandro
+ - Vivien Didelot (Savoir-faire Linux)
+ - Hans de Goede
+ - Mel Gorman (SUSE)
+ - Sven Eckelmann
+ - Alex Elder (Linaro)
+ - Fabio Estevam
+ - Larry Finger
+ - Bhumika Goyal
+ - Andy Gross
+ - Juergen Gross
+ - Shawn Guo
+ - Ulf Hansson
+ - Stephen Hemminger (Microsoft)
+ - Tejun Heo
+ - Rob Herring
+ - Masami Hiramatsu
+ - Michal Hocko
+ - Simon Horman
+ - Johan Hovold (Hovold Consulting AB)
+ - Christophe JAILLET
+ - Olof Johansson
+ - Lee Jones (Linaro)
+ - Heiner Kallweit
+ - Srinivas Kandagatla
+ - Jan Kara
+ - Shuah Khan (Samsung)
+ - David Kershner
+ - Jaegeuk Kim
+ - Namhyung Kim
+ - Colin Ian King
+ - Jeff Kirsher
+ - Greg Kroah-Hartman (Linux Foundation)
+ - Christian König
+ - Vinod Koul
+ - Krzysztof Kozlowski
+ - Viresh Kumar
+ - Aneesh Kumar K.V
+ - Julia Lawall
+ - Doug Ledford
+ - Chuck Lever (Oracle)
+ - Daniel Lezcano
+ - Shaohua Li
+ - Xin Long
+ - Tony Luck
+ - Catalin Marinas (Arm Ltd)
+ - Mike Marshall
+ - Chris Mason
+ - Paul E. McKenney
+ - Arnaldo Carvalho de Melo
+ - David S. Miller
+ - Ingo Molnar
+ - Kuninori Morimoto
+ - Trond Myklebust
+ - Martin K. Petersen (Oracle)
+ - Borislav Petkov
+ - Jiri Pirko
+ - Josh Poimboeuf
+ - Sebastian Reichel (Collabora)
+ - Guenter Roeck
+ - Joerg Roedel
+ - Leon Romanovsky
+ - Steven Rostedt (VMware)
+ - Frank Rowand
+ - Ivan Safonov
+ - Anna Schumaker
+ - Jes Sorensen
+ - K.Y. Srinivasan
+ - David Sterba (SUSE)
+ - Heiko Stuebner
+ - Jiri Kosina (SUSE)
+ - Willy Tarreau
+ - Dmitry Torokhov
+ - Linus Torvalds
+ - Thierry Reding
+ - Rik van Riel
+ - Luis R. Rodriguez
+ - Geert Uytterhoeven (Glider bvba)
+ - Eduardo Valentin (Amazon.com)
+ - Daniel Vetter
+ - Linus Walleij
+ - Richard Weinberger
+ - Dan Williams
+ - Rafael J. Wysocki
+ - Arvind Yadav
+ - Masahiro Yamada
+ - Wei Yongjun
+ - Lv Zheng
+ - Marc Zyngier (Arm Ltd)
diff --git a/Documentation/translations/it_IT/process/license-rules.rst b/Documentation/translations/it_IT/process/license-rules.rst
new file mode 100644
index 0000000000000000000000000000000000000000..91a8794ffd79ec5c6cfb362fd08a8f382215f388
--- /dev/null
+++ b/Documentation/translations/it_IT/process/license-rules.rst
@@ -0,0 +1,452 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../disclaimer-ita.rst
+
+:Original: :ref:`Documentation/process/license-rules.rst <kernel_licensing>`
+:Translator: Federico Vaga <federico.vaga@vaga.pv.it>
+
+.. _it_kernel_licensing:
+
+Regole per licenziare il kernel Linux
+=====================================
+
+Il kernel Linux viene rilasciato sotto i termini definiti dalla seconda
+versione della licenza *GNU General Public License* (GPL-2.0), di cui una
+copia è disponibile nel file LICENSES/preferred/GPL-2.0; a questo si
+aggiunge eccezione per le chiamate di sistema come descritto in
+LICENSES/exceptions/Linux-syscall-note; tutto ciò è descritto nel file COPYING.
+
+Questo documento fornisce una descrizione su come ogni singolo file sorgente
+debba essere licenziato per far si che sia chiaro e non ambiguo. Questo non
+sostituisce la licenza del kernel.
+
+La licenza descritta nel file COPYING si applica ai sorgenti del kernel nella
+loro interezza, quindi i singoli file sorgenti possono avere diverse licenze ma
+devono essere compatibili con la GPL-2.0::
+
+ GPL-1.0+ : GNU General Public License v1.0 o successiva
+ GPL-2.0+ : GNU General Public License v2.0 o successiva
+ LGPL-2.0 : GNU Library General Public License v2
+ LGPL-2.0+ : GNU Library General Public License v2 o successiva
+ LGPL-2.1 : GNU Lesser General Public License v2.1
+ LGPL-2.1+ : GNU Lesser General Public License v2.1 o successiva
+
+A parte questo, i singolo file possono essere forniti con una doppia licenza,
+per esempio con una delle varianti compatibili della GPL e alternativamente con
+una licenza permissiva come BSD, MIT eccetera.
+
+I file d'intestazione per l'API verso lo spazio utente (UAPI) descrivono
+le interfacce usate dai programmi, e per questo sono un caso speciale.
+Secondo le note nel file COPYING, le chiamate di sistema sono un chiaro
+confine oltre il quale non si estendono i requisiti della GPL per quei
+programmi che le usano per comunicare con il kernel. Dato che i file
+d'intestazione UAPI devono poter essere inclusi nei sorgenti di un
+qualsiasi programma eseguibile sul kernel Linux, questi meritano
+un'eccezione documentata da una clausola speciale.
+
+Il modo più comune per indicare la licenza dei file sorgenti è quello di
+aggiungere il corrispondente blocco di testo come commento in testa a detto
+file. Per via della formattazione, dei refusi, eccetera, questi blocchi di
+testo sono difficili da identificare dagli strumenti usati per verificare il
+rispetto delle licenze.
+
+Un'alternativa ai blocchi di testo è data dall'uso degli identificatori
+*Software Package Data Exchange* (SPDX) in ogni file sorgente. Gli
+identificatori di licenza SPDX sono analizzabili dalle macchine e sono precisi
+simboli stenografici che identificano la licenza sotto la quale viene
+licenziato il file che lo include. Gli identificatori di licenza SPDX sono
+gestiti del gruppo di lavoro SPDX presso la Linux Foundation e sono stati
+concordati fra i soci nell'industria, gli sviluppatori di strumenti, e i
+rispettivi gruppi legali. Per maggiori informazioni, consultate
+https://spdx.org/
+
+Il kernel Linux richiede un preciso identificatore SPDX in tutti i file
+sorgenti. Gli identificatori validi verranno spiegati nella sezione
+`Identificatori di licenza`_ e sono stati copiati dalla lista ufficiale di
+licenze SPDX assieme al rispettivo testo come mostrato in
+https://spdx.org/licenses/.
+
+Sintassi degli identificatori di licenza
+----------------------------------------
+
+1. Posizionamento:
+
+ L'identificativo di licenza SPDX dev'essere posizionato come prima riga
+ possibile di un file che possa contenere commenti. Per la maggior parte
+ dei file questa è la prima riga, fanno eccezione gli script che richiedono
+ come prima riga '#!PATH_TO_INTERPRETER'. Per questi script l'identificativo
+ SPDX finisce nella seconda riga.
+
+|
+
+2. Stile:
+
+ L'identificativo di licenza SPDX viene aggiunto sotto forma di commento.
+ Lo stile del commento dipende dal tipo di file::
+
+ sorgenti C: // SPDX-License-Identifier: <SPDX License Expression>
+ intestazioni C: /* SPDX-License-Identifier: <SPDX License Expression> */
+ ASM: /* SPDX-License-Identifier: <SPDX License Expression> */
+ scripts: # SPDX-License-Identifier: <SPDX License Expression>
+ .rst: .. SPDX-License-Identifier: <SPDX License Expression>
+ .dts{i}: // SPDX-License-Identifier: <SPDX License Expression>
+
+ Se un particolare programma non dovesse riuscire a gestire lo stile
+ principale per i commenti, allora dev'essere usato il meccanismo accettato
+ dal programma. Questo è il motivo per cui si ha "/\* \*/" nei file
+ d'intestazione C. Notammo che 'ld' falliva nell'analizzare i commenti del
+ C++ nei file .lds che venivano prodotti. Oggi questo è stato corretto,
+ ma ci sono in giro ancora vecchi programmi che non sono in grado di
+ gestire lo stile dei commenti del C++.
+
+|
+
+3. Sintassi:
+
+ Una <espressione di licenza SPDX> può essere scritta usando l'identificatore
+ SPDX della licenza come indicato nella lista di licenze SPDX, oppure la
+ combinazione di due identificatori SPDX separati da "WITH" per i casi
+ eccezionali. Quando si usano più licenze l'espressione viene formata da
+ sottoespressioni separate dalle parole chiave "AND", "OR" e racchiuse fra
+ parentesi tonde "(", ")".
+
+ Gli identificativi di licenza per licenze come la [L]GPL che si avvalgono
+ dell'opzione 'o successive' si formano aggiungendo alla fine il simbolo "+"
+ per indicare l'opzione 'o successive'.::
+
+ // SPDX-License-Identifier: GPL-2.0+
+ // SPDX-License-Identifier: LGPL-2.1+
+
+ WITH dovrebbe essere usato quando sono necessarie delle modifiche alla
+ licenza. Per esempio, la UAPI del kernel linux usa l'espressione::
+
+ // SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
+ // SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note
+
+ Altri esempi di usi di WITH all'interno del kernel sono::
+
+ // SPDX-License-Identifier: GPL-2.0 WITH mif-exception
+ // SPDX-License-Identifier: GPL-2.0+ WITH GCC-exception-2.0
+
+ Le eccezioni si possono usare solo in combinazione con identificatori di
+ licenza. Gli identificatori di licenza riconosciuti sono elencati nei
+ corrispondenti file d'eccezione. Per maggiori dettagli consultate
+ `Eccezioni`_ nel capitolo `Identificatori di licenza`_
+
+ La parola chiave OR dovrebbe essere usata solo quando si usa una doppia
+ licenza e solo una dev'essere scelta. Per esempio, alcuni file dtsi sono
+ disponibili con doppia licenza::
+
+ // SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
+
+ Esempi dal kernel di espressioni per file licenziati con doppia licenza
+ sono::
+
+ // SPDX-License-Identifier: GPL-2.0 OR MIT
+ // SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+ // SPDX-License-Identifier: GPL-2.0 OR Apache-2.0
+ // SPDX-License-Identifier: GPL-2.0 OR MPL-1.1
+ // SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) OR MIT
+ // SPDX-License-Identifier: GPL-1.0+ OR BSD-3-Clause OR OpenSSL
+
+ La parola chiave AND dovrebbe essere usata quando i termini di più licenze
+ si applicano ad un file. Per esempio, quando il codice viene preso da
+ un altro progetto il quale da i permessi per aggiungerlo nel kernel ma
+ richiede che i termini originali della licenza rimangano intatti::
+
+ // SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) AND MIT
+
+ Di seguito, un altro esempio dove entrambe i termini di licenza devono
+ essere rispettati::
+
+ // SPDX-License-Identifier: GPL-1.0+ AND LGPL-2.1+
+
+Identificatori di licenza
+-------------------------
+
+Le licenze attualmente in uso, così come le licenze aggiunte al kernel, possono
+essere categorizzate in:
+
+1. _`Licenze raccomandate`:
+
+ Ovunque possibile le licenze qui indicate dovrebbero essere usate perché
+ pienamente compatibili e molto usate. Queste licenze sono disponibile nei
+ sorgenti del kernel, nella cartella::
+
+ LICENSES/preferred/
+
+ I file in questa cartella contengono il testo completo della licenza e i
+ `Metatag`_. Il nome di questi file è lo stesso usato come identificatore
+ di licenza SPDX e che deve essere usato nei file sorgenti.
+
+ Esempi::
+
+ LICENSES/preferred/GPL-2.0
+
+ Contiene il testo della seconda versione della licenza GPL e i metatag
+ necessari::
+
+ LICENSES/preferred/MIT
+
+ Contiene il testo della licenza MIT e i metatag necessari.
+
+ _`Metatag`:
+
+ I seguenti metatag devono essere presenti in un file di licenza:
+
+ - Valid-License-Identifier:
+
+ Una o più righe che dichiarano quali identificatori di licenza sono validi
+ all'interno del progetto per far riferimento alla licenza in questione.
+ Solitamente, questo è un unico identificatore valido, ma per esempio le
+ licenze che permettono l'opzione 'o successive' hanno due identificatori
+ validi.
+
+ - SPDX-URL:
+
+ L'URL della pagina SPDX che contiene informazioni aggiuntive riguardanti
+ la licenza.
+
+ - Usage-Guidance:
+
+ Testo in formato libero per dare suggerimenti agli utenti. Il testo deve
+ includere degli esempi su come usare gli identificatori di licenza SPDX
+ in un file sorgente in conformità con le linea guida in
+ `Sintassi degli identificatori di licenza`_.
+
+ - License-Text:
+
+ Tutto il testo che compare dopo questa etichetta viene trattato
+ come se fosse parte del testo originale della licenza.
+
+ Esempi::
+
+ Valid-License-Identifier: GPL-2.0
+ Valid-License-Identifier: GPL-2.0+
+ SPDX-URL: https://spdx.org/licenses/GPL-2.0.html
+ Usage-Guide:
+ To use this license in source code, put one of the following SPDX
+ tag/value pairs into a comment according to the placement
+ guidelines in the licensing rules documentation.
+ For 'GNU General Public License (GPL) version 2 only' use:
+ SPDX-License-Identifier: GPL-2.0
+ For 'GNU General Public License (GPL) version 2 or any later version' use:
+ SPDX-License-Identifier: GPL-2.0+
+ License-Text:
+ Full license text
+
+ ::
+
+ SPDX-License-Identifier: MIT
+ SPDX-URL: https://spdx.org/licenses/MIT.html
+ Usage-Guide:
+ To use this license in source code, put the following SPDX
+ tag/value pair into a comment according to the placement
+ guidelines in the licensing rules documentation.
+ SPDX-License-Identifier: MIT
+ License-Text:
+ Full license text
+
+|
+
+2. Licenze non raccomandate:
+
+ Questo tipo di licenze dovrebbero essere usate solo per codice già esistente
+ o quando si prende codice da altri progetti. Le licenze sono disponibili
+ nei sorgenti del kernel nella cartella::
+
+ LICENSES/other/
+
+ I file in questa cartella contengono il testo completo della licenza e i
+ `Metatag`_. Il nome di questi file è lo stesso usato come identificatore
+ di licenza SPDX e che deve essere usato nei file sorgenti.
+
+ Esempi::
+
+ LICENSES/other/ISC
+
+ Contiene il testo della licenza Internet System Consortium e i suoi
+ metatag::
+
+ LICENSES/other/ZLib
+
+ Contiene il testo della licenza ZLIB e i suoi metatag.
+
+ Metatag:
+
+ I metatag necessari per le 'altre' ('other') licenze sono gli stessi
+ di usati per le `Licenze raccomandate`_.
+
+ Esempio del formato del file::
+
+ Valid-License-Identifier: ISC
+ SPDX-URL: https://spdx.org/licenses/ISC.html
+ Usage-Guide:
+ Usage of this license in the kernel for new code is discouraged
+ and it should solely be used for importing code from an already
+ existing project.
+ To use this license in source code, put the following SPDX
+ tag/value pair into a comment according to the placement
+ guidelines in the licensing rules documentation.
+ SPDX-License-Identifier: ISC
+ License-Text:
+ Full license text
+
+|
+
+3. _`Eccezioni`:
+
+ Alcune licenze possono essere corrette con delle eccezioni che forniscono
+ diritti aggiuntivi. Queste eccezioni sono disponibili nei sorgenti del
+ kernel nella cartella::
+
+ LICENSES/exceptions/
+
+ I file in questa cartella contengono il testo completo dell'eccezione e i
+ `Metatag per le eccezioni`_.
+
+ Esempi::
+
+ LICENSES/exceptions/Linux-syscall-note
+
+ Contiene la descrizione dell'eccezione per le chiamate di sistema Linux
+ così come documentato nel file COPYING del kernel Linux; questo viene usato
+ per i file d'intestazione per la UAPI. Per esempio
+ /\* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note \*/::
+
+ LICENSES/exceptions/GCC-exception-2.0
+
+ Contiene la 'eccezione di linking' che permette di collegare qualsiasi
+ binario, indipendentemente dalla sua licenza, con un compilato il cui file
+ sorgente è marchiato con questa eccezione. Questo è necessario per creare
+ eseguibili dai sorgenti che non sono compatibili con la GPL.
+
+ _`Metatag per le eccezioni`:
+
+ Un file contenente un'eccezione deve avere i seguenti metatag:
+
+ - SPDX-Exception-Identifier:
+
+ Un identificatore d'eccezione che possa essere usato in combinazione con
+ un identificatore di licenza SPDX.
+
+ - SPDX-URL:
+
+ L'URL della pagina SPDX che contiene informazioni aggiuntive riguardanti
+ l'eccezione.
+
+ - SPDX-Licenses:
+
+ Una lista di licenze SPDX separate da virgola, che possono essere usate
+ con l'eccezione.
+
+ - Usage-Guidance:
+
+ Testo in formato libero per dare suggerimenti agli utenti. Il testo deve
+ includere degli esempi su come usare gli identificatori di licenza SPDX
+ in un file sorgente in conformità con le linea guida in
+ `Sintassi degli identificatori di licenza`_.
+
+ - Exception-Text:
+
+ Tutto il testo che compare dopo questa etichetta viene trattato
+ come se fosse parte del testo originale della licenza.
+
+ Esempi::
+
+ SPDX-Exception-Identifier: Linux-syscall-note
+ SPDX-URL: https://spdx.org/licenses/Linux-syscall-note.html
+ SPDX-Licenses: GPL-2.0, GPL-2.0+, GPL-1.0+, LGPL-2.0, LGPL-2.0+, LGPL-2.1, LGPL-2.1+
+ Usage-Guidance:
+ This exception is used together with one of the above SPDX-Licenses
+ to mark user-space API (uapi) header files so they can be included
+ into non GPL compliant user-space application code.
+ To use this exception add it with the keyword WITH to one of the
+ identifiers in the SPDX-Licenses tag:
+ SPDX-License-Identifier: <SPDX-License> WITH Linux-syscall-note
+ Exception-Text:
+ Full exception text
+
+ ::
+
+ SPDX-Exception-Identifier: GCC-exception-2.0
+ SPDX-URL: https://spdx.org/licenses/GCC-exception-2.0.html
+ SPDX-Licenses: GPL-2.0, GPL-2.0+
+ Usage-Guidance:
+ The "GCC Runtime Library exception 2.0" is used together with one
+ of the above SPDX-Licenses for code imported from the GCC runtime
+ library.
+ To use this exception add it with the keyword WITH to one of the
+ identifiers in the SPDX-Licenses tag:
+ SPDX-License-Identifier: <SPDX-License> WITH GCC-exception-2.0
+ Exception-Text:
+ Full exception text
+
+Per ogni identificatore di licenza SPDX e per le eccezioni dev'esserci un file
+nella sotto-cartella LICENSES. Questo è necessario per permettere agli
+strumenti di effettuare verifiche (come checkpatch.pl), per avere le licenze
+disponibili per la lettura e per estrarre i diritti dai sorgenti, così come
+raccomandato da diverse organizzazioni FOSS, per esempio l'`iniziativa FSFE
+REUSE <https://reuse.software/>`_.
+
+_`MODULE_LICENSE`
+-----------------
+
+ I moduli del kernel necessitano di un'etichetta MODULE_LICENSE(). Questa
+ etichetta non sostituisce le informazioni sulla licenza del codice sorgente
+ (SPDX-License-Identifier) né fornisce informazioni che esprimono o
+ determinano l'esatta licenza sotto la quale viene rilasciato.
+
+ Il solo scopo di questa etichetta è quello di fornire sufficienti
+ informazioni al caricatore di moduli del kernel, o agli strumenti in spazio
+ utente, per capire se il modulo è libero o proprietario.
+
+ Le stringe di licenza valide per MODULE_LICENSE() sono:
+
+ ============================= =============================================
+ "GPL" Il modulo è licenziato con la GPL versione 2.
+ Questo non fa distinzione fra GPL'2.0-only o
+ GPL-2.0-or-later. L'esatta licenza può essere
+ determinata solo leggendo i corrispondenti
+ file sorgenti.
+
+ "GPL v2" Stesso significato di "GPL". Esiste per
+ motivi storici.
+
+ "GPL and additional rights" Questa è una variante che esiste per motivi
+ storici che indica che i sorgenti di un
+ modulo sono rilasciati sotto una variante
+ della licenza GPL v2 e quella MIT. Per favore
+ non utilizzatela per codice nuovo.
+
+ "Dual MIT/GPL" Questo è il modo corretto per esprimere il
+ il fatto che il modulo è rilasciato con
+ doppia licenza a scelta fra: una variante
+ della GPL v2 o la licenza MIT.
+
+ "Dual BSD/GPL" Questo modulo è rilasciato con doppia licenza
+ a scelta fra: una variante della GPL v2 o la
+ licenza BSD. La variante esatta della licenza
+ BSD può essere determinata solo attraverso i
+ corrispondenti file sorgenti.
+
+ "Dual MPL/GPL" Questo modulo è rilasciato con doppia licenza
+ a scelta fra: una variante della GPL v2 o la
+ Mozilla Public License (MPL). La variante
+ esatta della licenza MPL può essere
+ determinata solo attraverso i corrispondenti
+ file sorgenti.
+
+ "Proprietary" Questo modulo è rilasciato con licenza
+ proprietaria. Questa stringa è solo per i
+ moduli proprietari di terze parti e non può
+ essere usata per quelli che risiedono nei
+ sorgenti del kernel. I moduli etichettati in
+ questo modo stanno contaminando il kernel e
+ gli viene assegnato un flag 'P'; quando
+ vengono caricati, il caricatore di moduli del
+ kernel si rifiuterà di collegare questi
+ moduli ai simboli che sono stati esportati
+ con EXPORT_SYMBOL_GPL().
+
+ ============================= =============================================
diff --git a/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst b/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst
index 24a133f0a51dd2812182955f31012cac3bee1708..276db0e37f439420d2b3dda1e0710095216136da 100644
--- a/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst
+++ b/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst
@@ -1,13 +1,946 @@
.. include:: ../disclaimer-ita.rst
:Original: :ref:`Documentation/process/maintainer-pgp-guide.rst <pgpguide>`
+:Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>
.. _it_pgpguide:
+=========================================
+La guida a PGP per manutentori del kernel
+=========================================
+
+:Author: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
+
+Questo documento è destinato agli sviluppatori del kernel Linux, in particolar
+modo ai manutentori. Contiene degli approfondimenti riguardo informazioni che
+sono state affrontate in maniera più generale nella sezione
+"`Protecting Code Integrity`_" pubblicata dalla Linux Foundation.
+Per approfondire alcuni argomenti trattati in questo documento è consigliato
+leggere il documento sopraindicato
+
+.. _`Protecting Code Integrity`: https://github.com/lfit/itpol/blob/master/protecting-code-integrity.md
+
+Il ruolo di PGP nello sviluppo del kernel Linux
+===============================================
+
+PGP aiuta ad assicurare l'integrità del codice prodotto dalla comunitÃ
+di sviluppo del kernel e, in secondo luogo, stabilisce canali di comunicazione
+affidabili tra sviluppatori attraverso lo scambio di email firmate con PGP.
+
+Il codice sorgente del kernel Linux è disponibile principalmente in due
+formati:
+
+- repositori distribuiti di sorgenti (git)
+- rilasci periodici di istantanee (archivi tar)
+
+Sia i repositori git che gli archivi tar portano le firme PGP degli
+sviluppatori che hanno creato i rilasci ufficiali del kernel. Queste firme
+offrono una garanzia crittografica che le versioni scaricabili rese disponibili
+via kernel.org, o altri portali, siano identiche a quelle che gli sviluppatori
+hanno sul loro posto di lavoro. A tal scopo:
+
+- i repositori git forniscono firme PGP per ogni tag
+- gli archivi tar hanno firme separate per ogni archivio
+
+.. _it_devs_not_infra:
+
+Fidatevi degli sviluppatori e non dell'infrastruttura
+-----------------------------------------------------
+
+Fin dal 2011, quando i sistemi di kernel.org furono compromessi, il principio
+generale del progetto Kernel Archives è stato quello di assumere che qualsiasi
+parte dell'infrastruttura possa essere compromessa in ogni momento. Per questa
+ragione, gli amministratori hanno intrapreso deliberatemene dei passi per
+enfatizzare che la fiducia debba risiedere sempre negli sviluppatori e mai nel
+codice che gestisce l'infrastruttura, indipendentemente da quali che siano le
+pratiche di sicurezza messe in atto.
+
+Il principio sopra indicato è la ragione per la quale è necessaria questa
+guida. Vogliamo essere sicuri che il riporre la fiducia negli sviluppatori
+non sia fatto semplicemente per incolpare qualcun'altro per future falle di
+sicurezza. L'obiettivo è quello di fornire una serie di linee guida che gli
+sviluppatori possano seguire per creare un ambiente di lavoro sicuro e
+salvaguardare le chiavi PGP usate nello stabilire l'integrità del kernel Linux
+stesso.
+
+.. _it_pgp_tools:
+
+Strumenti PGP
+=============
+
+Usare GnuPG v2
+--------------
+
+La vostra distribuzione potrebbe avere già installato GnuPG, dovete solo
+verificare che stia utilizzando la versione 2.x e non la serie 1.4 --
+molte distribuzioni forniscono entrambe, di base il comando ''gpg''
+invoca GnuPG v.1. Per controllate usate::
+
+ $ gpg --version | head -n1
+
+Se visualizzate ``gpg (GnuPG) 1.4.x``, allora state usando GnuPG v.1.
+Provate il comando ``gpg2`` (se non lo avete, potreste aver bisogno
+di installare il pacchetto gnupg2)::
+
+ $ gpg2 --version | head -n1
+
+Se visualizzate ``gpg (GnuPG) 2.x.x``, allora siete pronti a partire.
+Questa guida assume che abbiate la versione 2.2.(o successiva) di GnuPG.
+Se state usando la versione 2.0, alcuni dei comandi indicati qui non
+funzioneranno, in questo caso considerate un aggiornamento all'ultima versione,
+la 2.2. Versioni di gnupg-2.1.11 e successive dovrebbero essere compatibili
+per gli obiettivi di questa guida.
+
+Se avete entrambi i comandi: ``gpg`` e ``gpg2``, assicuratevi di utilizzare
+sempre la versione V2, e non quella vecchia. Per evitare errori potreste creare
+un alias::
+
+ $ alias gpg=gpg2
+
+Potete mettere questa opzione nel vostro ``.bashrc`` in modo da essere sicuri.
+
+Configurare le opzioni di gpg-agent
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+L'agente GnuPG è uno strumento di aiuto che partirà automaticamente ogni volta
+che userete il comando ``gpg`` e funzionerà in background con l'obiettivo di
+individuare la passphrase. Ci sono due opzioni che dovreste conoscere
+per personalizzare la scadenza della passphrase nella cache:
+
+- ``default-cache-ttl`` (secondi): Se usate ancora la stessa chiave prima
+ che il time-to-live termini, il conto alla rovescia si resetterà per un
+ altro periodo. Di base è di 600 (10 minuti).
+
+- ``max-cache-ttl`` (secondi): indipendentemente da quanto sia recente l'ultimo
+ uso della chiave da quando avete inserito la passphrase, se il massimo
+ time-to-live è scaduto, dovrete reinserire nuovamente la passphrase.
+ Di base è di 30 minuti.
+
+Se ritenete entrambe questi valori di base troppo corti (o troppo lunghi),
+potete creare il vostro file ``~/.gnupg/gpg-agent.conf`` ed impostare i vostri
+valori::
+
+ # set to 30 minutes for regular ttl, and 2 hours for max ttl
+ default-cache-ttl 1800
+ max-cache-ttl 7200
+
+.. note::
+
+ Non è più necessario far partire l'agente gpg manualmente all'inizio della
+ vostra sessione. Dovreste controllare i file rc per rimuovere tutto ciò che
+ riguarda vecchie le versioni di GnuPG, poiché potrebbero non svolgere più
+ bene il loro compito.
+
+Impostare un *refresh* con cronjob
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Potreste aver bisogno di rinfrescare regolarmente il vostro portachiavi in
+modo aggiornare le chiavi pubbliche di altre persone, lavoro che è svolto
+al meglio con un cronjob giornaliero::
+
+ @daily /usr/bin/gpg2 --refresh >/dev/null 2>&1
+
+Controllate il percorso assoluto del vostro comando ``gpg`` o ``gpg2`` e usate
+il comando ``gpg2`` se per voi ``gpg`` corrisponde alla versione GnuPG v.1.
+
+.. _it_master_key:
+
+Proteggere la vostra chiave PGP primaria
========================================
-Guida a PGP per i manutentori del kernel
-========================================
+
+Questa guida parte dal presupposto che abbiate già una chiave PGP che usate
+per lo sviluppo del kernel Linux. Se non ne avete ancora una, date uno sguardo
+al documento "`Protecting Code Integrity`_" che abbiamo menzionato prima.
+
+Dovreste inoltre creare una nuova chiave se quella attuale è inferiore a 2048
+bit (RSA).
+
+Chiave principale o sottochiavi
+-------------------------------
+
+Le sottochiavi sono chiavi PGP totalmente indipendenti, e sono collegate alla
+chiave principale attraverso firme certificate. È quindi importante
+comprendere i seguenti punti:
+
+1. Non ci sono differenze tecniche tra la chiave principale e la sottochiave.
+2. In fesa di creazione, assegniamo limitazioni funzionali ad ogni chiave
+ assegnando capacità specifiche.
+3. Una chiave PGP può avere 4 capacità :
+
+ - **[S]** può essere usata per firmare
+ - **[E]** può essere usata per criptare
+ - **[A]** può essere usata per autenticare
+ - **[C]** può essere usata per certificare altre chiavi
+
+4. Una singola chiave può avere più capacitÃ
+5. Una sottochiave è completamente indipendente dalla chiave principale.
+ Un messaggio criptato con la sottochiave non può essere decrittato con
+ quella principale. Se perdete la vostra sottochiave privata, non può
+ essere rigenerata in nessun modo da quella principale.
+
+La chiave con capacità **[C]** (certify) è identificata come la chiave
+principale perché è l'unica che può essere usata per indicare la relazione
+con altre chiavi. Solo la chiave **[C]** può essere usata per:
+
+- Aggiungere o revocare altre chiavi (sottochiavi) che hanno capacità S/E/A
+- Aggiungere, modificare o eliminare le identità (unids) associate alla chiave
+- Aggiungere o modificare la data di termine di sé stessa o di ogni sottochiave
+- Firmare le chiavi di altre persone a scopo di creare una rete di fiducia
+
+Di base, alla creazione di nuove chiavi, GnuPG genera quanto segue:
+
+- Una chiave madre che porta sia la capacità di certificazione che quella
+ di firma (**[SC]**)
+- Una sottochiave separata con capacità di criptaggio (**[E]**)
+
+Se avete usato i parametri di base per generare la vostra chiave, quello
+sarà il risultato. Potete verificarlo utilizzando ``gpg --list-secret-keys``,
+per esempio::
+
+ sec rsa2048 2018-01-23 [SC] [expires: 2020-01-23]
+ 000000000000000000000000AAAABBBBCCCCDDDD
+ uid [ultimate] Alice Dev <adev@kernel.org>
+ ssb rsa2048 2018-01-23 [E] [expires: 2020-01-23]
+
+Qualsiasi chiave che abbia la capacità **[C]** è la vostra chiave madre,
+indipendentemente da quali altre capacità potreste averle assegnato.
+
+La lunga riga sotto la voce ``sec`` è la vostra impronta digitale --
+negli esempi che seguono, quando vedere ``[fpr]`` ci si riferisce a questa
+stringa di 40 caratteri.
+
+Assicuratevi che la vostra passphrase sia forte
+-----------------------------------------------
+
+GnuPG utilizza le passphrases per criptare la vostra chiave privata prima
+di salvarla sul disco. In questo modo, anche se il contenuto della vostra
+cartella ``.gnupg`` venisse letto o trafugato nella sia interezza, gli
+attaccanti non potrebbero comunque utilizzare le vostre chiavi private senza
+aver prima ottenuto la passphrase per decriptarle.
+
+È assolutamente essenziale che le vostre chiavi private siano protette da
+una passphrase forte. Per impostarla o cambiarla, usate::
+
+ $ gpg --change-passphrase [fpr]
+
+Create una sottochiave di firma separata
+----------------------------------------
+
+Il nostro obiettivo è di proteggere la chiave primaria spostandola su un
+dispositivo sconnesso dalla rete, dunque se avete solo una chiave combinata
+**[SC]** allora dovreste creare una sottochiave di firma separata::
+
+ $ gpg --quick-add-key [fpr] ed25519 sign
+
+Ricordate di informare il keyserver del vostro cambiamento, cosicché altri
+possano ricevere la vostra nuova sottochiave::
+
+ $ gpg --send-key [fpr]
+
+.. note:: Supporto ECC in GnuPG
+ GnuPG 2.1 e successivi supportano pienamente *Elliptic Curve Cryptography*,
+ con la possibilità di combinare sottochiavi ECC con le tradizionali chiavi
+ primarie RSA. Il principale vantaggio della crittografia ECC è che è molto
+ più veloce da calcolare e crea firme più piccole se confrontate byte per
+ byte con le chiavi RSA a più di 2048 bit. A meno che non pensiate di
+ utilizzare un dispositivo smartcard che non supporta le operazioni ECC, vi
+ raccomandiamo ti creare sottochiavi di firma ECC per il vostro lavoro col
+ kernel.
+
+ Se per qualche ragione preferite rimanere con sottochiavi RSA, nel comando
+ precedente, sostituite "ed25519" con "rsa2048".
+
+Copia di riserva della chiave primaria per gestire il recupero da disastro
+--------------------------------------------------------------------------
+
+Maggiori sono le firme di altri sviluppatori che vengono applicate alla vostra,
+maggiori saranno i motivi per avere una copia di riserva che non sia digitale,
+al fine di effettuare un recupero da disastro.
+
+Il modo migliore per creare una copia fisica della vostra chiave privata è
+l'uso del programma ``paperkey``. Consultate ``man paperkey`` per maggiori
+dettagli sul formato dell'output ed i suoi punti di forza rispetto ad altre
+soluzioni. Paperkey dovrebbe essere già pacchettizzato per la maggior parte
+delle distribuzioni.
+
+Eseguite il seguente comando per creare una copia fisica di riserva della
+vostra chiave privata::
+
+ $ gpg --export-secret-key [fpr] | paperkey -o /tmp/key-backup.txt
+
+Stampate il file (o fate un pipe direttamente verso lpr), poi prendete
+una penna e scrivete la passphare sul margine del foglio. **Questo è
+caldamente consigliato** perché la copia cartacea è comunque criptata con
+la passphrase, e se mai doveste cambiarla non vi ricorderete qual'era al
+momento della creazione di quella copia -- *garantito*.
+
+Mettete la copia cartacea e la passphrase scritta a mano in una busta e
+mettetela in un posto sicuro e ben protetto, preferibilmente fuori casa,
+magari in una cassetta di sicurezza in banca.
+
+.. note::
+
+ Probabilmente la vostra stampante non è più quello stupido dispositivo
+ connesso alla porta parallela, ma dato che il suo output è comunque
+ criptato con la passphrase, eseguire la stampa in un sistema "cloud"
+ moderno dovrebbe essere comunque relativamente sicuro. Un'opzione potrebbe
+ essere quella di cambiare la passphrase della vostra chiave primaria
+ subito dopo aver finito con paperkey.
+
+Copia di riserva di tutta la cartella GnuPG
+-------------------------------------------
.. warning::
- TODO ancora da tradurre
+ **!!!Non saltate questo passo!!!**
+
+Quando avete bisogno di recuperare le vostre chiavi PGP è importante avere
+una copia di riserva pronta all'uso. Questo sta su un diverso piano di
+prontezza rispetto al recupero da disastro che abbiamo risolto con
+``paperkey``. Vi affiderete a queste copie esterne quando dovreste usare la
+vostra chiave Certify -- ovvero quando fate modifiche alle vostre chiavi o
+firmate le chiavi di altre persone ad una conferenza o ad un gruppo d'incontro.
+
+Incominciate con una piccola chiavetta di memoria USB (preferibilmente due)
+che userete per le copie di riserva. Dovrete criptarle usando LUKS -- fate
+riferimento alla documentazione della vostra distribuzione per capire come
+fare.
+
+Per la passphrase di criptazione, potete usare la stessa della vostra chiave
+primaria.
+
+Una volta che il processo di criptazione è finito, reinserite il disco USB ed
+assicurativi che venga montato correttamente. Copiate interamente la cartella
+``.gnugp`` nel disco criptato::
+
+ $ cp -a ~/.gnupg /media/disk/foo/gnupg-backup
+
+Ora dovreste verificare che tutto continui a funzionare::
+
+ $ gpg --homedir=/media/disk/foo/gnupg-backup --list-key [fpr]
+
+Se non vedete errori, allora dovreste avere fatto tutto con successo.
+Smontate il disco USB, etichettatelo per bene di modo da evitare di
+distruggerne il contenuto non appena vi serve una chiavetta USB a caso, ed
+infine mettetelo in un posto sicuro -- ma non troppo lontano, perché vi servirÃ
+di tanto in tanto per modificare le identità , aggiungere o revocare
+sottochiavi, o firmare le chiavi di altre persone.
+
+Togliete la chiave primaria dalla vostra home
+---------------------------------------------
+
+I file che si trovano nella vostra cartella home non sono poi così ben protetti
+come potreste pensare. Potrebbero essere letti o trafugati in diversi modi:
+
+- accidentalmente quando fate una rapida copia della cartella home per
+ configurare una nuova postazione
+- da un amministratore di sistema negligente o malintenzionato
+- attraverso copie di riserva insicure
+- attraverso malware installato in alcune applicazioni (browser, lettori PDF,
+ eccetera)
+- attraverso coercizione quando attraversate confini internazionali
+
+Proteggere la vostra chiave con una buona passphare aiuta notevolmente a
+ridurre i rischi elencati qui sopra, ma le passphrase possono essere scoperte
+attraverso i keylogger, il shoulder-surfing, o altri modi. Per questi motivi,
+nella configurazione si raccomanda di rimuove la chiave primaria dalla vostra
+cartella home e la si archivia su un dispositivo disconnesso.
+
+.. warning::
+
+ Per favore, fate riferimento alla sezione precedente e assicuratevi
+ di aver fatto una copia di riserva totale della cartella GnuPG. Quello
+ che stiamo per fare renderà la vostra chiave inutile se non avete delle
+ copie di riserva utilizzabili!
+
+Per prima cosa, identificate il keygrip della vostra chiave primaria::
+
+ $ gpg --with-keygrip --list-key [fpr]
+
+L'output assomiglierà a questo::
+
+ pub rsa2048 2018-01-24 [SC] [expires: 2020-01-24]
+ 000000000000000000000000AAAABBBBCCCCDDDD
+ Keygrip = 1111000000000000000000000000000000000000
+ uid [ultimate] Alice Dev <adev@kernel.org>
+ sub rsa2048 2018-01-24 [E] [expires: 2020-01-24]
+ Keygrip = 2222000000000000000000000000000000000000
+ sub ed25519 2018-01-24 [S]
+ Keygrip = 3333000000000000000000000000000000000000
+
+Trovate la voce keygrid che si trova sotto alla riga ``pub`` (appena sotto
+all'impronta digitale della chiave primaria). Questo corrisponderà direttamente
+ad un file nella cartella ``~/.gnupg``::
+
+ $ cd ~/.gnupg/private-keys-v1.d
+ $ ls
+ 1111000000000000000000000000000000000000.key
+ 2222000000000000000000000000000000000000.key
+ 3333000000000000000000000000000000000000.key
+
+Quello che dovrete fare è rimuovere il file .key che corrisponde al keygrip
+della chiave primaria::
+
+ $ cd ~/.gnupg/private-keys-v1.d
+ $ rm 1111000000000000000000000000000000000000.key
+
+Ora, se eseguite il comando ``--list-secret-keys``, vedrete che la chiave
+primaria non compare più (il simbolo ``#`` indica che non è disponibile)::
+
+ $ gpg --list-secret-keys
+ sec# rsa2048 2018-01-24 [SC] [expires: 2020-01-24]
+ 000000000000000000000000AAAABBBBCCCCDDDD
+ uid [ultimate] Alice Dev <adev@kernel.org>
+ ssb rsa2048 2018-01-24 [E] [expires: 2020-01-24]
+ ssb ed25519 2018-01-24 [S]
+
+Dovreste rimuovere anche i file ``secring.gpg`` che si trovano nella cartella
+``~/.gnupg``, in quanto rimasugli delle versioni precedenti di GnuPG.
+
+Se non avete la cartella "private-keys-v1.d"
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Se non avete la cartella ``~/.gnupg/private-keys-v1.d``, allora le vostre
+chiavi segrete sono ancora salvate nel vecchio file ``secring.gpg`` usato
+da GnuPG v1. Effettuare una qualsiasi modifica alla vostra chiave, come
+cambiare la passphare o aggiungere una sottochiave, dovrebbe convertire
+automaticamente il vecchio formato ``secring.gpg``nel nuovo
+``private-keys-v1.d``.
+
+Una volta che l'avete fatto, assicuratevi di rimuovere il file ``secring.gpg``,
+che continua a contenere la vostra chiave privata.
+
+.. _it_smartcards:
+
+Spostare le sottochiavi in un apposito dispositivo criptato
+===========================================================
+
+Nonostante la chiave primaria sia ora al riparo da occhi e mani indiscrete,
+le sottochiavi si trovano ancora nella vostra cartella home. Chiunque riesca
+a mettere le sue mani su quelle chiavi riuscirà a decriptare le vostre
+comunicazioni o a falsificare le vostre firme (se conoscono la passphrase).
+Inoltre, ogni volta che viene fatta un'operazione con GnuPG, le chiavi vengono
+caricate nella memoria di sistema e potrebbero essere rubate con l'uso di
+malware sofisticati (pensate a Meltdown e a Spectre).
+
+Il miglior modo per proteggere le proprie chiave è di spostarle su un
+dispositivo specializzato in grado di effettuare operazioni smartcard.
+
+I benefici di una smartcard
+---------------------------
+
+Una smartcard contiene un chip crittografico che è capace di immagazzinare
+le chiavi private ed effettuare operazioni crittografiche direttamente sulla
+carta stessa. Dato che la chiave non lascia mai la smartcard, il sistema
+operativo usato sul computer non sarà in grado di accedere alle chiavi.
+Questo è molto diverso dai dischi USB criptati che abbiamo usato allo scopo di
+avere una copia di riserva sicura -- quando il dispositivo USB è connesso e
+montato, il sistema operativo potrà accedere al contenuto delle chiavi private.
+
+L'uso di un disco USB criptato non può sostituire le funzioni di un dispositivo
+capace di operazioni di tipo smartcard.
+
+Dispositivi smartcard disponibili
+---------------------------------
+
+A meno che tutti i vostri computer dispongano di lettori smartcard, il modo
+più semplice è equipaggiarsi di un dispositivo USB specializzato che
+implementi le funzionalità delle smartcard. Sul mercato ci sono diverse
+soluzioni disponibili:
+
+- `Nitrokey Start`_: è Open hardware e Free Software, è basata sul progetto
+ `GnuK`_ della FSIJ. Ha il supporto per chiavi ECC, ma meno funzionalità di
+ sicurezza (come la resistenza alla manomissione o alcuni attacchi ad un
+ canale laterale).
+- `Nitrokey Pro`_: è simile alla Nitrokey Start, ma è più resistente alla
+ manomissione e offre più funzionalità di sicurezza, ma l'ECC.
+- `Yubikey 4`_: l'hardware e il software sono proprietari, ma è più economica
+ della Nitrokey Pro ed è venduta anche con porta USB-C il che è utile con i
+ computer portatili più recenti. In aggiunta, offre altre funzionalità di
+ sicurezza come FIDO, U2F, ma non l'ECC
+
+`Su LWN c'è una buona recensione`_ dei modelli elencati qui sopra e altri.
+Se volete usare chiavi ECC, la vostra migliore scelta sul mercato è la
+Nitrokey Start.
+
+.. _`Nitrokey Start`: https://shop.nitrokey.com/shop/product/nitrokey-start-6
+.. _`Nitrokey Pro`: https://shop.nitrokey.com/shop/product/nitrokey-pro-3
+.. _`Yubikey 4`: https://www.yubico.com/product/yubikey-4-series/
+.. _Gnuk: http://www.fsij.org/doc-gnuk/
+.. _`Su LWN c'è una buona recensione`: https://lwn.net/Articles/736231/
+
+Configurare il vostro dispositivo smartcard
+-------------------------------------------
+
+Il vostro dispositivo smartcard dovrebbe iniziare a funzionare non appena
+lo collegate ad un qualsiasi computer Linux moderno. Potete verificarlo
+eseguendo::
+
+ $ gpg --card-status
+
+Se vedete tutti i dettagli della smartcard, allora ci siamo. Sfortunatamente,
+affrontare tutti i possibili motivi per cui le cose potrebbero non funzionare
+non è lo scopo di questa guida. Se avete problemi nel far funzionare la carta
+con GnuPG, cercate aiuto attraverso i soliti canali di supporto.
+
+Per configurare la vostra smartcard, dato che non c'è una via facile dalla
+riga di comando, dovrete usate il menu di GnuPG::
+
+ $ gpg --card-edit
+ [...omitted...]
+ gpg/card> admin
+ Admin commands are allowed
+ gpg/card> passwd
+
+Dovreste impostare il PIN dell'utente (1), quello dell'amministratore (3) e il
+codice di reset (4). Assicuratevi di annotare e salvare questi codici in un
+posto sicuro -- specialmente il PIN dell'amministratore e il codice di reset
+(che vi permetterà di azzerare completamente la smartcard). Il PIN
+dell'amministratore viene usato così raramente che è inevitabile dimenticarselo
+se non lo si annota.
+
+Tornando al nostro menu, potete impostare anche altri valori (come il nome,
+il sesso, informazioni d'accesso, eccetera), ma non sono necessari e aggiunge
+altre informazioni sulla carta che potrebbero trapelare in caso di smarrimento.
+
+.. note::
+
+ A dispetto del nome "PIN", né il PIN utente né quello dell'amministratore
+ devono essere esclusivamente numerici.
+
+Spostare le sottochiavi sulla smartcard
+---------------------------------------
+
+Uscite dal menu (usando "q") e salverete tutte le modifiche. Poi, spostiamo
+tutte le sottochiavi sulla smartcard. Per la maggior parte delle operazioni
+vi serviranno sia la passphrase della chiave PGP che il PIN
+dell'amministratore::
+
+ $ gpg --edit-key [fpr]
+
+ Secret subkeys are available.
+
+ pub rsa2048/AAAABBBBCCCCDDDD
+ created: 2018-01-23 expires: 2020-01-23 usage: SC
+ trust: ultimate validity: ultimate
+ ssb rsa2048/1111222233334444
+ created: 2018-01-23 expires: never usage: E
+ ssb ed25519/5555666677778888
+ created: 2017-12-07 expires: never usage: S
+ [ultimate] (1). Alice Dev <adev@kernel.org>
+
+ gpg>
+
+Usando ``--edit-key`` si tornerà alla modalità menu e noterete che
+la lista delle chiavi è leggermente diversa. Da questo momento in poi,
+tutti i comandi saranno eseguiti nella modalità menu, come indicato
+da ``gpg>``.
+
+Per prima cosa, selezioniamo la chiave che verrà messa sulla carta --
+potete farlo digitando ``key 1`` (è la prima della lista, la sottochiave
+**[E]**)::
+
+ gpg> key 1
+
+Nel'output dovreste vedere ``ssb*`` associato alla chiave **[E]**. Il simbolo
+``*`` indica che la chiave è stata "selezionata". Funziona come un
+interruttore, ovvero se scrivete nuovamente ``key 1``, il simbolo ``*`` sparirÃ
+e la chiave non sarà più selezionata.
+
+Ora, spostiamo la chiave sulla smartcard::
+
+ gpg> keytocard
+ Please select where to store the key:
+ (2) Encryption key
+ Your selection? 2
+
+Dato che è la nostra chiave **[E]**, ha senso metterla nella sezione criptata.
+Quando confermerete la selezione, vi verrà chiesta la passphrase della vostra
+chiave PGP, e poi il PIN dell'amministratore. Se il comando ritorna senza
+errori, allora la vostra chiave è stata spostata con successo.
+
+**Importante**: digitate nuovamente ``key 1`` per deselezionare la prima chiave
+e selezionate la seconda chiave **[S]** con ``key 2``::
+
+ gpg> key 1
+ gpg> key 2
+ gpg> keytocard
+ Please select where to store the key:
+ (1) Signature key
+ (3) Authentication key
+ Your selection? 1
+
+Potete usare la chiave **[S]** sia per firmare che per autenticare, ma vogliamo
+che sia nella sezione di firma, quindi scegliete (1). Ancora una volta, se il
+comando ritorna senza errori, allora l'operazione è avvenuta con successo::
+
+ gpg> q
+ Save changes? (y/N) y
+
+Salvando le modifiche cancellerete dalla vostra cartella home tutte le chiavi
+che avete spostato sulla carta (ma questo non è un problema, perché abbiamo
+fatto delle copie di sicurezza nel caso in cui dovessimo configurare una
+nuova smartcard).
+
+Verificare che le chiavi siano state spostate
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Ora, se doveste usare l'opzione ``--list-secret-keys``, vedrete una
+sottile differenza nell'output::
+
+ $ gpg --list-secret-keys
+ sec# rsa2048 2018-01-24 [SC] [expires: 2020-01-24]
+ 000000000000000000000000AAAABBBBCCCCDDDD
+ uid [ultimate] Alice Dev <adev@kernel.org>
+ ssb> rsa2048 2018-01-24 [E] [expires: 2020-01-24]
+ ssb> ed25519 2018-01-24 [S]
+
+Il simbolo ``>`` in ``ssb>`` indica che la sottochiave è disponibile solo
+nella smartcard. Se tornate nella vostra cartella delle chiavi segrete e
+guardate al suo contenuto, noterete che i file ``.key`` sono stati sostituiti
+con degli stub::
+
+ $ cd ~/.gnupg/private-keys-v1.d
+ $ strings *.key | grep 'private-key'
+
+Per indicare che i file sono solo degli stub e che in realtà il contenuto è
+sulla smartcard, l'output dovrebbe mostrarvi ``shadowed-private-key``.
+
+Verificare che la smartcard funzioni
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Per verificare che la smartcard funzioni come dovuto, potete creare
+una firma::
+
+ $ echo "Hello world" | gpg --clearsign > /tmp/test.asc
+ $ gpg --verify /tmp/test.asc
+
+Col primo comando dovrebbe chiedervi il PIN della smartcard, e poi dovrebbe
+mostrare "Good signature" dopo l'esecuzione di ``gpg --verify``.
+
+Complimenti, siete riusciti a rendere estremamente difficile il furto della
+vostra identità digitale di sviluppatore.
+
+Altre operazioni possibili con GnuPG
+------------------------------------
+
+Segue un breve accenno ad alcune delle operazioni più comuni che dovrete
+fare con le vostre chiavi PGP.
+
+Montare il disco con la chiave primaria
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Vi servirà la vostra chiave principale per tutte le operazioni che seguiranno,
+per cui per prima cosa dovrete accedere ai vostri backup e dire a GnuPG di
+usarli::
+
+ $ export GNUPGHOME=/media/disk/foo/gnupg-backup
+ $ gpg --list-secret-keys
+
+Dovete assicurarvi di vedere ``sec`` e non ``sec#`` nell'output del programma
+(il simbolo ``#`` significa che la chiave non è disponibile e che state ancora
+utilizzando la vostra solita cartella di lavoro).
+
+Estendere la data di scadenza di una chiave
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+La chiave principale ha una data di scadenza di 2 anni dal momento della sua
+creazione. Questo per motivi di sicurezza e per rendere obsolete le chiavi
+che, eventualmente, dovessero sparire dai keyserver.
+
+Per estendere di un anno, dalla data odierna, la scadenza di una vostra chiave,
+eseguite::
+
+ $ gpg --quick-set-expire [fpr] 1y
+
+Se per voi è più facile da memorizzare, potete anche utilizzare una data
+specifica (per esempio, il vostro compleanno o capodanno)::
+
+ $ gpg --quick-set-expire [fpr] 2020-07-01
+
+Ricordatevi di inviare l'aggiornamento ai keyserver::
+
+ $ gpg --send-key [fpr]
+
+Aggiornare la vostra cartella di lavoro dopo ogni modifica
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Dopo aver fatto delle modifiche alle vostre chiavi usando uno spazio a parte,
+dovreste importarle nella vostra cartella di lavoro abituale::
+
+ $ gpg --export | gpg --homedir ~/.gnupg --import
+ $ unset GNUPGHOME
+
+
+Usare PGP con Git
+=================
+
+Una delle caratteristiche fondanti di Git è la sua natura decentralizzata --
+una volta che il repositorio è stato clonato sul vostro sistema, avete la
+storia completa del progetto, inclusi i suoi tag, i commit ed i rami. Tuttavia,
+con i centinaia di repositori clonati che ci sono in giro, come si fa a
+verificare che la loro copia di linux.git non è stata manomessa da qualcuno?
+
+Oppure, cosa succede se viene scoperta una backdoor nel codice e la riga
+"Autore" dice che sei stato tu, mentre tu sei abbastanza sicuro di
+`non averci niente a che fare`_?
+
+Per risolvere entrambi i problemi, Git ha introdotto l'integrazione con PGP.
+I tag firmati dimostrano che il repositorio è integro assicurando che il suo
+contenuto è lo stesso che si trova sulle macchine degli sviluppatori che hanno
+creato il tag; mentre i commit firmati rendono praticamente impossibile
+ad un malintenzionato di impersonarvi senza avere accesso alle vostre chiavi
+PGP.
+
+.. _`non averci niente a che fare`: https://github.com/jayphelps/git-blame-someone-else
+
+Configurare git per usare la vostra chiave PGP
+----------------------------------------------
+
+Se avete solo una chiave segreta nel vostro portachiavi, allora non avete nulla
+da fare in più dato che sarà la vostra chiave di base. Tuttavia, se doveste
+avere più chiavi segrete, potete dire a git quale dovrebbe usare (``[fpg]``
+è la vostra impronta digitale)::
+
+ $ git config --global user.signingKey [fpr]
+
+**IMPORTANTE**: se avete una comando dedicato per ``gpg2``, allora dovreste
+dire a git di usare sempre quello piuttosto che il vecchio comando ``gpg``::
+
+ $ git config --global gpg.program gpg2
+
+Come firmare i tag
+------------------
+
+Per creare un tag firmato, passate l'opzione ``-s`` al comando tag::
+
+ $ git tag -s [tagname]
+
+La nostra raccomandazione è quella di firmare sempre i tag git, perché
+questo permette agli altri sviluppatori di verificare che il repositorio
+git dal quale stanno prendendo il codice non è stato alterato intenzionalmente.
+
+Come verificare i tag firmati
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Per verificare un tag firmato, potete usare il comando ``verify-tag``::
+
+ $ git verify-tag [tagname]
+
+Se state prendendo un tag da un fork del repositorio del progetto, git
+dovrebbe verificare automaticamente la firma di quello che state prendendo
+e vi mostrerà il risultato durante l'operazione di merge::
+
+ $ git pull [url] tags/sometag
+
+Il merge conterrà qualcosa di simile::
+
+ Merge tag 'sometag' of [url]
+
+ [Tag message]
+
+ # gpg: Signature made [...]
+ # gpg: Good signature from [...]
+
+Se state verificando il tag di qualcun altro, allora dovrete importare
+la loro chiave PGP. Fate riferimento alla sezione ":ref:`it_verify_identities`"
+che troverete più avanti.
+
+Configurare git per firmare sempre i tag con annotazione
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Se state creando un tag con annotazione è molto probabile che vogliate
+firmarlo. Per imporre a git di firmare sempre un tag con annotazione,
+dovete impostare la seguente opzione globale::
+
+ $ git config --global tag.forceSignAnnotated true
+
+Come usare commit firmati
+-------------------------
+
+Creare dei commit firmati è facile, ma è molto più difficile utilizzarli
+nello sviluppo del kernel linux per via del fatto che ci si affida alle
+liste di discussione e questo modo di procedere non mantiene le firme PGP
+nei commit. In aggiunta, quando si usa *rebase* nel proprio repositorio
+locale per allinearsi al kernel anche le proprie firme PGP verranno scartate.
+Per questo motivo, la maggior parte degli sviluppatori del kernel non si
+preoccupano troppo di firmare i propri commit ed ignoreranno quelli firmati
+che si trovano in altri repositori usati per il proprio lavoro.
+
+Tuttavia, se avete il vostro repositorio di lavoro disponibile al pubblico
+su un qualche servizio di hosting git (kernel.org, infradead.org, ozlabs.org,
+o altri), allora la raccomandazione è di firmare tutti i vostri commit
+anche se gli sviluppatori non ne beneficeranno direttamente.
+
+Vi raccomandiamo di farlo per i seguenti motivi:
+
+1. Se dovesse mai esserci la necessità di fare delle analisi forensi o
+ tracciare la provenienza di un codice, anche sorgenti mantenuti
+ esternamente che hanno firme PGP sui commit avranno un certo valore a
+ questo scopo.
+2. Se dovesse mai capitarvi di clonare il vostro repositorio locale (per
+ esempio dopo un danneggiamento del disco), la firma vi permetterà di
+ verificare l'integrità del repositorio prima di riprendere il lavoro.
+3. Se qualcuno volesse usare *cherry-pick* sui vostri commit, allora la firma
+ permetterà di verificare l'integrità dei commit prima di applicarli.
+
+Creare commit firmati
+~~~~~~~~~~~~~~~~~~~~~
+
+Per creare un commit firmato, dovete solamente aggiungere l'opzione ``-S``
+al comando ``git commit`` (si usa la lettera maiuscola per evitare
+conflitti con un'altra opzione)::
+
+ $ git commit -S
+
+Configurare git per firmare sempre i commit
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Potete dire a git di firmare sempre i commit::
+
+ git config --global commit.gpgSign true
+
+.. note::
+
+ Assicuratevi di aver configurato ``gpg-agent`` prima di abilitare
+ questa opzione.
+
+.. _it_verify_identities:
+
+Come verificare l'identità degli sviluppatori del kernel
+========================================================
+
+Firmare i tag e i commit è facile, ma come si fa a verificare che la chiave
+usata per firmare qualcosa appartenga davvero allo sviluppatore e non ad un
+impostore?
+
+Configurare l'auto-key-retrieval usando WKD e DANE
+--------------------------------------------------
+
+Se non siete ancora in possesso di una vasta collezione di chiavi pubbliche
+di altri sviluppatori, allora potreste iniziare il vostro portachiavi
+affidandovi ai servizi di auto-scoperta e auto-recupero. GnuPG può affidarsi
+ad altre tecnologie di delega della fiducia, come DNSSEC e TLS, per sostenervi
+nel caso in cui iniziare una propria rete di fiducia da zero sia troppo
+scoraggiante.
+
+Aggiungete il seguente testo al vostro file ``~/.gnupg/gpg.conf``::
+
+ auto-key-locate wkd,dane,local
+ auto-key-retrieve
+
+La *DNS-Based Authentication of Named Entities* ("DANE") è un metodo
+per la pubblicazione di chiavi pubbliche su DNS e per renderle sicure usando
+zone firmate con DNSSEC. Il *Web Key Directory* ("WKD") è un metodo
+alternativo che usa https a scopo di ricerca. Quando si usano DANE o WKD
+per la ricerca di chiavi pubbliche, GnuPG validerà i certificati DNSSEC o TLS
+prima di aggiungere al vostro portachiavi locale le eventuali chiavi trovate.
+
+Kernel.org pubblica la WKD per tutti gli sviluppatori che hanno un account
+kernel.org. Una volta che avete applicato le modifiche al file ``gpg.conf``,
+potrete auto-recuperare le chiavi di Linus Torvalds e Greg Kroah-Hartman
+(se non le avete già )::
+
+ $ gpg --locate-keys torvalds@kernel.org gregkh@kernel.org
+
+Se avete un account kernel.org, al fine di rendere più utile l'uso di WKD
+da parte di altri sviluppatori del kernel, dovreste `aggiungere alla vostra
+chiave lo UID di kernel.org`_.
+
+.. _`aggiungere alla vostra chiave lo UID di kernel.org`: https://korg.wiki.kernel.org/userdoc/mail#adding_a_kernelorg_uid_to_your_pgp_key
+
+Web of Trust (WOT) o Trust on First Use (TOFU)
+----------------------------------------------
+
+PGP incorpora un meccanismo di delega della fiducia conosciuto come
+"Web of Trust". Di base, questo è un tentativo di sostituire la necessitÃ
+di un'autorità certificativa centralizzata tipica del mondo HTTPS/TLS.
+Invece di avere svariati produttori software che decidono chi dovrebbero
+essere le entità di certificazione di cui dovreste fidarvi, PGP lascia
+la responsabilità ad ogni singolo utente.
+
+Sfortunatamente, solo poche persone capiscono come funziona la rete di fiducia.
+Nonostante sia un importante aspetto della specifica OpenPGP, recentemente
+le versioni di GnuPG (2.2 e successive) hanno implementato un meccanisco
+alternativo chiamato "Trust on First Use" (TOFU). Potete pensare a TOFU come
+"ad un approccio all fidicia simile ad SSH". In SSH, la prima volta che vi
+connettete ad un sistema remoto, l'impronta digitale della chiave viene
+registrata e ricordata. Se la chiave dovesse cambiare in futuro, il programma
+SSH vi avviserà e si rifiuterà di connettersi, obbligandovi a prendere una
+decisione circa la fiducia che riponete nella nuova chiave. In modo simile,
+la prima volta che importate la chiave PGP di qualcuno, si assume sia valida.
+Se ad un certo punto GnuPG trova un'altra chiave con la stessa identità ,
+entrambe, la vecchia e la nuova, verranno segnate come invalide e dovrete
+verificare manualmente quale tenere.
+
+Vi raccomandiamo di usare il meccanisco TOFU+PGP (che è la nuova configurazione
+di base di GnuPG v2). Per farlo, aggiungete (o modificate) l'impostazione
+``trust-model`` in ``~/.gnupg/gpg.conf``::
+
+ trust-model tofu+pgp
+
+Come usare i keyserver in sicurezza
+-----------------------------------
+Se ottenete l'errore "No public key" quando cercate di validate il tag di
+qualcuno, allora dovreste cercare quella chiave usando un keyserver. È
+importante tenere bene a mente che non c'è alcuna garanzia che la chiave
+che avete recuperato da un keyserver PGP appartenga davvero alla persona
+reale -- è progettato così. Dovreste usare il Web of Trust per assicurarvi
+che la chiave sia valida.
+
+Come mantenere il Web of Trust va oltre gli scopi di questo documento,
+semplicemente perché farlo come si deve richiede sia sforzi che perseveranza
+che tendono ad andare oltre al livello di interesse della maggior parte degli
+esseri umani. Qui di seguito alcuni rapidi suggerimenti per aiutarvi a ridurre
+il rischio di importare chiavi maligne.
+
+Primo, diciamo che avete provato ad eseguire ``git verify-tag`` ma restituisce
+un errore dicendo che la chiave non è stata trovata::
+
+ $ git verify-tag sunxi-fixes-for-4.15-2
+ gpg: Signature made Sun 07 Jan 2018 10:51:55 PM EST
+ gpg: using RSA key DA73759BF8619E484E5A3B47389A54219C0F2430
+ gpg: issuer "wens@...org"
+ gpg: Can't check signature: No public key
+
+Cerchiamo nel keyserver per maggiori informazioni sull'impronta digitale
+della chiave (l'impronta digitale, probabilmente, appartiene ad una
+sottochiave, dunque non possiamo usarla direttamente senza trovare prima
+l'ID della chiave primaria associata ad essa)::
+
+ $ gpg --search DA73759BF8619E484E5A3B47389A54219C0F2430
+ gpg: data source: hkp://keys.gnupg.net
+ (1) Chen-Yu Tsai <wens@...org>
+ 4096 bit RSA key C94035C21B4F2AEB, created: 2017-03-14, expires: 2019-03-15
+ Keys 1-1 of 1 for "DA73759BF8619E484E5A3B47389A54219C0F2430". Enter number(s), N)ext, or Q)uit > q
+
+Localizzate l'ID della chiave primaria, nel nostro esempio
+``C94035C21B4F2AEB``. Ora visualizzate le chiavi di Linus Torvalds
+che avete nel vostro portachiavi::
+
+ $ gpg --list-key torvalds@kernel.org
+ pub rsa2048 2011-09-20 [SC]
+ ABAF11C65A2970B130ABE3C479BE3E4300411886
+ uid [ unknown] Linus Torvalds <torvalds@kernel.org>
+ sub rsa2048 2011-09-20 [E]
+
+Poi, aprite il `PGP pathfinder`_. Nel campo "From", incollate l'impronta
+digitale della chiave di Linus Torvalds che si vede nell'output qui sopra.
+Nel campo "to", incollate il key-id della chiave sconosciuta che avete
+trovato con ``gpg --search``, e poi verificare il risultato:
+
+- `Finding paths to Linus`_
+
+Se trovate un paio di percorsi affidabili è un buon segno circa la validitÃ
+della chiave. Ora, potete aggiungerla al vostro portachiavi dal keyserver::
+
+ $ gpg --recv-key C94035C21B4F2AEB
+
+Questa procedura non è perfetta, e ovviamente state riponendo la vostra
+fiducia nell'amministratore del servizio *PGP Pathfinder* sperando che non
+sia malintenzionato (infatti, questo va contro :ref:`it_devs_not_infra`).
+Tuttavia, se mantenete con cura la vostra rete di fiducia sarà un deciso
+miglioramento rispetto alla cieca fiducia nei keyserver.
+
+.. _`PGP pathfinder`: https://pgp.cs.uu.nl/
+.. _`Finding paths to Linus`: https://pgp.cs.uu.nl/paths/79BE3E4300411886/to/C94035C21B4F2AEB.html
diff --git a/Documentation/translations/it_IT/process/stable-kernel-rules.rst b/Documentation/translations/it_IT/process/stable-kernel-rules.rst
index 6fa5ce9c3572663ff373c6db99efa638d06eb76e..48e88e5ad2c5c94aff37c93aa5303f269fb31052 100644
--- a/Documentation/translations/it_IT/process/stable-kernel-rules.rst
+++ b/Documentation/translations/it_IT/process/stable-kernel-rules.rst
@@ -1,12 +1,202 @@
.. include:: ../disclaimer-ita.rst
:Original: :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
+:Translator: Federico Vaga <federico.vaga@vaga.pv.it>
.. _it_stable_kernel_rules:
Tutto quello che volevate sapere sui rilasci -stable di Linux
==============================================================
-.. warning::
+Regole sul tipo di patch che vengono o non vengono accettate nei sorgenti
+"-stable":
- TODO ancora da tradurre
+ - Ovviamente dev'essere corretta e verificata.
+ - Non dev'essere più grande di 100 righe, incluso il contesto.
+ - Deve correggere una cosa sola.
+ - Deve correggere un baco vero che sta disturbando gli utenti (non cose del
+ tipo "Questo potrebbe essere un problema ...").
+ - Deve correggere un problema di compilazione (ma non per cose già segnate
+ con CONFIG_BROKEN), un kernel oops, un blocco, una corruzione di dati,
+ un vero problema di sicurezza, o problemi del tipo "oh, questo non va bene".
+ In pratica, qualcosa di critico.
+ - Problemi importanti riportati dagli utenti di una distribuzione potrebbero
+ essere considerati se correggono importanti problemi di prestazioni o di
+ interattività . Dato che questi problemi non sono così ovvi e la loro
+ correzione ha un'alta probabilità d'introdurre una regressione, dovrebbero
+ essere sottomessi solo dal manutentore della distribuzione includendo un
+ link, se esiste, ad un rapporto su bugzilla, e informazioni aggiuntive
+ sull'impatto che ha sugli utenti.
+ - Non deve correggere problemi relativi a una "teorica sezione critica",
+ a meno che non venga fornita anche una spiegazione su come questa si
+ possa verificare.
+ - Non deve includere alcuna correzione "banale" (correzioni grammaticali,
+ pulizia dagli spazi bianchi, eccetera).
+ - Deve rispettare le regole scritte in
+ :ref:`Documentation/translation/it_IT/process/submitting-patches.rst <it_submittingpatches>`
+ - Questa patch o una equivalente deve esistere già nei sorgenti principali di
+ Linux
+
+
+Procedura per sottomettere patch per i sorgenti -stable
+-------------------------------------------------------
+
+ - Se la patch contiene modifiche a dei file nelle cartelle net/ o drivers/net,
+ allora seguite le linee guida descritte in
+ :ref:`Documentation/translation/it_IT/networking/netdev-FAQ.rst <it_netdev-FAQ>`;
+ ma solo dopo aver verificato al seguente indirizzo che la patch non sia
+ già in coda:
+ https://patchwork.ozlabs.org/bundle/davem/stable/?series=&submitter=&state=*&q=&archive=
+ - Una patch di sicurezza non dovrebbero essere gestite (solamente) dal processo
+ di revisione -stable, ma dovrebbe seguire le procedure descritte in
+ :ref:`Documentation/translations/it_IT/admin-guide/security-bugs.rst <it_securitybugs>`.
+
+
+Per tutte le altre sottomissioni, scegliere una delle seguenti procedure
+------------------------------------------------------------------------
+
+.. _it_option_1:
+
+Opzione 1
+*********
+
+Per far sì che una patch venga automaticamente inclusa nei sorgenti stabili,
+aggiungete l'etichetta
+
+.. code-block:: none
+
+ Cc: stable@vger.kernel.org
+
+nell'area dedicata alla firme. Una volta che la patch è stata inclusa, verrÃ
+applicata anche sui sorgenti stabili senza che l'autore o il manutentore
+del sottosistema debba fare qualcosa.
+
+.. _it_option_2:
+
+Opzione 2
+*********
+
+Dopo che la patch è stata inclusa nei sorgenti Linux, inviate una mail a
+stable@vger.kernel.org includendo: il titolo della patch, l'identificativo
+del commit, il perché pensate che debba essere applicata, e in quale versione
+del kernel la vorreste vedere.
+
+.. _it_option_3:
+
+Opzione 3
+*********
+
+Inviata la patch, dopo aver verificato che rispetta le regole descritte in
+precedenza, a stable@vger.kernel.org. Dovete annotare nel changelog
+l'identificativo del commit nei sorgenti principali, così come la versione
+del kernel nel quale vorreste vedere la patch.
+
+L':ref:`it_option_1` è fortemente raccomandata; è il modo più facile e usato.
+L':ref:`it_option_2` e l':ref:`it_option_3` sono più utili quando, al momento
+dell'inclusione dei sorgenti principali, si ritiene che non debbano essere
+incluse anche in quelli stabili (per esempio, perché si crede che si dovrebbero
+fare più verifiche per eventuali regressioni). L':ref:`it_option_3` è
+particolarmente utile se la patch ha bisogno di qualche modifica per essere
+applicata ad un kernel più vecchio (per esempio, perché nel frattempo l'API è
+cambiata).
+
+Notate che per l':ref:`it_option_3`, se la patch è diversa da quella nei
+sorgenti principali (per esempio perché è stato necessario un lavoro di
+adattamento) allora dev'essere ben documentata e giustificata nella descrizione
+della patch.
+
+L'identificativo del commit nei sorgenti principali dev'essere indicato sopra
+al messaggio della patch, così:
+
+.. code-block:: none
+
+ commit <sha1> upstream.
+
+In aggiunta, alcune patch inviate attraverso l':ref:`it_option_1` potrebbero
+dipendere da altre che devo essere incluse. Questa situazione può essere
+indicata nel seguente modo nell'area dedicata alle firme:
+
+.. code-block:: none
+
+ Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
+ Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
+ Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
+ Cc: <stable@vger.kernel.org> # 3.3.x
+ Signed-off-by: Ingo Molnar <mingo@elte.hu>
+
+La sequenza di etichette ha il seguente significato:
+
+.. code-block:: none
+
+ git cherry-pick a1f84a3
+ git cherry-pick 1b9508f
+ git cherry-pick fd21073
+ git cherry-pick <this commit>
+
+Inoltre, alcune patch potrebbero avere dei requisiti circa la versione del
+kernel. Questo può essere indicato usando il seguente formato nell'area
+dedicata alle firme:
+
+.. code-block:: none
+
+ Cc: <stable@vger.kernel.org> # 3.3.x
+
+L'etichetta ha il seguente significato:
+
+.. code-block:: none
+
+ git cherry-pick <this commit>
+
+per ogni sorgente "-stable" che inizia con la versione indicata.
+
+Dopo la sottomissione:
+
+ - Il mittente riceverà un ACK quando la patch è stata accettata e messa in
+ coda, oppure un NAK se la patch è stata rigettata. A seconda degli impegni
+ degli sviluppatori, questa risposta potrebbe richiedere alcuni giorni.
+ - Se accettata, la patch verrà aggiunta alla coda -stable per essere
+ revisionata dal altri sviluppatori e dal principale manutentore del
+ sottosistema.
+
+
+Ciclo di una revisione
+----------------------
+
+ - Quando i manutentori -stable decidono di fare un ciclo di revisione, le
+ patch vengono mandate al comitato per la revisione, ai manutentori soggetti
+ alle modifiche delle patch (a meno che il mittente non sia anche il
+ manutentore di quell'area del kernel) e in CC: alla lista di discussione
+ linux-kernel.
+ - La commissione per la revisione ha 48 ore per dare il proprio ACK o NACK
+ alle patch.
+ - Se una patch viene rigettata da un membro della commissione, o un membro
+ della lista linux-kernel obietta la bontà della patch, sollevando problemi
+ che i manutentori ed i membri non avevano compreso, allora la patch verrÃ
+ rimossa dalla coda.
+ - Alla fine del ciclo di revisione tutte le patch che hanno ricevuto l'ACK
+ verranno aggiunte per il prossimo rilascio -stable, e successivamente
+ questo nuovo rilascio verrà fatto.
+ - Le patch di sicurezza verranno accettate nei sorgenti -stable direttamente
+ dalla squadra per la sicurezza del kernel, e non passerà per il normale
+ ciclo di revisione. Contattate la suddetta squadra per maggiori dettagli
+ su questa procedura.
+
+Sorgenti
+--------
+
+ - La coda delle patch, sia quelle già applicate che in fase di revisione,
+ possono essere trovate al seguente indirizzo:
+
+ https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
+
+ - Il rilascio definitivo, e marchiato, di tutti i kernel stabili può essere
+ trovato in rami distinti per versione al seguente indirizzo:
+
+ https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+
+
+Comitato per la revisione
+-------------------------
+
+ - Questo comitato è fatto di sviluppatori del kernel che si sono offerti
+ volontari per questo lavoro, e pochi altri che non sono proprio volontari.
diff --git a/Documentation/translations/it_IT/process/submitting-patches.rst b/Documentation/translations/it_IT/process/submitting-patches.rst
index 2ab9c1401aa191080ffd461fb83d3bf83b0d4394..7d7ea92c5c5ad27677af982b5b168bbad257149c 100644
--- a/Documentation/translations/it_IT/process/submitting-patches.rst
+++ b/Documentation/translations/it_IT/process/submitting-patches.rst
@@ -67,8 +67,8 @@ sulla radice dei sorgenti del kernel, e non sulle sue sottocartelle.
Per creare una patch per un singolo file, spesso è sufficiente fare::
- SRCTREE= linux
- MYFILE= drivers/net/mydriver.c
+ SRCTREE=linux
+ MYFILE=drivers/net/mydriver.c
cd $SRCTREE
cp $MYFILE $MYFILE.orig
@@ -80,7 +80,7 @@ Per creare una patch per molteplici file, dovreste spacchettare i sorgenti
"vergini", o comunque non modificati, e fare un ``diff`` coi vostri.
Per esempio::
- MYSRC= /devel/linux
+ MYSRC=/devel/linux
tar xvfz linux-3.19.tar.gz
mv linux-3.19 linux-3.19-vanilla
@@ -567,11 +567,42 @@ alcunché - ma dovrebbe indicare che la persona ha ricevuto una copia della
patch. Questa etichetta documenta che terzi potenzialmente interessati sono
stati inclusi nella discussione.
-L'etichetta Co-developed-by: indica che la patch è stata scritta dall'autore in
-collaborazione con un altro sviluppatore. Qualche volta questo è utile quando
-più persone lavorano sulla stessa patch. Notate, questa persona deve avere
-nella patch anche una riga Signed-off-by:.
+Co-developed-by: indica che la patch è stata cosviluppata da diversi
+sviluppatori; viene usato per assegnare più autori (in aggiunta a quello
+associato all'etichetta From:) quando più persone lavorano ad una patch. Dato
+che Co-developed-by: implica la paternità della patch, ogni Co-developed-by:
+dev'essere seguito immediatamente dal Signed-off-by: del corrispondente
+coautore. Qui si applica la procedura di base per sign-off, in pratica
+l'ordine delle etichette Signed-off-by: dovrebbe riflettere il più possibile
+l'ordine cronologico della storia della patch, indipendentemente dal fatto che
+la paternità venga assegnata via From: o Co-developed-by:. Da notare che
+l'ultimo Signed-off-by: dev'essere quello di colui che ha sottomesso la patch.
+Notate anche che l'etichetta From: è opzionale quando l'autore in From: è
+anche la persona (e indirizzo email) indicato nel From: dell'intestazione
+dell'email.
+
+Esempio di una patch sottomessa dall'autore in From:::
+
+ <changelog>
+
+ Co-developed-by: First Co-Author <first@coauthor.example.org>
+ Signed-off-by: First Co-Author <first@coauthor.example.org>
+ Co-developed-by: Second Co-Author <second@coauthor.example.org>
+ Signed-off-by: Second Co-Author <second@coauthor.example.org>
+ Signed-off-by: From Author <from@author.example.org>
+
+Esempio di una patch sottomessa dall'autore Co-developed-by:::
+
+ From: From Author <from@author.example.org>
+
+ <changelog>
+
+ Co-developed-by: Random Co-Author <random@coauthor.example.org>
+ Signed-off-by: Random Co-Author <random@coauthor.example.org>
+ Signed-off-by: From Author <from@author.example.org>
+ Co-developed-by: Submitting Co-Author <sub@coauthor.example.org>
+ Signed-off-by: Submitting Co-Author <sub@coauthor.example.org>
13) Utilizzare Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: e Fixes:
-----------------------------------------------------------------------------
@@ -719,7 +750,7 @@ Un paio di esempi di oggetti::
La riga ``from`` dev'essere la prima nel corpo del messaggio ed è nel
formato:
- From: Original Author <author@example.com>
+ From: Patch Author <author@example.com>
La riga ``from`` indica chi verrà accreditato nel changelog permanente come
l'autore della patch. Se la riga ``from`` è mancante, allora per determinare
diff --git a/Documentation/translations/ja_JP/SubmittingPatches b/Documentation/translations/ja_JP/SubmittingPatches
index 02139656463eb7bc86ff9ee054a1d1896518440c..ad979c3c06a6cc1b26bc90d95143ee23113688e8 100644
--- a/Documentation/translations/ja_JP/SubmittingPatches
+++ b/Documentation/translations/ja_JP/SubmittingPatches
@@ -58,8 +58,8 @@ Linux カーãƒãƒ«ã«å¯¾ã™ã‚‹å…¨ã¦ã®å¤‰æ›´ã¯ diff(1) コマンドã«ã‚ˆã‚‹
1個ã®ãƒ•ã‚¡ã‚¤ãƒ«ã«ã¤ã„ã¦ã®ãƒ‘ッãƒã‚’作æˆã™ã‚‹ãŸã‚ã«ã¯ã€ã»ã¨ã‚“ã©ã®å ´åˆã€
以下ã®ä½œæ¥ã‚’è¡Œãˆã°å分ã§ã™ã€‚
- SRCTREE= linux-2.6
- MYFILE= drivers/net/mydriver.c
+ SRCTREE=linux-2.6
+ MYFILE=drivers/net/mydriver.c
cd $SRCTREE
cp $MYFILE $MYFILE.orig
@@ -71,7 +71,7 @@ Linux カーãƒãƒ«ã«å¯¾ã™ã‚‹å…¨ã¦ã®å¤‰æ›´ã¯ diff(1) コマンドã«ã‚ˆã‚‹
ãªã‚ã¡å¤‰æ›´ã‚’åŠ ãˆã¦ãªã„ Linux カーãƒãƒ«ã‚’展開ã—ã€è‡ªåˆ†ã® Linux カーãƒãƒ«
ソースã¨ã®å·®åˆ†ã‚’生æˆã—ãªã„ã¨ã„ã‘ã¾ã›ã‚“。例ãˆã°ã€
- MYSRC= /devel/linux-2.6
+ MYSRC=/devel/linux-2.6
tar xvfz linux-2.6.12.tar.gz
mv linux-2.6.12 linux-2.6.12-vanilla
diff --git a/Documentation/translations/zh_CN/SubmittingPatches b/Documentation/translations/zh_CN/SubmittingPatches
deleted file mode 100644
index e9098da8f1a4febfe1cf99e7c12dbdaa934783ff..0000000000000000000000000000000000000000
--- a/Documentation/translations/zh_CN/SubmittingPatches
+++ /dev/null
@@ -1,412 +0,0 @@
-Chinese translated version of Documentation/process/submitting-patches.rst
-
-If you have any comment or update to the content, please contact the
-original document maintainer directly. However, if you have a problem
-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.
-
-Chinese maintainer: TripleX Chung <triplex@zh-kernel.org>
----------------------------------------------------------------------
-Documentation/process/submitting-patches.rst çš„ä¸æ–‡ç¿»è¯‘
-
-如果想评论或更新本文的内容，请直接è”ç³»åŽŸæ–‡æ¡£çš„ç»´æŠ¤è€…ã€‚å¦‚æžœä½ ä½¿ç”¨è‹±æ–‡
-交æµæœ‰å›°éš¾çš„è¯ï¼Œä¹Ÿå¯ä»¥å‘ä¸æ–‡ç‰ˆç»´æŠ¤è€…求助。如果本翻译更新ä¸åŠæ—¶æˆ–者翻
-译å˜åœ¨é—®é¢˜ï¼Œè¯·è”ç³»ä¸æ–‡ç‰ˆç»´æŠ¤è€…。
-
-ä¸æ–‡ç‰ˆç»´æŠ¤è€…： 钟宇 TripleX Chung <triplex@zh-kernel.org>
-ä¸æ–‡ç‰ˆç¿»è¯‘者： 钟宇 TripleX Chung <triplex@zh-kernel.org>
-ä¸æ–‡ç‰ˆæ ¡è¯‘者： æŽé˜³ Li Yang <leo@zh-kernel.org>
- çŽ‹èª Wang Cong <xiyou.wangcong@gmail.com>
-
-以下为æ£æ–‡
----------------------------------------------------------------------
-
- å¦‚ä½•è®©ä½ çš„æ”¹åŠ¨è¿›å…¥å†…æ ¸
- 或者
- 获得亲爱的 Linus Torvalds 的关注和处ç†
-----------------------------------
-
-对于想è¦å°†æ”¹åŠ¨æ交到 Linux å†…æ ¸çš„ä¸ªäººæˆ–è€…å…¬å¸æ¥è¯´ï¼Œå¦‚æžœä¸ç†Ÿæ‚‰â€œè§„矩â€ï¼Œ
-æ交的æµç¨‹ä¼šè®©äººç•æƒ§ã€‚本文档收集了一系列建议，这些建议å¯ä»¥å¤§å¤§çš„æ高ä½
-的改动被接å—的机会。
-阅读 Documentation/process/submit-checklist.rst æ¥èŽ·å¾—在æ交代ç å‰éœ€è¦æ£€æŸ¥çš„项目的列
-è¡¨ã€‚å¦‚æžœä½ åœ¨æ交一个驱动程åºï¼Œé‚£ä¹ˆåŒæ—¶é˜…读一下
-Documentation/process/submitting-drivers.rst 。
-
-
---------------------------
-第一节 - 创建并å‘é€ä½ 的改动
---------------------------
-
-1) "diff -up"
------------
-
-使用 "diff -up" 或者 "diff -uprN" æ¥åˆ›å»ºè¡¥ä¸ã€‚
-
-æ‰€æœ‰å†…æ ¸çš„æ”¹åŠ¨ï¼Œéƒ½æ˜¯ä»¥è¡¥ä¸çš„å½¢å¼å‘ˆçŽ°çš„，补ä¸ç”± diff(1) 生æˆã€‚创建补ä¸çš„
-时候，è¦ç¡®è®¤å®ƒæ˜¯ä»¥ "unified diff" æ ¼å¼åˆ›å»ºçš„，这ç§æ ¼å¼ç”± diff(1) çš„ '-u'
-å‚数生æˆã€‚而且，请使用 '-p' å‚æ•°ï¼Œé‚£æ ·ä¼šæ˜¾ç¤ºæ¯ä¸ªæ”¹åŠ¨æ‰€åœ¨çš„C函数，使得
-产生的补ä¸å®¹æ˜“读得多。补ä¸åº”è¯¥åŸºäºŽå†…æ ¸æºä»£ç æ ‘çš„æ ¹ç›®å½•ï¼Œè€Œä¸æ˜¯é‡Œè¾¹çš„ä»»
-何å目录。
-为一个å•ç‹¬çš„文件创建补ä¸ï¼Œä¸€èˆ¬æ¥è¯´è¿™æ ·åšå°±å¤Ÿäº†ï¼š
-
- SRCTREE= linux-2.6
- MYFILE= drivers/net/mydriver.c
-
- cd $SRCTREE
- cp $MYFILE $MYFILE.orig
- vi $MYFILE # make your change
- cd ..
- diff -up $SRCTREE/$MYFILE{.orig,} > /tmp/patch
-
-为多个文件创建补ä¸ï¼Œä½ å¯ä»¥è§£å¼€ä¸€ä¸ªæ²¡æœ‰ä¿®æ”¹è¿‡çš„å†…æ ¸æºä»£ç æ ‘ï¼Œç„¶åŽå’Œä½ 自
-己的代ç æ ‘ä¹‹é—´åš diff 。例如：
-
- MYSRC= /devel/linux-2.6
-
- tar xvfz linux-2.6.12.tar.gz
- mv linux-2.6.12 linux-2.6.12-vanilla
- diff -uprN -X linux-2.6.12-vanilla/Documentation/dontdiff \
- linux-2.6.12-vanilla $MYSRC > /tmp/patch
-
-"dontdiff" æ˜¯å†…æ ¸åœ¨ç¼–è¯‘çš„æ—¶å€™äº§ç”Ÿçš„æ–‡ä»¶çš„åˆ—è¡¨ï¼Œåˆ—è¡¨ä¸çš„文件在 diff(1)
-产生的补ä¸é‡Œä¼šè¢«è·³è¿‡ã€‚"dontdiff" 文件被包å«åœ¨2.6.12和之åŽç‰ˆæœ¬çš„å†…æ ¸æºä»£
-ç æ ‘ä¸ã€‚å¯¹äºŽæ›´æ—©çš„å†…æ ¸ç‰ˆæœ¬ï¼Œä½ å¯ä»¥ä»Ž
-<http://www.xenotime.net/linux/doc/dontdiff> 获å–它。
-ç¡®å®šä½ çš„è¡¥ä¸é‡Œæ²¡æœ‰åŒ…å«ä»»ä½•ä¸å±žäºŽè¿™æ¬¡è¡¥ä¸æ交的é¢å¤–文件。记得在用diff(1)
-生æˆè¡¥ä¸ä¹‹åŽï¼Œå®¡é˜…一次补ä¸ï¼Œä»¥ç¡®ä¿å‡†ç¡®ã€‚
-å¦‚æžœä½ çš„æ”¹åŠ¨å¾ˆæ•£ä¹±ï¼Œä½ åº”è¯¥ç ”ç©¶ä¸€ä¸‹å¦‚ä½•å°†è¡¥ä¸åˆ†å‰²æˆç‹¬ç«‹çš„部分，将改动分
-割æˆä¸€ç³»åˆ—åˆä¹Žé€»è¾‘çš„æ¥éª¤ã€‚è¿™æ ·æ›´å®¹æ˜“è®©å…¶ä»–å†…æ ¸å¼€å‘è€…å®¡æ ¸ï¼Œå¦‚æžœä½ æƒ³ä½ çš„
-è¡¥ä¸è¢«æŽ¥å—，这是很é‡è¦çš„。下é¢è¿™äº›è„šæœ¬èƒ½å¤Ÿå¸®åŠ©ä½ åšè¿™ä»¶äº‹æƒ…：
-Quilt:
-http://savannah.nongnu.org/projects/quilt
-
-2)æè¿°ä½ çš„æ”¹åŠ¨ã€‚
-æè¿°ä½ çš„æ”¹åŠ¨åŒ…å«çš„技术细节。
-
-è¦å¤šå…·ä½“就写多具体。最糟糕的æè¿°å¯èƒ½æ˜¯åƒä¸‹é¢è¿™äº›è¯å¥ï¼šâ€œæ›´æ–°äº†æŸé©±åŠ¨ç¨‹
-åºâ€ï¼Œâ€œä¿®æ£äº†æŸé©±åŠ¨ç¨‹åºçš„bugâ€ï¼Œæˆ–者“这个补ä¸åŒ…å«äº†æŸå系统的修改，请
-使用。â€
-
-å¦‚æžœä½ çš„æ述开始å˜é•¿ï¼Œè¿™è¡¨ç¤ºä½ 也许需è¦æ‹†åˆ†ä½ çš„è¡¥ä¸äº†ï¼Œè¯·çœ‹ç¬¬3å°èŠ‚，
-继ç»ã€‚
-
-3)æ‹†åˆ†ä½ çš„æ”¹åŠ¨
-
-将改动拆分，逻辑类似的放到åŒä¸€ä¸ªè¡¥ä¸æ–‡ä»¶é‡Œã€‚
-
-ä¾‹å¦‚ï¼Œå¦‚æžœä½ çš„æ”¹åŠ¨é‡ŒåŒæ—¶æœ‰bugä¿®æ£å’Œæ€§èƒ½ä¼˜åŒ–，那么把这些改动拆分到两个或
-者更多的补ä¸æ–‡ä»¶ä¸ã€‚å¦‚æžœä½ çš„æ”¹åŠ¨åŒ…å«å¯¹API的修改，并且修改了驱动程åºæ¥é€‚
-应这些新的API，那么把这些修改分æˆä¸¤ä¸ªè¡¥ä¸ã€‚
-
-å¦ä¸€æ–¹é¢ï¼Œå¦‚æžœä½ å°†ä¸€ä¸ªå•ç‹¬çš„改动åšæˆå¤šä¸ªè¡¥ä¸æ–‡ä»¶ï¼Œé‚£ä¹ˆå°†å®ƒä»¬åˆå¹¶æˆä¸€ä¸ª
-å•ç‹¬çš„è¡¥ä¸æ–‡ä»¶ã€‚è¿™æ ·ä¸€ä¸ªé€»è¾‘ä¸Šå•ç‹¬çš„改动åªè¢«åŒ…å«åœ¨ä¸€ä¸ªè¡¥ä¸æ–‡ä»¶é‡Œã€‚
-
-如果有一个补ä¸ä¾èµ–å¦å¤–一个补ä¸æ¥å®Œæˆå®ƒçš„改动，那没问题。简å•çš„åœ¨ä½ çš„è¡¥
-ä¸æ述里指出“这个补ä¸ä¾èµ–æŸè¡¥ä¸â€å°±å¥½äº†ã€‚
-
-å¦‚æžœä½ ä¸èƒ½å°†è¡¥ä¸æµ“缩æˆæ›´å°‘的文件，那么æ¯æ¬¡å¤§çº¦å‘é€å‡º15个，然åŽç‰å¾…审查
-和整åˆã€‚
-
-4)选择 e-mail 的收件人
-
-看一é MAINTAINERS 文件和æºä»£ç ï¼Œçœ‹çœ‹ä½ æ‰€çš„æ”¹åŠ¨æ‰€åœ¨çš„å†…æ ¸å系统有没有指
-定的维护者。如果有，给他们å‘e-mail。
-
-如果没有找到维护者，或者维护者没有åé¦ˆï¼Œå°†ä½ çš„è¡¥ä¸å‘é€åˆ°å†…æ ¸å¼€å‘者主邮
-件列表 linux-kernel@vger.kernel.orgã€‚å¤§éƒ¨åˆ†çš„å†…æ ¸å¼€å‘者都跟踪这个邮件列
-表，å¯ä»¥è¯„ä»·ä½ çš„æ”¹åŠ¨ã€‚
-
-æ¯æ¬¡ä¸è¦å‘é€è¶…过15个补ä¸åˆ° vger 邮件列表ï¼ï¼ï¼
-
-Linus Torvalds 是决定改动能å¦è¿›å…¥ Linux å†…æ ¸çš„æœ€ç»ˆè£å†³è€…。他的 e-mail
-地å€æ˜¯ <torvalds@linux-foundation.org> 。他收到的 e-mail 很多，所以一般
-çš„è¯´ï¼Œæœ€å¥½åˆ«ç»™ä»–å‘ e-mail。
-
-那些修æ£bug，“显而易è§â€çš„修改或者是类似的åªéœ€è¦å¾ˆå°‘讨论的补ä¸å¯ä»¥ç›´æŽ¥
-å‘é€æˆ–者CCç»™Linus。那些需è¦è®¨è®ºæˆ–者没有很清楚的好处的补ä¸ï¼Œä¸€èˆ¬å…ˆå‘é€åˆ°
-linux-kernel邮件列表。åªæœ‰å½“è¡¥ä¸è¢«è®¨è®ºå¾—å·®ä¸å¤šäº†ï¼Œæ‰æ交给Linus。
-
-5)选择CC( e-mail 抄é€)列表
-
-除éžä½ 有ç†ç”±ä¸è¿™æ ·åšï¼Œå¦åˆ™CC linux-kernel@vger.kernel.org。
-
-除了 Linus ä¹‹å¤–ï¼Œå…¶ä»–å†…æ ¸å¼€å‘者也需è¦æ³¨æ„åˆ°ä½ çš„æ”¹åŠ¨ï¼Œè¿™æ ·ä»–ä»¬æ‰èƒ½è¯„论ä½
-的改动并æ供代ç 审查和建议。linux-kernel 是 Linux å†…æ ¸å¼€å‘者主邮件列表
-。其它的邮件列表为特定的å系统æä¾›æœåŠ¡ï¼Œæ¯”如 USB，framebuffer 设备，虚
-拟文件系统，SCSI å系统，ç‰ç‰ã€‚查看 MAINTAINERS 文件æ¥èŽ·å¾—å’Œä½ çš„æ”¹åŠ¨æœ‰
-关的邮件列表。
-
-Majordomo lists of VGER.KERNEL.ORG at:
- <http://vger.kernel.org/vger-lists.html>
-
-如果改动影å“äº†ç”¨æˆ·ç©ºé—´å’Œå†…æ ¸ä¹‹é—´çš„æŽ¥å£ï¼Œè¯·ç»™ MAN-PAGES 的维护者（列在
-MAINTAINERS 文件里的）å‘é€ä¸€ä¸ªæ‰‹å†Œé¡µï¼ˆman-pages）补ä¸ï¼Œæˆ–者至少通知一下改
-å˜ï¼Œè®©ä¸€äº›ä¿¡æ¯æœ‰é€”径进入手册页。
-
-å³ä½¿åœ¨ç¬¬å››æ¥çš„时候，维护者没有作出回应，也è¦ç¡®è®¤åœ¨ä¿®æ”¹ä»–们的代ç 的时候
-，一直将维护者拷è´åˆ°CC列表ä¸ã€‚
-
-对于å°çš„è¡¥ä¸ï¼Œä½ 也许会CC到 Adrian Bunk 管ç†çš„æœé›†ç碎补ä¸çš„邮件列表
-(Trivial Patch Monkey)trivial@kernel.org，那里专门收集ç碎的补ä¸ã€‚下é¢è¿™æ ·
-çš„è¡¥ä¸ä¼šè¢«çœ‹ä½œâ€œç碎的â€è¡¥ä¸ï¼š
- 文档的拼写修æ£ã€‚
- ä¿®æ£ä¼šå½±å“到 grep(1) 的拼写。
- è¦å‘Šä¿¡æ¯ä¿®æ£(频ç¹çš„打å°æ— 用的è¦å‘Šæ˜¯ä¸å¥½çš„。)
- 编译错误修æ£ï¼ˆä»£ç 逻辑的确是对的，åªæ˜¯ç¼–译有问题。）
- è¿è¡Œæ—¶ä¿®æ£ï¼ˆåªè¦çœŸçš„ä¿®æ£äº†é”™è¯¯ã€‚）
- 移除使用了被废弃的函数/å®çš„代ç (例如 check_region。)
- è”系方å¼å’Œæ–‡æ¡£ä¿®æ£ã€‚
- 用å¯ç§»æ¤çš„代ç 替æ¢ä¸å¯ç§»æ¤çš„代ç （å³ä½¿åœ¨ä½“系结构相关的代ç ä¸ï¼Œæ—¢ç„¶æœ‰
- 人拷è´ï¼Œåªè¦å®ƒæ˜¯ç碎的）
- 任何文件的作者/维护者对该文件的改动（例如 patch monkey 在é‡ä¼ 模å¼ä¸‹ï¼‰
-
-EMAIL: trivial@kernel.org
-
-(译注，关于“ç碎补ä¸â€çš„ä¸€äº›è¯´æ˜Žï¼šå› ä¸ºåŽŸæ–‡çš„è¿™ä¸€éƒ¨åˆ†å†™å¾—æ¯”è¾ƒç®€å•ï¼Œæ‰€ä»¥ä¸å¾—ä¸
-è¿ä¾‹å†™ä¸€ä¸‹è¯‘注。"trivial"这个英文å•è¯çš„本æ„是“ç碎的，ä¸é‡è¦çš„。â€ä½†æ˜¯åœ¨è¿™é‡Œ
-有ç¨å¾®æœ‰ä¸€äº›å˜åŒ–，例如对一些明显的NULL指针的修æ£ï¼Œå±žäºŽè¿è¡Œæ—¶ä¿®æ£ï¼Œä¼šè¢«å½’ç±»
-到ç碎补ä¸é‡Œã€‚虽然NULL指针的修æ£å¾ˆé‡è¦ï¼Œä½†æ˜¯è¿™æ ·çš„ä¿®æ£å¾€å¾€å¾ˆå°è€Œä¸”很容易得到
-检验，所以也被归入ç碎补ä¸ã€‚ç碎补ä¸æ›´ç²¾ç¡®çš„归类应该是
-“simple, localized & easy to verifyâ€ï¼Œä¹Ÿå°±æ˜¯è¯´ç®€å•çš„，局部的和易于检验的。
-trivial@kernel.orgé‚®ä»¶åˆ—è¡¨çš„ç›®çš„æ˜¯é’ˆå¯¹è¿™æ ·çš„è¡¥ä¸ï¼Œä¸ºæ交者æ供一个ä¸å¿ƒï¼Œæ¥
-é™ä½Žæ交的门槛。)
-
-6)没有 MIME ç¼–ç ，没有链接，没有压缩，没有附件，åªæœ‰çº¯æ–‡æœ¬ã€‚
-
-Linus å’Œå…¶ä»–çš„å†…æ ¸å¼€å‘者需è¦é˜…è¯»å’Œè¯„è®ºä½ æäº¤çš„æ”¹åŠ¨ã€‚å¯¹äºŽå†…æ ¸å¼€å‘者æ¥è¯´
-，å¯ä»¥â€œå¼•ç”¨â€ä½ 的改动很é‡è¦ï¼Œä½¿ç”¨ä¸€èˆ¬çš„ e-mail 工具，他们就å¯ä»¥åœ¨ä½ çš„
-代ç 的任何ä½ç½®æ·»åŠ 评论。
-
-å› ä¸ºè¿™ä¸ªåŽŸå› ï¼Œæ‰€æœ‰çš„æ交的补ä¸éƒ½æ˜¯ e-mail ä¸â€œå†…嵌â€çš„。
-è¦å‘Šï¼šå¦‚æžœä½ ä½¿ç”¨å‰ªåˆ‡-ç²˜è´´ä½ çš„è¡¥ä¸ï¼Œå°å¿ƒä½ 的编辑器的自动æ¢è¡ŒåŠŸèƒ½ç ´åä½ çš„
-è¡¥ä¸ã€‚
-
-ä¸è¦å°†è¡¥ä¸ä½œä¸º MIME ç¼–ç 的附件，ä¸ç®¡æ˜¯å¦åŽ‹ç¼©ã€‚很多æµè¡Œçš„ e-mail 软件ä¸
-是任何时候都将 MIME ç¼–ç 的附件当作纯文本å‘é€çš„ï¼Œè¿™ä¼šä½¿å¾—åˆ«äººæ— æ³•åœ¨ä½ çš„
-代ç ä¸åŠ 评论。å¦å¤–，MIME ç¼–ç 的附件会让 Linus 多花一点时间æ¥å¤„ç†ï¼Œè¿™å°±
-é™ä½Žäº†ä½ 的改动被接å—çš„å¯èƒ½æ€§ã€‚
-
-è¦å‘Šï¼šä¸€äº›é‚®ä»¶è½¯ä»¶ï¼Œæ¯”如 Mozilla ä¼šå°†ä½ çš„ä¿¡æ¯ä»¥å¦‚ä¸‹æ ¼å¼å‘é€ï¼š
----- 邮件头 ----
-Content-Type: text/plain; charset=us-ascii; format=flowed
----- 邮件头 ----
-问题在于 “format=flowed†会让接收端的æŸäº›é‚®ä»¶è½¯ä»¶å°†é‚®ä»¶ä¸çš„制表符替æ¢
-æˆç©ºæ ¼ä»¥åŠåšä¸€äº›ç±»ä¼¼çš„替æ¢ã€‚è¿™æ ·ï¼Œä½ å‘é€çš„时候看起æ¥æ²¡é—®é¢˜çš„è¡¥ä¸å°±è¢«ç ´
-å了。
-
-è¦ä¿®æ£è¿™ä¸ªé—®é¢˜ï¼Œåªéœ€è¦å°†ä½ çš„ mozilla çš„ defaults/pref/mailnews.js 文件
-里的
-pref("mailnews.send_plaintext_flowed", false); // RFC 2646=======
-修改æˆ
-pref("mailnews.display.disable_format_flowed_support", true);
-å°±å¯ä»¥äº†ã€‚
-
-7) e-mail 的大å°
-
-ç»™ Linus å‘é€è¡¥ä¸çš„时候，永远按照第6å°èŠ‚说的åšã€‚
-
-大的改动对邮件列表ä¸åˆé€‚，对æŸäº›ç»´æŠ¤è€…也ä¸åˆé€‚ã€‚å¦‚æžœä½ çš„è¡¥ä¸ï¼Œåœ¨ä¸åŽ‹ç¼©
-的情况下，超过了40kBï¼Œé‚£ä¹ˆä½ æœ€å¥½å°†è¡¥ä¸æ”¾åœ¨ä¸€ä¸ªèƒ½é€šè¿‡ internet 访问的æœ
-务器上，然åŽç”¨æŒ‡å‘ä½ çš„è¡¥ä¸çš„ URL 替代。
-
-8) æŒ‡å‡ºä½ çš„å†…æ ¸ç‰ˆæœ¬
-
-åœ¨æ ‡é¢˜å’Œåœ¨è¡¥ä¸çš„æè¿°ä¸ï¼ŒæŒ‡å‡ºè¡¥ä¸å¯¹åº”çš„å†…æ ¸çš„ç‰ˆæœ¬ï¼Œæ˜¯å¾ˆé‡è¦çš„。
-
-如果补ä¸ä¸èƒ½å¹²å‡€çš„åœ¨æœ€æ–°ç‰ˆæœ¬çš„å†…æ ¸ä¸Šæ‰“ä¸Šï¼ŒLinus 是ä¸ä¼šæŽ¥å—它的。
-
-9) ä¸è¦æ°”é¦ï¼Œç»§ç»æ交。
-
-å½“ä½ æ交了改动以åŽï¼Œè€å¿ƒåœ°ç‰å¾…。如果 Linus å–œæ¬¢ä½ çš„æ”¹åŠ¨å¹¶ä¸”åŒæ„它，那么
-å®ƒå°†åœ¨ä¸‹ä¸€ä¸ªå†…æ ¸å‘布版本ä¸å‡ºçŽ°ã€‚
-
-ç„¶è€Œï¼Œå¦‚æžœä½ çš„æ”¹åŠ¨æ²¡æœ‰å‡ºçŽ°åœ¨ä¸‹ä¸€ä¸ªç‰ˆæœ¬çš„å†…æ ¸ä¸ï¼Œå¯èƒ½æœ‰è‹¥å¹²åŽŸå› 。å‡å°‘é‚£
-äº›åŽŸå› ï¼Œä¿®æ£é”™è¯¯ï¼Œé‡æ–°æ交更新åŽçš„æ”¹åŠ¨ï¼Œæ˜¯ä½ è‡ªå·±çš„å·¥ä½œã€‚
-
-Linusä¸ç»™å‡ºä»»ä½•è¯„论就“丢弃â€ä½ çš„è¡¥ä¸æ˜¯å¸¸è§çš„事情。在系统ä¸è¿™æ ·çš„事情很
-平常。如果他没有接å—ä½ çš„è¡¥ä¸ï¼Œä¹Ÿè®¸æ˜¯ç”±äºŽä»¥ä¸‹åŽŸå› ：
-* ä½ çš„è¡¥ä¸ä¸èƒ½åœ¨æœ€æ–°ç‰ˆæœ¬çš„å†…æ ¸ä¸Šå¹²å‡€çš„æ‰“ä¸Šã€‚
-* ä½ çš„è¡¥ä¸åœ¨ linux-kernel 邮件列表ä¸æ²¡æœ‰å¾—到充分的讨论。
-* é£Žæ ¼é—®é¢˜ï¼ˆå‚照第2å°èŠ‚）
-* é‚®ä»¶æ ¼å¼é—®é¢˜ï¼ˆé‡è¯»æœ¬èŠ‚）
-* ä½ çš„æ”¹åŠ¨æœ‰æŠ€æœ¯é—®é¢˜ã€‚
-* 他收到了æˆå¨çš„ e-mailï¼Œè€Œä½ çš„åœ¨æ··ä¹±ä¸ä¸¢å¤±äº†ã€‚
-* ä½ è®©äººä¸ºéš¾ã€‚
-
-有疑问的时候，在 linux-kernel 邮件列表上请求评论。
-
-10) åœ¨æ ‡é¢˜ä¸ŠåŠ ä¸Š PATCH çš„å—æ ·
-
-Linus å’Œ linux-kernel 邮件列表的 e-mail æµé‡éƒ½å¾ˆé«˜ï¼Œä¸€ä¸ªé€šå¸¸çš„çº¦å®šæ˜¯æ ‡
-题行以 [PATCH] å¼€å¤´ã€‚è¿™æ ·å¯ä»¥è®© Linus å’Œå…¶ä»–å†…æ ¸å¼€å‘人员å¯ä»¥ä»Ž e-mail
-的讨论ä¸å¾ˆè½»æ˜“的将补ä¸åˆ†è¾¨å‡ºæ¥ã€‚
-
-11ï¼‰ä¸ºä½ çš„å·¥ä½œç¾å
-
-ä¸ºäº†åŠ å¼ºå¯¹è°åšäº†ä½•äº‹çš„追踪，尤其是对那些é€è¿‡å¥½å‡ 层的维护者的补ä¸ï¼Œæˆ‘们
-建议在å‘é€å‡ºåŽ»çš„è¡¥ä¸ä¸ŠåŠ 一个 “sign-off†的过程。
-
-"sign-off" 是在补ä¸çš„注释的最åŽçš„简å•çš„一行文å—，认è¯ä½ 编写了它或者其他
-人有æƒåŠ›å°†å®ƒä½œä¸ºå¼€æ”¾æºä»£ç çš„è¡¥ä¸ä¼ 递。规则很简å•ï¼šå¦‚æžœä½ èƒ½è®¤è¯å¦‚下信æ¯
-：
- å¼€å‘者æ¥æºè¯ä¹¦ 1.1
- 对于本项目的贡献，我认è¯å¦‚下信æ¯ï¼š
- （a）这些贡献是完全或者部分的由我创建，我有æƒåˆ©ä»¥æ–‡ä»¶ä¸æŒ‡å‡º
- 的开放æºä»£ç 许å¯è¯æ交它；或者
- （b）这些贡献基于以å‰çš„工作，æ®æˆ‘所知，这些以å‰çš„工作å—æ°å½“的开放
- æºä»£ç 许å¯è¯ä¿æŠ¤ï¼Œè€Œä¸”ï¼Œæ ¹æ®è®¸å¯è¯ï¼Œæˆ‘有æƒæ交修改åŽçš„贡献，
- æ— è®ºæ˜¯å®Œå…¨è¿˜æ˜¯éƒ¨åˆ†ç”±æˆ‘åˆ›é€ ï¼Œè¿™äº›è´¡çŒ®éƒ½ä½¿ç”¨åŒä¸€ä¸ªå¼€æ”¾æºä»£ç 许å¯è¯
- （除éžæˆ‘被å…许用其它的许å¯è¯ï¼‰ï¼Œæ£å¦‚文件ä¸æŒ‡å‡ºçš„；或者
- （c）这些贡献由认è¯ï¼ˆa），（b）或者（c）的人直接æ供给我，而
- 且我没有修改它。
- （d）我ç†è§£å¹¶åŒæ„这个项目和贡献是公开的，贡献的记录（包括我
- 一起æ交的个人记录，包括 sign-off ）被永久维护并且å¯ä»¥å’Œè¿™ä¸ªé¡¹ç›®
- 或者开放æºä»£ç 的许å¯è¯åŒæ¥åœ°å†å‘行。
- é‚£ä¹ˆåŠ å…¥è¿™æ ·ä¸€è¡Œï¼š
- Signed-off-by: Random J Developer <random@developer.example.org>
-
-ä½¿ç”¨ä½ çš„çœŸå（抱æ‰ï¼Œä¸èƒ½ä½¿ç”¨å‡å或者匿å。）
-
-有人在最åŽåŠ ä¸Šæ ‡ç¾ã€‚çŽ°åœ¨è¿™äº›ä¸œè¥¿ä¼šè¢«å¿½ç•¥ï¼Œä½†æ˜¯ä½ å¯ä»¥è¿™æ ·åšï¼Œæ¥æ ‡è®°å…¬å¸
-内部的过程，或者åªæ˜¯æŒ‡å‡ºå…³äºŽ sign-off 的一些特殊细节。
-
-12ï¼‰æ ‡å‡†è¡¥ä¸æ ¼å¼
-
-æ ‡å‡†çš„è¡¥ä¸ï¼Œæ ‡é¢˜è¡Œæ˜¯ï¼š
- Subject: [PATCH 001/123] å系统:一å¥è¯æ¦‚è¿°
-
-æ ‡å‡†è¡¥ä¸çš„信体å˜åœ¨å¦‚下部分：
-
- - 一个 "from" 行指出补ä¸ä½œè€…。
-
- - 一个空行
-
- - 说明的主体，这些说明文å—会被拷è´åˆ°æ述该补ä¸çš„永久改动记录里。
-
- - 一个由"---"æž„æˆçš„æ ‡è®°è¡Œ
-
- - ä¸åˆé€‚放到改动记录里的é¢å¤–的注解。
-
- - è¡¥ä¸æœ¬èº«ï¼ˆdiff 输出）
-
-æ ‡é¢˜è¡Œçš„æ ¼å¼ï¼Œä½¿å¾—å¯¹æ ‡é¢˜è¡ŒæŒ‰å—æ¯åºæŽ’åºéžå¸¸çš„容易 - 很多 e-mail 客户端都
-å¯ä»¥æ”¯æŒ - å› ä¸ºåºåˆ—å·æ˜¯ç”¨é›¶å¡«å……的，所以按数å—排åºå’ŒæŒ‰å—æ¯æŽ’åºæ˜¯ä¸€æ ·çš„。
-
-e-mail æ ‡é¢˜ä¸çš„“å系统â€æ ‡è¯†å“ªä¸ªå†…æ ¸å系统将被打补ä¸ã€‚
-
-e-mail æ ‡é¢˜ä¸çš„“一å¥è¯æ¦‚è¿°â€æ‰¼è¦çš„æè¿° e-mail ä¸çš„è¡¥ä¸ã€‚“一å¥è¯æ¦‚è¿°â€
-ä¸åº”该是一个文件å。对于一个补ä¸ç³»åˆ—（“补ä¸ç³»åˆ—â€æŒ‡ä¸€ç³»åˆ—的多个相关补
-ä¸ï¼‰ï¼Œä¸è¦å¯¹æ¯ä¸ªè¡¥ä¸éƒ½ä½¿ç”¨åŒæ ·çš„“一å¥è¯æ¦‚è¿°â€ã€‚
-
-è®°ä½ e-mail 的“一å¥è¯æ¦‚è¿°â€ä¼šæˆä¸ºè¯¥è¡¥ä¸çš„å…¨å±€å”¯ä¸€æ ‡è¯†ã€‚å®ƒä¼šè”“å»¶åˆ° git
-的改动记录里。然åŽâ€œä¸€å¥è¯æ¦‚è¿°â€ä¼šè¢«ç”¨åœ¨å¼€å‘者的讨论里，用æ¥æŒ‡ä»£è¿™ä¸ªè¡¥
-ä¸ã€‚用户将希望通过 google æ¥æœç´¢"一å¥è¯æ¦‚è¿°"æ¥æ‰¾åˆ°é‚£äº›è®¨è®ºè¿™ä¸ªè¡¥ä¸çš„æ–‡
-ç« ã€‚
-
-ä¸€äº›æ ‡é¢˜çš„ä¾‹å：
-
- Subject: [patch 2/5] ext2: improve scalability of bitmap searching
- Subject: [PATCHv2 001/207] x86: fix eflags tracking
-
-"from" 行是信体里的最上é¢ä¸€è¡Œï¼Œå…·æœ‰å¦‚ä¸‹æ ¼å¼ï¼š
- From: Original Author <author@example.com>
-
-"from" 行指明在永久改动日志里，è°ä¼šè¢«ç¡®è®¤ä¸ºä½œè€…。如果没有 "from" 行，那
-么邮件头里的 "From: " 行会被用æ¥å†³å®šæ”¹åŠ¨æ—¥å¿—ä¸çš„作者。
-
-说明的主题将会被æ交到永久的æºä»£ç æ”¹åŠ¨æ—¥å¿—é‡Œï¼Œå› æ¤å¯¹é‚£äº›æ—©å·²ç»ä¸è®°å¾—å’Œ
-这个补ä¸ç›¸å…³çš„讨论细节的有能力的读者æ¥è¯´ï¼Œæ˜¯æœ‰æ„义的。
-
-"---" æ ‡è®°è¡Œå¯¹äºŽè¡¥ä¸å¤„ç†å·¥å…·è¦æ‰¾åˆ°å“ªé‡Œæ˜¯æ”¹åŠ¨æ—¥å¿—ä¿¡æ¯çš„结æŸï¼Œæ˜¯ä¸å¯ç¼ºå°‘
-的。
-
-对于 "---" æ ‡è®°ä¹‹åŽçš„é¢å¤–注解，一个好的用途就是用æ¥å†™ diffstat，用æ¥æ˜¾
-示修改了什么文件和æ¯ä¸ªæ–‡ä»¶éƒ½å¢žåŠ å’Œåˆ é™¤äº†å¤šå°‘è¡Œã€‚diffstat 对于比较大的补
-ä¸ç‰¹åˆ«æœ‰ç”¨ã€‚其余那些åªæ˜¯å’Œæ—¶åˆ»æˆ–者开å‘者相关的注解，ä¸åˆé€‚放到永久的改
-动日志里的，也应该放这里。
-使用 diffstat的选项 "-p 1 -w 70" è¿™æ ·æ–‡ä»¶åå°±ä¼šä»Žå†…æ ¸æºä»£ç æ ‘çš„ç›®å½•å¼€å§‹
-，ä¸ä¼šå 用太宽的空间（很容易适åˆ80列的宽度，也许会有一些缩进。）
-
-在åŽé¢çš„å‚考资料ä¸èƒ½çœ‹åˆ°é€‚当的补ä¸æ ¼å¼çš„更多细节。
-
--------------------------------
-第二节 æ示，建议和诀çª
--------------------------------
-
-本节包å«å¾ˆå¤šå’Œæäº¤åˆ°å†…æ ¸çš„ä»£ç 有关的通常的"规则"。事情永远有例外...但是
-ä½ å¿…é¡»çœŸçš„æœ‰å¥½çš„ç†ç”±è¿™æ ·åšã€‚ä½ å¯ä»¥æŠŠæœ¬èŠ‚å«åšLinus的计算机科å¦å…¥é—¨è¯¾ã€‚
-
-1) 读 Document/process/coding-style.rst
-
-Nuff è¯´è¿‡ï¼Œå¦‚æžœä½ çš„ä»£ç 和这个å离太多，那么它有å¯èƒ½ä¼šè¢«æ‹’ç»ï¼Œæ²¡æœ‰æ›´å¤šçš„
-审查，没有更多的评价。
-
-2) #ifdef 是丑陋的
-æ··æ‚了 ifdef 的代ç éš¾ä»¥é˜…è¯»å’Œç»´æŠ¤ã€‚åˆ«è¿™æ ·åšã€‚ä½œä¸ºæ›¿ä»£ï¼Œå°†ä½ çš„ ifdef 放
-在头文件里，有æ¡ä»¶åœ°å®šä¹‰ "static inline" 函数，或者å®ï¼Œåœ¨ä»£ç 里用这些东
-西。让编译器把那些"空æ“作"优化掉。
-
-一个简å•çš„例å，ä¸å¥½çš„代ç ：
-
- dev = alloc_etherdev (sizeof(struct funky_private));
- if (!dev)
- return -ENODEV;
- #ifdef CONFIG_NET_FUNKINESS
- init_funky_net(dev);
- #endif
-
-清ç†åŽçš„例å:
-
-(头文件里)
- #ifndef CONFIG_NET_FUNKINESS
- static inline void init_funky_net (struct net_device *d) {}
- #endif
-
-(代ç 文件里)
- dev = alloc_etherdev (sizeof(struct funky_private));
- if (!dev)
- return -ENODEV;
- init_funky_net(dev);
-
-3) 'static inline' 比å®å¥½
-
-Static inline 函数相比å®æ¥è¯´ï¼Œæ˜¯å¥½å¾—多的选择。Static inline 函数æ供了
-类型安全，没有长度é™åˆ¶ï¼Œæ²¡æœ‰æ ¼å¼é™åˆ¶ï¼Œåœ¨ gcc 下开销和å®ä¸€æ ·å°ã€‚
-
-å®åªåœ¨ static inline 函数ä¸æ˜¯æœ€ä¼˜çš„时候[在 fast paths 里有很少的独立的
-案例]，或者ä¸å¯èƒ½ç”¨ static inline 函数的时候[例如å—符串分é…]。
-应该用 'static inline' 而ä¸æ˜¯ 'static __inline__', 'extern inline' å’Œ
-'extern __inline__' 。
-
-4) ä¸è¦è¿‡åº¦è®¾è®¡
-
-ä¸è¦è¯•å›¾é¢„计模糊的未æ¥äº‹æƒ…，这些事情也许有用也许没有用："让事情尽å¯èƒ½çš„
-简å•ï¼Œè€Œä¸æ˜¯æ›´ç®€å•"。
-
-----------------
-第三节 å‚考文献
-----------------
-
-Andrew Morton, "The perfect patch" (tpp).
- <http://www.ozlabs.org/~akpm/stuff/tpp.txt>
-
-Jeff Garzik, "Linux kernel patch submission format".
- <http://linux.yyz.us/patch-format.html>
-
-Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
- <http://www.kroah.com/log/2005/03/31/>
- <http://www.kroah.com/log/2005/07/08/>
- <http://www.kroah.com/log/2005/10/19/>
- <http://www.kroah.com/log/2006/01/11/>
-
-NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
- <https://lkml.org/lkml/2005/7/11/336>
-
-Kernel Documentation/process/coding-style.rst:
- <http://sosdg.org/~coywolf/lxr/source/Documentation/process/coding-style.rst>
-
-Linus Torvalds's mail on the canonical patch format:
- <http://lkml.org/lkml/2005/4/7/183>
---
diff --git a/Documentation/translations/zh_CN/disclaimer-zh_CN.rst b/Documentation/translations/zh_CN/disclaimer-zh_CN.rst
new file mode 100644
index 0000000000000000000000000000000000000000..dcf803ede85a180511761c8866f9dcc7c43377fa
--- /dev/null
+++ b/Documentation/translations/zh_CN/disclaimer-zh_CN.rst
@@ -0,0 +1,9 @@
+:orphan:
+
+.. warning::
+ æ¤æ–‡ä»¶çš„目的是为让ä¸æ–‡è¯»è€…更容易阅读和ç†è§£ï¼Œè€Œä¸æ˜¯ä½œä¸ºä¸€ä¸ªåˆ†æ”¯ã€‚ å› æ¤ï¼Œ
+ 如果您对æ¤æ–‡ä»¶æœ‰ä»»ä½•æ„è§æˆ–更新，请先å°è¯•æ›´æ–°åŽŸå§‹è‹±æ–‡æ–‡ä»¶ã€‚
+
+.. note::
+ 如果您å‘现本文档与原始文件有任何ä¸åŒæˆ–者有翻译问题，请è”系该文件的译者，
+ 或者请求时奎亮的帮助：<alex.shi@linux.alibaba.com>。
diff --git a/Documentation/translations/zh_CN/index.rst b/Documentation/translations/zh_CN/index.rst
index 75956d669962c6efa99b674d58e6fbf3de3c737f..d3165535ec9e5a40624dbf44e2f6efc3fd30c2b3 100644
--- a/Documentation/translations/zh_CN/index.rst
+++ b/Documentation/translations/zh_CN/index.rst
@@ -3,10 +3,19 @@
\renewcommand\thesection*
\renewcommand\thesubsection*
-Chinese translations
-====================
+ä¸æ–‡ç¿»è¯‘
+========
+
+这些手册包å«æœ‰å…³å¦‚何开å‘å†…æ ¸çš„æ•´ä½“ä¿¡æ¯ã€‚å†…æ ¸ç¤¾åŒºéžå¸¸åºžå¤§ï¼Œä¸€å¹´ä¸‹æ¥æœ‰æ•°åƒåå¼€å‘
+人员åšå‡ºè´¡çŒ®ã€‚ ä¸Žä»»ä½•å¤§åž‹ç¤¾åŒºä¸€æ ·ï¼ŒçŸ¥é“如何完æˆä»»åŠ¡å°†ä½¿å¾—更改åˆå¹¶çš„过程å˜å¾—æ›´
+åŠ å®¹æ˜“ã€‚
.. toctree::
- :maxdepth: 1
+ :maxdepth: 2
+
+ process/index
+
+ç›®å½•å’Œè¡¨æ ¼
+----------
- coding-style
+* :ref:`genindex`
diff --git a/Documentation/translations/zh_CN/magic-number.txt b/Documentation/translations/zh_CN/magic-number.txt
deleted file mode 100644
index 7159cec04090d8f0243090b18a53f227a942e4e1..0000000000000000000000000000000000000000
--- a/Documentation/translations/zh_CN/magic-number.txt
+++ /dev/null
@@ -1,153 +0,0 @@
-Chinese translated version of Documentation/process/magic-number.rst
-
-If you have any comment or update to the content, please post to LKML directly.
-However, if you have problem communicating in English you can also ask the
-Chinese maintainer for help. Contact the Chinese maintainer, if this
-translation is outdated or there is problem with translation.
-
-Chinese maintainer: Jia Wei Wei <harryxiyou@gmail.com>
----------------------------------------------------------------------
-Documentation/process/magic-number.rstçš„ä¸æ–‡ç¿»è¯‘
-
-如果想评论或更新本文的内容，请直接å‘信到LKMLã€‚å¦‚æžœä½ ä½¿ç”¨è‹±æ–‡äº¤æµæœ‰å›°éš¾çš„è¯ï¼Œä¹Ÿå¯
-以å‘ä¸æ–‡ç‰ˆç»´æŠ¤è€…求助。如果本翻译更新ä¸åŠæ—¶æˆ–者翻译å˜åœ¨é—®é¢˜ï¼Œè¯·è”ç³»ä¸æ–‡ç‰ˆç»´æŠ¤è€…。
-
-ä¸æ–‡ç‰ˆç»´æŠ¤è€…： è´¾å¨å¨ Jia Wei Wei <harryxiyou@gmail.com>
-ä¸æ–‡ç‰ˆç¿»è¯‘者： è´¾å¨å¨ Jia Wei Wei <harryxiyou@gmail.com>
-ä¸æ–‡ç‰ˆæ ¡è¯‘者： è´¾å¨å¨ Jia Wei Wei <harryxiyou@gmail.com>
-
-以下为æ£æ–‡
----------------------------------------------------------------------
-这个文件是有关当å‰ä½¿ç”¨çš„é”æœ¯å€¼æ³¨å†Œè¡¨ã€‚å½“ä½ ç»™ä¸€ä¸ªç»“æž„æ·»åŠ äº†ä¸€ä¸ªé”æœ¯å€¼ï¼Œä½ ä¹Ÿåº”è¯¥æŠŠè¿™ä¸ªé”æœ¯å€¼æ·»åŠ åˆ°è¿™ä¸ªæ–‡ä»¶ï¼Œå› ä¸ºæˆ‘ä»¬æœ€å¥½æŠŠç”¨äºŽå„ç§ç»“æž„çš„é”术值统一起æ¥ã€‚
-
-使用é”术值æ¥ä¿æŠ¤å†…æ ¸æ•°æ®ç»“构是一个éžå¸¸å¥½çš„主æ„。这就å…è®¸ä½ åœ¨è¿è¡ŒæœŸæ£€æŸ¥(a)一个结构是å¦å·²ç»è¢«æ”»å‡»ï¼Œæˆ–者(b)ä½ å·²ç»ç»™ä¸€ä¸ªä¾‹è¡Œç¨‹åºé€šè¿‡äº†ä¸€ä¸ªé”™è¯¯çš„结构。åŽä¸€ç§æƒ…况特别地有用---ç‰¹åˆ«æ˜¯å½“ä½ é€šè¿‡ä¸€ä¸ªç©ºæŒ‡é’ˆæŒ‡å‘结构体的时候。ttyæºç ，例如，ç»å¸¸é€šè¿‡ç‰¹å®šé©±åŠ¨ä½¿ç”¨è¿™ç§æ–¹æ³•å¹¶ä¸”åå¤åœ°æŽ’列特定方é¢çš„结构。
-
-使用é”术值的方法是在结构的开始处声明的，如下：
-
-struct tty_ldisc {
- int magic;
- ...
-};
-
-å½“ä½ ä»¥åŽç»™å†…æ ¸æ·»åŠ å¢žå¼ºåŠŸèƒ½çš„æ—¶å€™ï¼Œè¯·éµå®ˆè¿™æ¡è§„则ï¼è¿™æ ·å°±ä¼šèŠ‚çœæ•°ä¸æ¸…的调试时间，特别是一些å¤æ€ªçš„情况，例如，数组超出范围并且é‡æ–°å†™äº†è¶…出部分。éµå®ˆè¿™ä¸ªè§„则，‪这些情况å¯ä»¥è¢«å¿«é€Ÿåœ°ï¼Œå®‰å…¨åœ°é¿å…。
-
- Theodore Ts'o
- 31 Mar 94
-
-给当å‰çš„Linux 2.1.55æ·»åŠ é”术表。
-
- Michael Chastain
- <mailto:mec@shout.net>
- 22 Sep 1997
-
-现在应该最新的Linux 2.1.112.å› ä¸ºåœ¨ç‰¹æ€§å†»ç»“æœŸé—´ï¼Œä¸èƒ½åœ¨2.2.xå‰æ”¹å˜ä»»ä½•ä¸œè¥¿ã€‚这些æ¡ç›®è¢«æ•°åŸŸæ‰€æŽ’åºã€‚
-
- Krzysztof G.Baranowski
- <mailto: kgb@knm.org.pl>
- 29 Jul 1998
-
-æ›´æ–°é”术表到Linux 2.5.45。刚好越过特性冻结，但是有å¯èƒ½è¿˜ä¼šæœ‰ä¸€äº›æ–°çš„é”术值在2.6.x之å‰èžå…¥åˆ°å†…æ ¸ä¸ã€‚
-
- Petr Baudis
- <pasky@ucw.cz>
- 03 Nov 2002
-
-æ›´æ–°é”术表到Linux 2.5.74。
-
- Fabian Frederick
- <ffrederick@users.sourceforge.net>
- 09 Jul 2003
-
-é”术å åœ°å€ ç»“æž„ 所在文件
-===========================================================================
-PG_MAGIC 'P' pg_{read,write}_hdr include/linux/pg.h
-CMAGIC 0x0111 user include/linux/a.out.h
-MKISS_DRIVER_MAGIC 0x04bf mkiss_channel drivers/net/mkiss.h
-HDLC_MAGIC 0x239e n_hdlc drivers/char/n_hdlc.c
-APM_BIOS_MAGIC 0x4101 apm_user arch/x86/kernel/apm_32.c
-CYCLADES_MAGIC 0x4359 cyclades_port include/linux/cyclades.h
-DB_MAGIC 0x4442 fc_info drivers/net/iph5526_novram.c
-DL_MAGIC 0x444d fc_info drivers/net/iph5526_novram.c
-FASYNC_MAGIC 0x4601 fasync_struct include/linux/fs.h
-FF_MAGIC 0x4646 fc_info drivers/net/iph5526_novram.c
-ISICOM_MAGIC 0x4d54 isi_port include/linux/isicom.h
-PTY_MAGIC 0x5001 drivers/char/pty.c
-PPP_MAGIC 0x5002 ppp include/linux/if_pppvar.h
-SERIAL_MAGIC 0x5301 async_struct include/linux/serial.h
-SSTATE_MAGIC 0x5302 serial_state include/linux/serial.h
-SLIP_MAGIC 0x5302 slip drivers/net/slip.h
-STRIP_MAGIC 0x5303 strip drivers/net/strip.c
-X25_ASY_MAGIC 0x5303 x25_asy drivers/net/x25_asy.h
-SIXPACK_MAGIC 0x5304 sixpack drivers/net/hamradio/6pack.h
-AX25_MAGIC 0x5316 ax_disp drivers/net/mkiss.h
-TTY_MAGIC 0x5401 tty_struct include/linux/tty.h
-MGSL_MAGIC 0x5401 mgsl_info drivers/char/synclink.c
-TTY_DRIVER_MAGIC 0x5402 tty_driver include/linux/tty_driver.h
-MGSLPC_MAGIC 0x5402 mgslpc_info drivers/char/pcmcia/synclink_cs.c
-TTY_LDISC_MAGIC 0x5403 tty_ldisc include/linux/tty_ldisc.h
-USB_SERIAL_MAGIC 0x6702 usb_serial drivers/usb/serial/usb-serial.h
-FULL_DUPLEX_MAGIC 0x6969 drivers/net/ethernet/dec/tulip/de2104x.c
-USB_BLUETOOTH_MAGIC 0x6d02 usb_bluetooth drivers/usb/class/bluetty.c
-RFCOMM_TTY_MAGIC 0x6d02 net/bluetooth/rfcomm/tty.c
-USB_SERIAL_PORT_MAGIC 0x7301 usb_serial_port drivers/usb/serial/usb-serial.h
-CG_MAGIC 0x00090255 ufs_cylinder_group include/linux/ufs_fs.h
-RPORT_MAGIC 0x00525001 r_port drivers/char/rocket_int.h
-LSEMAGIC 0x05091998 lse drivers/fc4/fc.c
-GDTIOCTL_MAGIC 0x06030f07 gdth_iowr_str drivers/scsi/gdth_ioctl.h
-RIEBL_MAGIC 0x09051990 drivers/net/atarilance.c
-NBD_REQUEST_MAGIC 0x12560953 nbd_request include/linux/nbd.h
-RED_MAGIC2 0x170fc2a5 (any) mm/slab.c
-BAYCOM_MAGIC 0x19730510 baycom_state drivers/net/baycom_epp.c
-ISDN_X25IFACE_MAGIC 0x1e75a2b9 isdn_x25iface_proto_data
- drivers/isdn/isdn_x25iface.h
-ECP_MAGIC 0x21504345 cdkecpsig include/linux/cdk.h
-LSOMAGIC 0x27091997 lso drivers/fc4/fc.c
-LSMAGIC 0x2a3b4d2a ls drivers/fc4/fc.c
-WANPIPE_MAGIC 0x414C4453 sdla_{dump,exec} include/linux/wanpipe.h
-CS_CARD_MAGIC 0x43525553 cs_card sound/oss/cs46xx.c
-LABELCL_MAGIC 0x4857434c labelcl_info_s include/asm/ia64/sn/labelcl.h
-ISDN_ASYNC_MAGIC 0x49344C01 modem_info include/linux/isdn.h
-CTC_ASYNC_MAGIC 0x49344C01 ctc_tty_info drivers/s390/net/ctctty.c
-ISDN_NET_MAGIC 0x49344C02 isdn_net_local_s drivers/isdn/i4l/isdn_net_lib.h
-SAVEKMSG_MAGIC2 0x4B4D5347 savekmsg arch/*/amiga/config.c
-CS_STATE_MAGIC 0x4c4f4749 cs_state sound/oss/cs46xx.c
-SLAB_C_MAGIC 0x4f17a36d kmem_cache mm/slab.c
-COW_MAGIC 0x4f4f4f4d cow_header_v1 arch/um/drivers/ubd_user.c
-I810_CARD_MAGIC 0x5072696E i810_card sound/oss/i810_audio.c
-TRIDENT_CARD_MAGIC 0x5072696E trident_card sound/oss/trident.c
-ROUTER_MAGIC 0x524d4157 wan_device [in wanrouter.h pre 3.9]
-SAVEKMSG_MAGIC1 0x53415645 savekmsg arch/*/amiga/config.c
-GDA_MAGIC 0x58464552 gda arch/mips/include/asm/sn/gda.h
-RED_MAGIC1 0x5a2cf071 (any) mm/slab.c
-EEPROM_MAGIC_VALUE 0x5ab478d2 lanai_dev drivers/atm/lanai.c
-HDLCDRV_MAGIC 0x5ac6e778 hdlcdrv_state include/linux/hdlcdrv.h
-PCXX_MAGIC 0x5c6df104 channel drivers/char/pcxx.h
-KV_MAGIC 0x5f4b565f kernel_vars_s arch/mips/include/asm/sn/klkernvars.h
-I810_STATE_MAGIC 0x63657373 i810_state sound/oss/i810_audio.c
-TRIDENT_STATE_MAGIC 0x63657373 trient_state sound/oss/trident.c
-M3_CARD_MAGIC 0x646e6f50 m3_card sound/oss/maestro3.c
-FW_HEADER_MAGIC 0x65726F66 fw_header drivers/atm/fore200e.h
-SLOT_MAGIC 0x67267321 slot drivers/hotplug/cpqphp.h
-SLOT_MAGIC 0x67267322 slot drivers/hotplug/acpiphp.h
-LO_MAGIC 0x68797548 nbd_device include/linux/nbd.h
-OPROFILE_MAGIC 0x6f70726f super_block drivers/oprofile/oprofilefs.h
-M3_STATE_MAGIC 0x734d724d m3_state sound/oss/maestro3.c
-VMALLOC_MAGIC 0x87654320 snd_alloc_track sound/core/memory.c
-KMALLOC_MAGIC 0x87654321 snd_alloc_track sound/core/memory.c
-PWC_MAGIC 0x89DC10AB pwc_device drivers/usb/media/pwc.h
-NBD_REPLY_MAGIC 0x96744668 nbd_reply include/linux/nbd.h
-ENI155_MAGIC 0xa54b872d midway_eprom drivers/atm/eni.h
-CODA_MAGIC 0xC0DAC0DA coda_file_info include/linux/coda_fs_i.h
-DPMEM_MAGIC 0xc0ffee11 gdt_pci_sram drivers/scsi/gdth.h
-YAM_MAGIC 0xF10A7654 yam_port drivers/net/hamradio/yam.c
-CCB_MAGIC 0xf2691ad2 ccb drivers/scsi/ncr53c8xx.c
-QUEUE_MAGIC_FREE 0xf7e1c9a3 queue_entry drivers/scsi/arm/queue.c
-QUEUE_MAGIC_USED 0xf7e1cc33 queue_entry drivers/scsi/arm/queue.c
-HTB_CMAGIC 0xFEFAFEF1 htb_class net/sched/sch_htb.c
-NMI_MAGIC 0x48414d4d455201 nmi_s arch/mips/include/asm/sn/nmi.h
-
-请注æ„，在声音记忆管ç†ä¸ä»ç„¶æœ‰ä¸€äº›ç‰¹æ®Šçš„为æ¯ä¸ªé©±åŠ¨å®šä¹‰çš„é”术值。查看include/sound/sndmagic.hæ¥èŽ·å–他们完整的列表信æ¯ã€‚很多OSS声音驱动拥有自己从声å¡PCI ID构建的é”术值-他们也没有被列在这里。
-
-IrDAå系统也使用了大é‡çš„自己的é”术值，查看include/net/irda/irda.hæ¥èŽ·å–他们完整的信æ¯ã€‚
-
-HFS是å¦å¤–一个比较大的使用é”术值的文件系统-ä½ å¯ä»¥åœ¨fs/hfs/hfs.hä¸æ‰¾åˆ°ä»–们。
diff --git a/Documentation/translations/zh_CN/oops-tracing.txt b/Documentation/translations/zh_CN/oops-tracing.txt
index a893f04dfd5d5fbb22468cc5fe77223ab644667e..93fa061cf9e4f51572c5aa9a63b7f6b509ab99cc 100644
--- a/Documentation/translations/zh_CN/oops-tracing.txt
+++ b/Documentation/translations/zh_CN/oops-tracing.txt
@@ -16,7 +16,7 @@ Documentation/admin-guide/bug-hunting.rst çš„ä¸æ–‡ç¿»è¯‘
ä¸æ–‡ç‰ˆç»´æŠ¤è€…： æ¨ç‘ž Dave Young <hidave.darkstar@gmail.com>
ä¸æ–‡ç‰ˆç¿»è¯‘者： æ¨ç‘ž Dave Young <hidave.darkstar@gmail.com>
-ä¸æ–‡ç‰ˆæ ¡è¯‘者： æŽé˜³ Li Yang <leo@zh-kernel.org>
+ä¸æ–‡ç‰ˆæ ¡è¯‘者： æŽé˜³ Li Yang <leoyang.li@nxp.com>
çŽ‹èª Wang Cong <xiyou.wangcong@gmail.com>
以下为æ£æ–‡
diff --git a/Documentation/translations/zh_CN/process/1.Intro.rst b/Documentation/translations/zh_CN/process/1.Intro.rst
new file mode 100644
index 0000000000000000000000000000000000000000..10a15f3dc28203cc24fe9e511c31ee3ffe604d53
--- /dev/null
+++ b/Documentation/translations/zh_CN/process/1.Intro.rst
@@ -0,0 +1,186 @@
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: :ref:`Documentation/process/1.Intro.rst <development_process_intro>`
+:Translator: Alex Shi <alex.shi@linux.alibaba.com>
+
+.. _cn_development_process_intro:
+
+介ç»
+====
+
+执行摘è¦
+--------
+
+æœ¬èŠ‚çš„å…¶ä½™éƒ¨åˆ†æ¶µç›–äº†å†…æ ¸å¼€å‘过程的范围，以åŠå¼€å‘人员åŠå…¶é›‡ä¸»åœ¨è¿™æ–¹é¢å¯èƒ½é‡
+到的å„ç§æŒ«æŠ˜ã€‚å†…æ ¸ä»£ç 应该åˆå¹¶åˆ°æ£å¼çš„（“主线â€ï¼‰å†…æ ¸ä¸æœ‰å¾ˆå¤šåŽŸå› ，包括对用
+户的自动å¯ç”¨æ€§ã€å¤šç§å½¢å¼çš„社区支æŒä»¥åŠå½±å“å†…æ ¸å¼€å‘æ–¹å‘的能力。æ供给Linux
+å†…æ ¸çš„ä»£ç 必须在与GPL兼容的许å¯è¯ä¸‹å¯ç”¨ã€‚
+
+:ref:`cn_development_process` 介ç»äº†å¼€å‘过程ã€å†…æ ¸å‘布周期和åˆå¹¶çª—å£çš„机制。
+涵盖了补ä¸å¼€å‘ã€å®¡æŸ¥å’Œåˆå¹¶å‘¨æœŸä¸çš„å„个阶段。有一些关于工具和邮件列表的讨论。
+é¼“åŠ±å¸Œæœ›å¼€å§‹å†…æ ¸å¼€å‘çš„å¼€å‘人员作为åˆå§‹ç»ƒä¹ 跟踪并修å¤bug。
+
+
+:ref:`cn_development_early_stage` 包括早期项目规划，é‡ç‚¹æ˜¯å°½å¿«è®©å¼€å‘社区å‚与
+
+:ref:`cn_development_coding` 是关于编ç 过程的；讨论了其他开å‘人员é‡åˆ°çš„å‡ ä¸ª
+陷阱。对补ä¸çš„一些è¦æ±‚å·²ç»æ¶µç›–，并且介ç»äº†ä¸€äº›å·¥å…·ï¼Œè¿™äº›å·¥å…·æœ‰åŠ©äºŽç¡®ä¿å†…æ ¸
+è¡¥ä¸æ˜¯æ£ç¡®çš„。
+
+:ref:`cn_development_posting` 讨论å‘布补ä¸ä»¥ä¾›è¯„审的过程。为了让开å‘社区
+认真对待，补ä¸å¿…é¡»æ£ç¡®æ ¼å¼åŒ–å’Œæ述，并且必须å‘é€åˆ°æ£ç¡®çš„地方。éµå¾ªæœ¬èŠ‚ä¸çš„
+建议有助于确ä¿ä¸ºæ‚¨çš„工作æ供最好的接纳。
+
+:ref:`cn_development_followthrough` 介ç»äº†å‘布补ä¸ä¹‹åŽå‘生的事情；该工作
+在这一点上还远远没有完æˆã€‚与审阅者一起工作是开å‘过程ä¸çš„一个é‡è¦éƒ¨åˆ†ï¼›æœ¬èŠ‚
+æ供了一些关于如何在这个é‡è¦é˜¶æ®µé¿å…问题的æ示。当补ä¸è¢«åˆå¹¶åˆ°ä¸»çº¿ä¸æ—¶ï¼Œ
+å¼€å‘人员è¦æ³¨æ„ä¸è¦å‡å®šä»»åŠ¡å·²ç»å®Œæˆã€‚
+
+:ref:`cn_development_advancedtopics` 介ç»äº†ä¸¤ä¸ªâ€œé«˜çº§â€ä¸»é¢˜ï¼š
+使用Git管ç†è¡¥ä¸å’ŒæŸ¥çœ‹å…¶ä»–人å‘布的补ä¸ã€‚
+
+:ref:`cn_development_conclusion` æ€»ç»“äº†æœ‰å…³å†…æ ¸å¼€å‘的更多信æ¯ï¼Œé™„带有带有
+指å‘资æºçš„链接.
+
+这个文件是关于什么的
+--------------------
+
+Linuxå†…æ ¸æœ‰è¶…è¿‡800万行代ç ，æ¯ä¸ªç‰ˆæœ¬çš„贡献者超过1000人，是现å˜æœ€å¤§ã€æœ€æ´»è·ƒ
+çš„å…费软件项目之一。从1991å¹´å¼€å§‹ï¼Œè¿™ä¸ªå†…æ ¸å·²ç»å‘展æˆä¸ºä¸€ä¸ªæœ€å¥½çš„æ“作系统
+组件，è¿è¡Œåœ¨è¢–çæ•°å—音ä¹æ’放器ã€å°å¼PCã€çŽ°å˜æœ€å¤§çš„超级计算机以åŠæ‰€æœ‰ç±»åž‹çš„
+系统上。它是一ç§é€‚ç”¨äºŽå‡ ä¹Žä»»ä½•æƒ…å†µçš„å¥å£®ã€é«˜æ•ˆå’Œå¯æ‰©å±•çš„解决方案。
+
+éšç€Linuxçš„å‘展，希望å‚与其开å‘çš„å¼€å‘人员（和公å¸ï¼‰çš„æ•°é‡ä¹Ÿåœ¨å¢žåŠ 。硬件供应商
+希望确ä¿Linux能够很好地支æŒä»–们的产å“，使这些产å“对Linux用户具有å¸å¼•åŠ›ã€‚嵌入
+å¼ç³»ç»Ÿä¾›åº”商使用Linux作为集æˆäº§å“的组件，希望Linux能够尽å¯èƒ½åœ°èƒœä»»æ‰‹å¤´çš„任务。
+分销商和其他基于Linux的软件供应商对Linuxå†…æ ¸çš„åŠŸèƒ½ã€æ€§èƒ½å’Œå¯é 性有ç€æ˜Žç¡®çš„
+兴趣。最终用户也常常希望修改Linux，使之更好地满足他们的需求。
+
+Linux最引人注目的特性之一是这些开å‘人员å¯ä»¥è®¿é—®å®ƒï¼›ä»»ä½•å…·å¤‡å¿…è¦æŠ€èƒ½çš„人都å¯ä»¥
+改进Linux并影å“其开å‘æ–¹å‘。专有产å“ä¸èƒ½æ供这ç§å¼€æ”¾æ€§ï¼Œè¿™æ˜¯è‡ªç”±è½¯ä»¶çš„一个特点。
+但是，如果有什么ä¸åŒçš„è¯ï¼Œå†…æ ¸æ¯”å¤§å¤šæ•°å…¶ä»–è‡ªç”±è½¯ä»¶é¡¹ç›®æ›´å¼€æ”¾ã€‚ä¸€ä¸ªå…¸åž‹çš„ä¸‰ä¸ªæœˆ
+å†…æ ¸å¼€å‘周期å¯ä»¥æ¶‰åŠ1000多个开å‘人员，他们为100多个ä¸åŒçš„å…¬å¸
+ï¼ˆæˆ–è€…æ ¹æœ¬æ²¡æœ‰å…¬å¸ï¼‰å·¥ä½œã€‚
+
+ä¸Žå†…æ ¸å¼€å‘社区åˆä½œå¹¶ä¸æ˜¯ç‰¹åˆ«å›°éš¾ã€‚但是，尽管如æ¤ï¼Œè®¸å¤šæ½œåœ¨çš„贡献者在å°è¯•åš
+å†…æ ¸å·¥ä½œæ—¶é‡åˆ°äº†å›°éš¾ã€‚å†…æ ¸ç¤¾åŒºå·²ç»å‘展了自己独特的æ“作方å¼ï¼Œä½¿å…¶èƒ½å¤Ÿåœ¨æ¯å¤©
+都è¦æ›´æ”¹æ•°åƒè¡Œä»£ç 的环境ä¸é¡ºåˆ©è¿è¡Œï¼ˆå¹¶ç”Ÿæˆé«˜è´¨é‡çš„产å“ï¼‰ã€‚å› æ¤ï¼ŒLinuxå†…æ ¸å¼€å‘
+过程与专有的开å‘方法有很大的ä¸åŒä¹Ÿå°±ä¸è¶³ä¸ºå¥‡äº†ã€‚
+
+对于新开å‘人员æ¥è¯´ï¼Œå†…æ ¸çš„å¼€å‘过程å¯èƒ½ä¼šè®©äººæ„Ÿåˆ°å¥‡æ€ªå’Œæ惧，但这个背åŽæœ‰å……分的
+ç†ç”±å’Œåšå®žçš„ç»éªŒã€‚一个ä¸äº†è§£å†…æ ¸ç¤¾åŒºçš„æ–¹å¼çš„å¼€å‘人员（或者更糟的是，他们试图
+抛弃或规é¿å†…æ ¸ç¤¾åŒºçš„æ–¹å¼ï¼‰ä¼šæœ‰ä¸€ä¸ªä»¤äººæ²®ä¸§çš„体验。开å‘社区, 在帮助那些试图å¦ä¹
+的人的åŒæ—¶ï¼Œæ²¡æœ‰æ—¶é—´å¸®åŠ©é‚£äº›ä¸æ„¿æ„倾å¬æˆ–ä¸å…³å¿ƒå¼€å‘过程的人。
+
+希望阅读本文的人能够é¿å…è¿™ç§ä»¤äººæ²®ä¸§çš„ç»åŽ†ã€‚这里有很多æ料，但阅读时所åšçš„
+努力会在çŸæ—¶é—´å†…得到回报。开å‘社区总是需è¦èƒ½è®©å†…æ ¸å˜æ›´å¥½çš„å¼€å‘人员；下é¢çš„
+æ–‡æœ¬åº”è¯¥å¸®åŠ©æ‚¨æˆ–ä¸ºæ‚¨å·¥ä½œçš„äººå‘˜åŠ å…¥æˆ‘ä»¬çš„ç¤¾åŒºã€‚
+
+致谢
+----
+
+本文件由Jonathan Corbet撰写，corbet@lwn.net。以下人员的建议使之更为完善：
+Johannes Berg, James Berry, Alex Chiang, Roland Dreier, Randy Dunlap,
+Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh, Amanda McPherson,
+Andrew Morton, Andrew Price, Tsugikazu Shibata, 和 Jochen Voß.
+
+这项工作得到了Linux基金会的支æŒï¼Œç‰¹åˆ«æ„Ÿè°¢Amanda McPherson，他看到了这项工作
+的价值并把它å˜æˆçŽ°å®žã€‚
+
+代ç 进入主线的é‡è¦æ€§
+--------------------
+
+有些公å¸å’Œå¼€å‘人员å¶å°”会想，为什么他们è¦è´¹å¿ƒå¦ä¹ å¦‚ä½•ä¸Žå†…æ ¸ç¤¾åŒºåˆä½œï¼Œå¹¶å°†ä»£ç
+æ”¾å…¥ä¸»çº¿å†…æ ¸ï¼ˆâ€œä¸»çº¿â€æ˜¯ç”±Linus Torvaldsç»´æŠ¤çš„å†…æ ¸ï¼ŒLinuxå‘行商将其用作基础）。
+在çŸæœŸå†…，贡献代ç 看起æ¥åƒæ˜¯ä¸€ç§å¯ä»¥é¿å…的开销；仅仅将代ç 分开并直接支æŒç”¨æˆ·
+似乎更容易。事实上，ä¿æŒä»£ç ç‹¬ç«‹ï¼ˆâ€œæ ‘å¤–â€ï¼‰æ˜¯åœ¨ç»æµŽä¸Šæ˜¯é”™è¯¯çš„。
+
+ä½œä¸ºè¯´æ˜Žæ ‘å¤–ä»£ç æˆæœ¬çš„一ç§æ–¹æ³•ï¼Œä¸‹é¢æ˜¯å†…æ ¸å¼€å‘过程的一些相关方é¢ï¼›æœ¬æ–‡ç¨åŽå°†
+更详细地讨论其ä¸çš„大部分内容。考虑：
+
+- 所有Linux用户都å¯ä»¥ä½¿ç”¨åˆå¹¶åˆ°ä¸»çº¿å†…æ ¸ä¸çš„代ç 。它将自动出现在所有å¯ç”¨å®ƒçš„
+ å‘行版上。ä¸éœ€è¦é©±åŠ¨ç¨‹åºç£ç›˜ã€ä¸‹è½½ï¼Œä¹Ÿä¸éœ€è¦ä¸ºå¤šä¸ªå‘行版的多个版本æ供支æŒï¼›
+ 对于开å‘人员和用户æ¥è¯´ï¼Œè¿™ä¸€åˆ‡éƒ½æ˜¯å¯è¡Œçš„。并入主线解决了大é‡çš„分布和支æŒé—®é¢˜
+
+- å½“å†…æ ¸å¼€å‘人员努力维护一个稳定的用户空间接å£æ—¶ï¼Œå†…éƒ¨å†…æ ¸API处于ä¸æ–å˜åŒ–之ä¸.
+ 缺ä¹ä¸€ä¸ªç¨³å®šçš„内部接å£æ˜¯ä¸€ä¸ªæ·±æ€ç†Ÿè™‘的设计决ç–；它å…许在任何时候进行基本的改
+ 进，并产生更高质é‡çš„代ç 。但该ç–略的一个结果是，如果è¦ä½¿ç”¨æ–°çš„å†…æ ¸ï¼Œä»»ä½•æ ‘å¤–
+ 代ç 都需è¦æŒç»çš„ç»´æŠ¤ã€‚ç»´æŠ¤æ ‘å¤–ä»£ç 需è¦å¤§é‡çš„工作æ‰èƒ½ä½¿ä»£ç ä¿æŒå·¥ä½œçŠ¶æ€ã€‚
+
+ 相å，ä½äºŽä¸»çº¿ä¸çš„代ç ä¸éœ€è¦è¿™æ ·åšï¼Œå› 为一个简å•çš„规则è¦æ±‚进行API更改的任何
+ å¼€å‘人员也必须修å¤ç”±äºŽè¯¥æ›´æ”¹è€Œç ´å的任何代ç ã€‚å› æ¤ï¼Œåˆå¹¶åˆ°ä¸»çº¿ä¸çš„代ç 大大
+ é™ä½Žäº†ç»´æŠ¤æˆæœ¬ã€‚
+
+- 除æ¤ä¹‹å¤–ï¼Œå†…æ ¸ä¸çš„代ç 通常会被其他开å‘人员改进。令人惊讶的结果å¯èƒ½æ¥è‡ªæŽˆæƒ
+ 您的用户社区和客户改进您的产å“。
+
+- å†…æ ¸ä»£ç 在åˆå¹¶åˆ°ä¸»çº¿ä¹‹å‰å’Œä¹‹åŽéƒ½è¦ç»è¿‡å®¡æŸ¥ã€‚ä¸ç®¡åŽŸå§‹å¼€å‘人员的技能有多强，
+ 这个审查过程总是能找到改进代ç 的方法。审查ç»å¸¸å‘现严é‡çš„错误和安全问题。
+ 这对于在å°é—环境ä¸å¼€å‘的代ç 尤其如æ¤ï¼›è¿™ç§ä»£ç 从外部开å‘人员的审查ä¸èŽ·ç›Š
+ åŒªæµ…ã€‚æ ‘å¤–ä»£ç 是低质é‡ä»£ç 。
+
+- å‚与开å‘过程是您影å“å†…æ ¸å¼€å‘æ–¹å‘çš„æ–¹å¼ã€‚æ—观者的抱怨会被å¬åˆ°ï¼Œä½†æ˜¯æ´»è·ƒçš„
+ å¼€å‘äººå‘˜æœ‰æ›´å¼ºçš„å£°éŸ³â€”â€”å¹¶ä¸”èƒ½å¤Ÿå®žçŽ°ä½¿å†…æ ¸æ›´å¥½åœ°æ»¡è¶³å…¶éœ€æ±‚çš„æ›´æ”¹ã€‚
+
+- 当å•ç‹¬ç»´æŠ¤ä»£ç 时，总是å˜åœ¨ç¬¬ä¸‰æ–¹ä¸ºç±»ä¼¼åŠŸèƒ½æä¾›ä¸åŒå®žçŽ°çš„å¯èƒ½æ€§ã€‚如果å‘生
+ è¿™ç§æƒ…况，åˆå¹¶ä»£ç å°†å˜å¾—æ›´åŠ å›°éš¾â€”â€”ç”šè‡³åˆ°äº†ä¸å¯èƒ½çš„地æ¥ã€‚然åŽï¼Œæ‚¨å°†é¢ä¸´ä»¥ä¸‹
+ 令人ä¸å¿«çš„选择：（1ï¼‰æ— é™æœŸåœ°ç»´æŠ¤æ ‘外的éžæ ‡å‡†ç‰¹æ€§ï¼Œæˆ–（2）放弃代ç 并将用户
+ è¿ç§»åˆ°æ ‘内版本。
+
+- 代ç çš„è´¡çŒ®æ˜¯ä½¿æ•´ä¸ªè¿‡ç¨‹å·¥ä½œçš„æ ¹æœ¬ã€‚é€šè¿‡è´¡çŒ®ä»£ç ，您å¯ä»¥å‘å†…æ ¸æ·»åŠ æ–°åŠŸèƒ½ï¼Œå¹¶
+ æä¾›å…¶ä»–å†…æ ¸å¼€å‘人员使用的功能和示例。如果您已ç»ä¸ºLinuxå¼€å‘了代ç （或者
+ æ£åœ¨è€ƒè™‘è¿™æ ·åšï¼‰ï¼Œé‚£ä¹ˆæ‚¨æ˜¾ç„¶å¯¹è¿™ä¸ªå¹³å°çš„æŒç»æˆåŠŸæ„Ÿå…´è¶£ï¼›è´¡çŒ®ä»£ç 是确ä¿æˆåŠŸ
+ 的最好方法之一。
+
+上述所有ç†ç”±éƒ½é€‚ç”¨äºŽä»»ä½•æ ‘å¤–å†…æ ¸ä»£ç ，包括以专有的ã€ä»…二进制形å¼åˆ†å‘的代ç 。
+ç„¶è€Œï¼Œåœ¨è€ƒè™‘ä»»ä½•ç±»åž‹çš„çº¯äºŒè¿›åˆ¶å†…æ ¸ä»£ç 分布之å‰ï¼Œè¿˜éœ€è¦è€ƒè™‘å…¶ä»–å› ç´ ã€‚è¿™äº›åŒ…æ‹¬ï¼š
+
+- å›´ç»•ä¸“æœ‰å†…æ ¸æ¨¡å—分å‘的法律问题充其é‡æ˜¯æ¨¡ç³Šçš„ï¼›ç›¸å½“å¤šçš„å†…æ ¸ç‰ˆæƒæ‰€æœ‰è€…认为，
+ 大多数仅é™äºŒè¿›åˆ¶çš„模å—æ˜¯å†…æ ¸çš„æ´¾ç”Ÿäº§å“ï¼Œå› æ¤ï¼Œå®ƒä»¬çš„分å‘è¿å了GNU通用公共
+ 许å¯è¯ï¼ˆä¸‹é¢å°†è¯¦ç»†ä»‹ç»ï¼‰ã€‚您的作者ä¸æ˜¯å¾‹å¸ˆï¼Œæœ¬æ–‡æ¡£ä¸çš„任何内容都ä¸å¯èƒ½è¢«
+ 视为法律建议。å°é—æºä»£ç 模å—的真实法律地ä½åªèƒ½ç”±æ³•é™¢å†³å®šã€‚但ä¸ç®¡æ€Žæ ·ï¼Œå›°æ‰°
+ 这些模å—çš„ä¸ç¡®å®šæ€§ä»ç„¶å˜åœ¨ã€‚
+
+- 二进制模å—å¤§å¤§å¢žåŠ äº†è°ƒè¯•å†…æ ¸é—®é¢˜çš„éš¾åº¦ï¼Œä»¥è‡³äºŽå¤§å¤šæ•°å†…æ ¸å¼€å‘人员甚至都ä¸ä¼š
+ å°è¯•ã€‚å› æ¤ï¼Œåªåˆ†å‘二进制模å—将使您的用户更难从社区获得支æŒã€‚
+
+- 对于åªæ”¯æŒäºŒè¿›åˆ¶çš„模å—çš„å‘行者æ¥è¯´ï¼Œæ”¯æŒä¹Ÿæ›´åŠ 困难，他们必须为他们希望支æŒ
+ çš„æ¯ä¸ªå‘行版和æ¯ä¸ªå†…æ ¸ç‰ˆæœ¬æ供一个版本的模å—。为了æ供相当全é¢çš„覆盖范围，
+ å¯èƒ½éœ€è¦ä¸€ä¸ªæ¨¡å—çš„å‡ å个构建，并且æ¯æ¬¡å‡çº§å†…æ ¸æ—¶ï¼Œæ‚¨çš„ç”¨æˆ·éƒ½å¿…é¡»å•ç‹¬å‡çº§
+ 您的模å—。
+
+- 上é¢æ到的关于代ç è¯„å®¡çš„æ‰€æœ‰é—®é¢˜éƒ½æ›´åŠ å˜åœ¨äºŽå°é—æºä»£ç 。由于该代ç æ ¹æœ¬ä¸å¯
+ ç”¨ï¼Œå› æ¤ç¤¾åŒºæ— æ³•å¯¹å…¶è¿›è¡Œå®¡æŸ¥ï¼Œæ¯«æ— ç–‘é—®ï¼Œå®ƒå°†å˜åœ¨ä¸¥é‡é—®é¢˜ã€‚
+
+尤其是嵌入å¼ç³»ç»Ÿçš„åˆ¶é€ å•†ï¼Œå¯èƒ½ä¼šå€¾å‘于忽视本节ä¸æ‰€è¯´çš„å¤§éƒ¨åˆ†å†…å®¹ï¼Œå› ä¸ºä»–ä»¬
+相信自己æ£åœ¨å•†ç”¨ä¸€ç§ä½¿ç”¨å†»ç»“å†…æ ¸ç‰ˆæœ¬çš„ç‹¬ç«‹äº§å“，在å‘布åŽä¸éœ€è¦å†è¿›è¡Œå¼€å‘。
+这个论点忽略了广泛的代ç 审查的价值以åŠå…许用户å‘产å“æ·»åŠ åŠŸèƒ½çš„ä»·å€¼ã€‚ä½†è¿™äº›
+产å“也有有é™çš„商业寿命，之åŽå¿…é¡»å‘布新版本的产å“。在这一点上，代ç 在主线上
+并得到良好维护的供应商将能够更好地å ä½ï¼Œä»¥ä½¿æ–°äº§å“快速上市。
+
+许å¯
+----
+
+代ç æ˜¯æ ¹æ®ä¸€äº›è®¸å¯è¯æ供给Linuxå†…æ ¸çš„ï¼Œä½†æ˜¯æ‰€æœ‰ä»£ç 都必须与GNU通用公共许å¯
+è¯ï¼ˆGPLV2）的版本2å…¼å®¹ï¼Œè¯¥ç‰ˆæœ¬æ˜¯è¦†ç›–æ•´ä¸ªå†…æ ¸åˆ†å‘的许å¯è¯ã€‚在实践ä¸ï¼Œè¿™æ„味
+ç€æ‰€æœ‰ä»£ç 贡献都由GPLv2（å¯é€‰åœ°ï¼Œè¯è¨€å…许在更高版本的GPL下分å‘）或3åå¥BSD
+许å¯ï¼ˆNew BSD License, 译者注）覆盖。任何ä¸åŒ…å«åœ¨å…¼å®¹è®¸å¯è¯ä¸çš„贡献都ä¸ä¼š
+被接å—åˆ°å†…æ ¸ä¸ã€‚
+
+è´¡çŒ®ç»™å†…æ ¸çš„ä»£ç ä¸éœ€è¦ï¼ˆæˆ–请求）版æƒåˆ†é…。åˆå¹¶åˆ°ä¸»çº¿å†…æ ¸ä¸çš„所有代ç 都ä¿ç•™
+其原始所有æƒï¼›å› æ¤ï¼Œå†…æ ¸çŽ°åœ¨æ‹¥æœ‰æ•°åƒä¸ªæ‰€æœ‰è€…。
+
+è¿™ç§æ‰€æœ‰æƒç»“构的一个暗示是，任何改å˜å†…æ ¸è®¸å¯çš„å°è¯•éƒ½æ³¨å®šä¼šå¤±è´¥ã€‚很少有实际
+的场景å¯ä»¥èŽ·å¾—所有版æƒæ‰€æœ‰è€…çš„åŒæ„ï¼ˆæˆ–è€…ä»Žå†…æ ¸ä¸åˆ 除他们的代ç ï¼‰ã€‚å› æ¤ï¼Œç‰¹
+别是，在å¯é¢„è§çš„å°†æ¥ï¼Œä¸å¯èƒ½è¿ç§»åˆ°GPL的版本3。
+
+æ‰€æœ‰è´¡çŒ®ç»™å†…æ ¸çš„ä»£ç 都必须是åˆæ³•çš„å…è´¹è½¯ä»¶ã€‚å› æ¤ï¼Œä¸æŽ¥å—匿å（或匿å）贡献
+者的代ç 。所有贡献者都需è¦åœ¨ä»–们的代ç 上“sign offâ€ï¼Œå£°æ˜Žä»£ç å¯ä»¥åœ¨GPL下与内
+æ ¸ä¸€èµ·åˆ†å‘ã€‚æ— æ³•æ供未被其所有者许å¯ä¸ºå…费软件的代ç ，或å¯èƒ½ä¸ºå†…æ ¸é€ æˆç‰ˆæƒ
+相关问题的代ç （例如，由缺ä¹é€‚当ä¿æŠ¤çš„åå‘工程工作派生的代ç ）ä¸èƒ½è¢«æŽ¥å—。
+
+有关版æƒç›¸å…³é—®é¢˜çš„问题在Linuxå¼€å‘邮件列表ä¸å¾ˆå¸¸è§ã€‚è¿™æ ·çš„é—®é¢˜é€šå¸¸ä¼šå¾—åˆ°ä¸å°‘
+ç”案，但è¦è®°ä½ï¼Œå›žç”这些问题的人ä¸æ˜¯å¾‹å¸ˆï¼Œä¸èƒ½æ供法律咨询。如果您有关于
+Linuxæºä»£ç 的法律问题，那么与了解该领域的律师交æµæ˜¯æ— 法替代的。ä¾é 从技术
+邮件列表ä¸èŽ·å¾—çš„ç”案是一件冒险的事情。
+
diff --git a/Documentation/translations/zh_CN/process/2.Process.rst b/Documentation/translations/zh_CN/process/2.Process.rst
new file mode 100644
index 0000000000000000000000000000000000000000..ceb733bb0294e3ce54d1f3d16315ce8ce14af58f
--- /dev/null
+++ b/Documentation/translations/zh_CN/process/2.Process.rst
@@ -0,0 +1,360 @@
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: :ref:`Documentation/process/2.Process.rst <development_process>`
+:Translator: Alex Shi <alex.shi@linux.alibaba.com>
+
+.. _cn_development_process:
+
+å¼€å‘æµç¨‹å¦‚何工作
+================
+
+90年代早期的Linuxå†…æ ¸å¼€å‘是一件相当æ¾æ•£çš„事情，涉åŠçš„用户和开å‘人员相对较
+少。由于拥有数以百万计的用户群，并且在一年的时间里有大约2000åå¼€å‘人员å‚与
+è¿›æ¥ï¼Œå†…æ ¸å› æ¤å¿…é¡»å‘展许多æµç¨‹æ¥ä¿æŒå¼€å‘的顺利进行。è¦æˆä¸ºæµç¨‹çš„有效组æˆ
+部分，需è¦å¯¹æµç¨‹çš„工作方å¼æœ‰ä¸€ä¸ªæ‰Žå®žçš„ç†è§£ã€‚
+
+总览
+----
+
+å†…æ ¸å¼€å‘人员使用一个æ¾æ•£çš„基于时间的å‘布过程，æ¯ä¸¤åˆ°ä¸‰ä¸ªæœˆå‘布一次新的主è¦
+å†…æ ¸ç‰ˆæœ¬ã€‚æœ€è¿‘çš„å‘布历å²è®°å½•å¦‚下：
+
+ ====== =================
+ 4.11 四月 30, 2017
+ 4.12 七月 2, 2017
+ 4.13 ä¹æœˆ 3, 2017
+ 4.14 å一月 12, 2017
+ 4.15 一月 28, 2018
+ 4.16 四月 1, 2018
+ ====== =================
+
+æ¯4.x版本都是一个主è¦çš„å†…æ ¸ç‰ˆæœ¬ï¼Œå…·æœ‰æ–°ç‰¹æ€§ã€å†…部API更改ç‰ç‰ã€‚一个典型的4.x
+版本包å«å¤§çº¦13000个å˜æ›´é›†ï¼Œå˜æ›´äº†å‡ å万行代ç ã€‚å› æ¤ï¼Œ4.x是Linuxå†…æ ¸å¼€å‘çš„å‰
+æ²¿ï¼›å†…æ ¸ä½¿ç”¨æ»šåŠ¨å¼€å‘模型，ä¸æ–集æˆé‡å¤§å˜åŒ–。
+
+对于æ¯ä¸ªç‰ˆæœ¬çš„è¡¥ä¸åˆå¹¶ï¼Œéµå¾ªä¸€ä¸ªç›¸å¯¹ç®€å•çš„规则。在æ¯ä¸ªå¼€å‘周期的开始，“åˆå¹¶
+窗å£â€è¢«æ‰“开。当时，被认为足够稳定（并且被开å‘社区接å—）的代ç 被åˆå¹¶åˆ°ä¸»çº¿å†…
+æ ¸ä¸ã€‚在这段时间内，新开å‘周期的大部分å˜æ›´ï¼ˆä»¥åŠæ‰€æœ‰ä¸»è¦å˜æ›´ï¼‰å°†ä»¥æŽ¥è¿‘æ¯å¤©
+1000次å˜æ›´ï¼ˆâ€œè¡¥ä¸â€æˆ–“å˜æ›´é›†â€ï¼‰çš„速度åˆå¹¶ã€‚
+
+（顺便说一å¥ï¼Œå€¼å¾—注æ„的是，åˆå¹¶çª—å£æœŸé—´é›†æˆçš„更改并ä¸æ˜¯å‡ç©ºäº§ç”Ÿçš„；它们是
+æå‰æ”¶é›†ã€æµ‹è¯•å’Œåˆ†çº§çš„。ç¨åŽå°†è¯¦ç»†æ述该过程的工作方å¼ï¼‰ã€‚
+
+åˆå¹¶çª—å£æŒç»å¤§çº¦ä¸¤å‘¨ã€‚在这段时间结æŸæ—¶ï¼ŒLinusTorvalds将声明窗å£å·²å…³é—，并
+释放第一个“rcâ€å†…æ ¸ã€‚ä¾‹å¦‚ï¼Œå¯¹äºŽç›®æ ‡ä¸º4.14çš„å†…æ ¸ï¼Œåœ¨åˆå¹¶çª—å£ç»“æŸæ—¶å‘生的释放
+将被称为4.14-rc1。RC1版本是一个信å·ï¼Œè¡¨ç¤ºåˆå¹¶æ–°ç‰¹æ€§çš„时间已ç»è¿‡åŽ»ï¼Œç¨³å®šä¸‹ä¸€
+ä¸ªå†…æ ¸çš„æ—¶é—´å·²ç»å¼€å§‹ã€‚
+
+在接下æ¥çš„6到10周内，åªæœ‰ä¿®å¤é—®é¢˜çš„è¡¥ä¸æ‰åº”该æ交给主线。有时会å…许更大的
+更改，但这ç§æƒ…况很少å‘生；试图在åˆå¹¶çª—å£å¤–åˆå¹¶æ–°åŠŸèƒ½çš„å¼€å‘人员往往会å—到ä¸
+å‹å¥½çš„接待。一般æ¥è¯´ï¼Œå¦‚果您错过了给定特性的åˆå¹¶çª—å£ï¼Œæœ€å¥½çš„åšæ³•æ˜¯ç‰å¾…下一
+个开å‘周期。（对于以å‰ä¸æ”¯æŒçš„硬件，å¶å°”会对驱动程åºè¿›è¡Œä¾‹å¤–；如果它们ä¸
+改å˜å·²æœ‰ä»£ç ，则ä¸ä¼šå¯¼è‡´å›žå½’，并且应该å¯ä»¥éšæ—¶å®‰å…¨åœ°æ·»åŠ ）。
+
+éšç€ä¿®å¤ç¨‹åºè¿›å…¥ä¸»çº¿ï¼Œè¡¥ä¸é€Ÿåº¦å°†éšç€æ—¶é—´çš„推移而å˜æ…¢ã€‚Linus大约æ¯å‘¨å‘布一次
+æ–°çš„-rcå†…æ ¸ï¼›ä¸€ä¸ªæ£å¸¸çš„系列将在-rc6å’Œ-rc9ä¹‹é—´ï¼Œå†…æ ¸è¢«è®¤ä¸ºè¶³å¤Ÿç¨³å®šå¹¶æœ€ç»ˆå‘布。
+然åŽï¼Œæ•´ä¸ªè¿‡ç¨‹åˆé‡æ–°å¼€å§‹äº†ã€‚
+
+例如，这里是4.16çš„å¼€å‘周期进行情况（2018年的所有日期）:
+
+ ============== ==============================
+ 一月 28 4.15 稳定版å‘布
+ 二月 11 4.16-rc1, åˆå¹¶çª—å£å…³é—
+ 二月 18 4.16-rc2
+ 二月 25 4.16-rc3
+ 三月 4 4.16-rc4
+ 三月 11 4.16-rc5
+ 三月 18 4.16-rc6
+ 三月 25 4.16-rc7
+ 四月 1 4.16 稳定版å‘布
+ ============== ==============================
+
+å¼€å‘人员如何决定何时结æŸå¼€å‘周期并创建稳定的版本？使用的最é‡è¦çš„æŒ‡æ ‡æ˜¯ä»¥å‰
+版本的回归列表。ä¸æ¬¢è¿Žå‡ºçŽ°ä»»ä½•é”™è¯¯ï¼Œä½†æ˜¯é‚£äº›ç ´å了以å‰èƒ½å·¥ä½œçš„系统的错误被
+认为是特别严é‡çš„ã€‚å› æ¤ï¼Œå¯¼è‡´å›žå½’çš„è¡¥ä¸æ˜¯ä¸å—欢迎的，很å¯èƒ½åœ¨ç¨³å®šæœŸå†…åˆ é™¤ã€‚
+
+å¼€å‘äººå‘˜çš„ç›®æ ‡æ˜¯åœ¨ç¨³å®šå‘布之å‰ä¿®å¤æ‰€æœ‰å·²çŸ¥çš„回归。在现实世界ä¸ï¼Œè¿™ç§å®Œç¾Žæ˜¯
+很难实现的；在这ç§è§„模的项目ä¸ï¼Œå˜é‡å¤ªå¤šäº†ã€‚有一点，延迟最终版本åªä¼šä½¿é—®é¢˜
+å˜å¾—更糟；ç‰å¾…下一个åˆå¹¶çª—å£çš„ä¸€å †æ›´æ”¹å°†å˜å¤§ï¼Œä»Žè€Œåœ¨ä¸‹æ¬¡åˆ›å»ºæ›´å¤šçš„回归错误。
+å› æ¤ï¼Œå¤§å¤šæ•°4.xå†…æ ¸éƒ½æœ‰ä¸€äº›å·²çŸ¥çš„å›žå½’é”™è¯¯ï¼Œä¸è¿‡ï¼Œå¸Œæœ›æ²¡æœ‰ä¸€ä¸ªæ˜¯ä¸¥é‡çš„。
+
+一旦一个稳定的版本å‘布，它æ£åœ¨è¿›è¡Œçš„维护工作就被移交给“稳定团队â€ï¼Œç›®å‰ç”±
+Greg Kroah-Hartman组æˆã€‚稳定团队将使用4.x.yç¼–å·æ–¹æ¡ˆä¸å®šæœŸçš„å‘布稳定版本的更
+新。è¦åŠ 入更新版本，补ä¸ç¨‹åºå¿…须（1）修å¤ä¸€ä¸ªé‡è¦çš„bug，（2）已ç»åˆå¹¶åˆ°
+下一个开å‘主线ä¸ã€‚å†…æ ¸é€šå¸¸ä¼šåœ¨è¶…è¿‡å…¶åˆå§‹ç‰ˆæœ¬çš„一个以上的开å‘周期内接收稳定
+的更新。例如，4.13å†…æ ¸çš„åŽ†å²å¦‚下
+
+ ============== ===============================
+ ä¹æœˆ 3 4.13 稳定版å‘布
+ ä¹æœˆ 13 4.13.1
+ ä¹æœˆ 20 4.13.2
+ ä¹æœˆ 27 4.13.3
+ å月 5 4.13.4
+ å月 12 4.13.5
+ ... ...
+ å一月 24 4.13.16
+ ============== ===============================
+
+4.13.16是4.13版本的最终稳定更新。
+
+æœ‰äº›å†…æ ¸è¢«æŒ‡å®šä¸ºâ€œé•¿æœŸâ€å†…æ ¸ï¼›å®ƒä»¬å°†å¾—åˆ°æ›´é•¿æ—¶é—´çš„æ”¯æŒã€‚在本文ä¸ï¼Œå½“å‰çš„长期
+å†…æ ¸åŠå…¶ç»´æŠ¤è€…是：
+
+ ====== ====================== ==============================
+ 3.16 Ben Hutchings (é•¿æœŸç¨³å®šå†…æ ¸)
+ 4.1 Sasha Levin
+ 4.4 Greg Kroah-Hartman (é•¿æœŸç¨³å®šå†…æ ¸)
+ 4.9 Greg Kroah-Hartman
+ 4.14 Greg Kroah-Hartman
+ ====== ====================== ==============================
+
+为长期支æŒé€‰æ‹©å†…æ ¸çº¯ç²¹æ˜¯ç»´æŠ¤äººå‘˜æœ‰å¿…è¦å’Œæ—¶é—´æ¥ç»´æŠ¤è¯¥ç‰ˆæœ¬çš„问题。目å‰è¿˜æ²¡æœ‰
+为å³å°†å‘布的任何特定版本æ供长期支æŒçš„已知计划。
+
+è¡¥ä¸çš„生命周期
+--------------
+
+è¡¥ä¸ä¸ä¼šç›´æŽ¥ä»Žå¼€å‘äººå‘˜çš„é”®ç›˜è¿›å…¥ä¸»çº¿å†…æ ¸ã€‚ç›¸å，有一个ç¨å¾®å¤æ‚（如果有些éž
+æ£å¼ï¼‰çš„过程，旨在确ä¿å¯¹æ¯ä¸ªè¡¥ä¸è¿›è¡Œè´¨é‡å®¡æŸ¥ï¼Œå¹¶ç¡®ä¿æ¯ä¸ªè¡¥ä¸å®žçŽ°äº†ä¸€ä¸ªåœ¨ä¸»çº¿
+ä¸éœ€è¦çš„更改。对于å°çš„ä¿®å¤ï¼Œè¿™ä¸ªè¿‡ç¨‹å¯èƒ½ä¼šå¾ˆå¿«å‘生，或者，在大的和有争议的
+å˜æ›´çš„情况下，会æŒç»æ•°å¹´ã€‚许多开å‘人员的挫折æ¥è‡ªäºŽå¯¹è¿™ä¸ªè¿‡ç¨‹ç¼ºä¹ç†è§£æˆ–者
+试图绕过它。
+
+为了å‡å°‘è¿™ç§æŒ«æŠ˜æ„Ÿï¼Œæœ¬æ–‡å°†æè¿°è¡¥ä¸å¦‚ä½•è¿›å…¥å†…æ ¸ã€‚ä¸‹é¢æ˜¯ä¸€ä¸ªä»‹ç»ï¼Œå®ƒä»¥æŸç§
+ç†æƒ³åŒ–çš„æ–¹å¼æ述了这个过程。更详细的过程将在åŽé¢çš„ç« èŠ‚ä¸ä»‹ç»ã€‚
+
+è¡¥ä¸ç¨‹åºç»åŽ†çš„阶段通常是：
+
+- 设计。这就是补ä¸çš„真æ£éœ€æ±‚——以åŠæ»¡è¶³è¿™äº›éœ€æ±‚çš„æ–¹å¼â€”—的所在。设计工作通常
+ 是在ä¸æ¶‰åŠç¤¾åŒºçš„情况下完æˆçš„，但是如果å¯èƒ½çš„è¯ï¼Œæœ€å¥½æ˜¯åœ¨å…¬å¼€çš„情况下完æˆ
+ è¿™é¡¹å·¥ä½œï¼›è¿™æ ·å¯ä»¥èŠ‚çœå¾ˆå¤šç¨åŽå†é‡æ–°è®¾è®¡çš„时间。
+
+- 早期评审。补ä¸è¢«å‘布到相关的邮件列表ä¸ï¼Œåˆ—表ä¸çš„å¼€å‘人员会回å¤ä»–们å¯èƒ½æœ‰
+ 的任何评论。如果一切顺利的è¯ï¼Œè¿™ä¸ªè¿‡ç¨‹åº”该会å‘现补ä¸çš„任何主è¦é—®é¢˜ã€‚
+
+- 更广泛的评审。当补ä¸æŽ¥è¿‘准备好纳入主线时，它应该被相关的å系统维护人员
+ 接å———尽管这ç§æŽ¥å—并ä¸èƒ½ä¿è¯è¡¥ä¸ä¼šä¸€ç›´å»¶ä¼¸åˆ°ä¸»çº¿ã€‚è¡¥ä¸å°†å‡ºçŽ°åœ¨ç»´æŠ¤äººå‘˜çš„
+ åç³»ç»Ÿæ ‘ä¸ï¼Œå¹¶è¿›å…¥ -next æ ‘ï¼ˆå¦‚ä¸‹æ‰€è¿°ï¼‰ã€‚å½“æµç¨‹å·¥ä½œæ—¶ï¼Œæ¤æ¥éª¤å°†å¯¼è‡´å¯¹è¡¥ä¸
+ 进行更广泛的审查，并å‘现由于将æ¤è¡¥ä¸ä¸Žå…¶ä»–人所åšçš„工作集æˆè€Œå¯¼è‡´çš„任何
+ 问题。
+
+- 请注æ„ï¼Œå¤§å¤šæ•°ç»´æŠ¤äººå‘˜ä¹Ÿæœ‰æ—¥å¸¸å·¥ä½œï¼Œå› æ¤åˆå¹¶è¡¥ä¸å¯èƒ½ä¸æ˜¯ä»–们的最高优先级。
+ 如果您的补ä¸ç¨‹åºå¾—到了关于所需更改的å馈，那么您应该进行这些更改，或者为
+ ä¸åº”è¯¥è¿›è¡Œè¿™äº›æ›´æ”¹çš„åŽŸå› è¾©æŠ¤ã€‚å¦‚æžœæ‚¨çš„è¡¥ä¸æ²¡æœ‰è¯„审æ„è§ï¼Œä½†æ²¡æœ‰è¢«å…¶ç›¸åº”çš„
+ å系统或驱动程åºç»´æŠ¤è€…接å—，那么您应该åšæŒä¸æ‡ˆåœ°å°†è¡¥ä¸æ›´æ–°åˆ°å½“å‰å†…æ ¸ï¼Œä½¿
+ 其干净地应用，并ä¸æ–地将其å‘é€ä»¥ä¾›å®¡æŸ¥å’Œåˆå¹¶ã€‚
+
+- åˆå¹¶åˆ°ä¸»çº¿ã€‚最终，一个æˆåŠŸçš„è¡¥ä¸å°†è¢«åˆå¹¶åˆ°ç”±LinusTorvalds管ç†çš„主线å˜å‚¨åº“
+ ä¸ã€‚æ¤æ—¶å¯èƒ½ä¼šå‡ºçŽ°æ›´å¤šçš„评论和/或问题；开å‘人员应对这些问题并解决出现的
+ 任何问题很é‡è¦ã€‚
+
+- 稳定版å‘布。å¯èƒ½å—è¡¥ä¸å½±å“的用户数é‡çŽ°åœ¨å¾ˆå¤§ï¼Œå› æ¤å¯èƒ½å†æ¬¡å‡ºçŽ°æ–°çš„问题。
+
+- 长期维护。虽然开å‘人员在åˆå¹¶ä»£ç åŽå¯èƒ½ä¼šå¿˜è®°ä»£ç ，但这ç§è¡Œä¸ºå¾€å¾€ä¼šç»™å¼€å‘
+ 社区留下ä¸è‰¯å°è±¡ã€‚åˆå¹¶ä»£ç æ¶ˆé™¤äº†ä¸€äº›ç»´æŠ¤è´Ÿæ‹…ï¼Œå› ä¸ºå…¶ä»–ä»£ç 将修å¤ç”±API
+ 更改引起的问题。但是，如果代ç è¦é•¿æœŸä¿æŒæœ‰ç”¨ï¼ŒåŽŸå§‹å¼€å‘人员应该继ç»ä¸º
+ 代ç 负责。
+
+å†…æ ¸å¼€å‘人员（或他们的雇主）犯的最大错误之一是试图将æµç¨‹ç®€åŒ–为一个
+“åˆå¹¶åˆ°ä¸»çº¿â€æ¥éª¤ã€‚è¿™ç§æ–¹æ³•æ€»æ˜¯ä¼šè®©æ‰€æœ‰ç›¸å…³äººå‘˜æ„Ÿåˆ°æ²®ä¸§ã€‚
+
+è¡¥ä¸å¦‚ä½•è¿›å…¥å†…æ ¸
+----------------
+
+åªæœ‰ä¸€ä¸ªäººå¯ä»¥å°†è¡¥ä¸åˆå¹¶åˆ°ä¸»çº¿å†…æ ¸å˜å‚¨åº“ä¸ï¼šLinusTorvalds。但是，在进入
+2.6.38å†…æ ¸çš„9500多个补ä¸ä¸ï¼Œåªæœ‰112个（大约1.3%）是由Linus自己直接选择的。
+å†…æ ¸é¡¹ç›®å·²ç»å‘展到一个规模，没有一个开å‘人员å¯ä»¥åœ¨æ²¡æœ‰æ”¯æŒçš„情况下检查和
+选择æ¯ä¸ªè¡¥ä¸ã€‚å†…æ ¸å¼€å‘人员处ç†è¿™ç§å¢žé•¿çš„æ–¹å¼æ˜¯é€šè¿‡ä½¿ç”¨å›´ç»•ä¿¡ä»»é“¾æž„建的
+助ç†ç³»ç»Ÿã€‚
+
+å†…æ ¸ä»£ç 库在逻辑上被分解为一组å系统：网络ã€ç‰¹å®šçš„体系结构支æŒã€å†…å˜ç®¡ç†ã€
+视频设备ç‰ã€‚大多数å系统都有一个指定的维护人员，开å‘人员对该å系统ä¸çš„代ç
+负有全部责任。这些å系统维护者（æ¾æ•£åœ°ï¼‰æ˜¯ä»–们所管ç†çš„å†…æ ¸éƒ¨åˆ†çš„å®ˆæŠ¤è€…ï¼›
+他们（通常）会接å—一个补ä¸ä»¥åŒ…å«åˆ°ä¸»çº¿å†…æ ¸ä¸ã€‚
+
+å系统维护人员æ¯ä¸ªäººéƒ½ä½¿ç”¨gitæºä»£ç 管ç†å·¥å…·ç®¡ç†è‡ªå·±ç‰ˆæœ¬çš„å†…æ ¸æºä»£ç æ ‘ã€‚Git
+ç‰å·¥å…·ï¼ˆä»¥åŠQuilt或Mercurialç‰ç›¸å…³å·¥å…·ï¼‰å…许维护人员跟踪补ä¸åˆ—表，包括作者
+ä¿¡æ¯å’Œå…¶ä»–元数æ®ã€‚在任何给定的时间，维护人员都å¯ä»¥ç¡®å®šä»–或她的å˜å‚¨åº“ä¸çš„哪
+些补ä¸åœ¨ä¸»çº¿ä¸æ‰¾ä¸åˆ°ã€‚
+
+当åˆå¹¶çª—å£æ‰“开时，顶级维护人员将è¦æ±‚Linus从其å˜å‚¨åº“ä¸â€œæ‹‰å‡ºâ€ä»–们为åˆå¹¶é€‰æ‹©
+çš„è¡¥ä¸ã€‚如果LinusåŒæ„，补ä¸æµå°†æµå‘ä»–çš„å˜å‚¨åº“，æˆä¸ºä¸»çº¿å†…æ ¸çš„ä¸€éƒ¨åˆ†ã€‚
+Linus对拉æ“作ä¸æŽ¥æ”¶åˆ°çš„特定补ä¸çš„关注程度å„ä¸ç›¸åŒã€‚很明显，有时他看起æ¥å¾ˆ
+关注。但是，作为一般规则，Linus相信å系统维护人员ä¸ä¼šå‘上游å‘é€åè¡¥ä¸ã€‚
+
+å系统维护人员å过æ¥ä¹Ÿå¯ä»¥ä»Žå…¶ä»–维护人员那里获å–è¡¥ä¸ã€‚ä¾‹å¦‚ï¼Œç½‘ç»œæ ‘æ˜¯ç”±é¦–å…ˆ
+在专用于网络设备驱动程åºã€æ— 线网络ç‰çš„æ ‘ä¸ç§¯ç´¯çš„è¡¥ä¸æž„建的。æ¤å˜å‚¨é“¾å¯ä»¥
+ä»»æ„长，但很少超过两个或三个链接。由于链ä¸çš„æ¯ä¸ªç»´æŠ¤è€…都信任那些管ç†è¾ƒä½Ž
+çº§åˆ«æ ‘çš„ç»´æŠ¤è€…ï¼Œæ‰€ä»¥è¿™ä¸ªè¿‡ç¨‹ç§°ä¸ºâ€œä¿¡ä»»é“¾â€ã€‚
+
+æ˜¾ç„¶ï¼Œåœ¨è¿™æ ·çš„ç³»ç»Ÿä¸ï¼ŒèŽ·å–å†…æ ¸è¡¥ä¸å–决于找到æ£ç¡®çš„维护者。直接å‘Linuså‘é€
+è¡¥ä¸é€šå¸¸ä¸æ˜¯æ£ç¡®çš„方法。
+
+Next æ ‘
+-------
+
+åç³»ç»Ÿæ ‘é“¾å¼•å¯¼è¡¥ä¸æµåˆ°å†…æ ¸ï¼Œä½†å®ƒä¹Ÿæ出了一个有趣的问题：如果有人想查看为
+下一个åˆå¹¶çª—å£å‡†å¤‡çš„所有补ä¸æ€Žä¹ˆåŠžï¼Ÿå¼€å‘人员将感兴趣的是，还有什么其他的
+更改有待解决，以查看是å¦å˜åœ¨éœ€è¦æ‹…心的冲çªï¼›ä¾‹å¦‚ï¼Œæ›´æ”¹æ ¸å¿ƒå†…æ ¸å‡½æ•°åŽŸåž‹çš„
+修补程åºå°†ä¸Žä½¿ç”¨è¯¥å‡½æ•°æ—§å½¢å¼çš„任何其他修补程åºå†²çªã€‚审查人员和测试人员希望
+在所有这些å˜æ›´åˆ°è¾¾ä¸»çº¿å†…æ ¸ä¹‹å‰ï¼Œèƒ½å¤Ÿè®¿é—®å®ƒä»¬çš„集æˆå½¢å¼ä¸çš„å˜æ›´ã€‚您å¯ä»¥ä»Žæ‰€æœ‰
+有趣的åç³»ç»Ÿæ ‘ä¸æå–更改，但这将是一项大型且容易出错的工作。
+
+ç”案以-nextæ ‘çš„å½¢å¼å‡ºçŽ°ï¼Œåœ¨è¿™é‡Œåç³»ç»Ÿæ ‘è¢«æ”¶é›†ä»¥ä¾›æµ‹è¯•å’Œå®¡æŸ¥ã€‚Andrew Morton
+ç»´æŠ¤çš„è¿™äº›æ—§æ ‘è¢«ç§°ä¸ºâ€œ-mmâ€ï¼ˆç”¨äºŽå†…å˜ç®¡ç†ï¼Œè¿™å°±æ˜¯å®ƒçš„å¯åŠ¨åå—）。-mm æ ‘é›†æˆäº†
+一长串åç³»ç»Ÿæ ‘ä¸çš„è¡¥ä¸ï¼›å®ƒè¿˜åŒ…å«ä¸€äº›æ—¨åœ¨å¸®åŠ©è°ƒè¯•çš„è¡¥ä¸ã€‚
+
+除æ¤ä¹‹å¤–，-mm 还包å«å¤§é‡ç”±Andrew直接选择的补ä¸ã€‚这些补ä¸å¯èƒ½å·²ç»å‘布在邮件
+列表上，或者它们å¯èƒ½åº”ç”¨äºŽå†…æ ¸ä¸æ²¡æœ‰æŒ‡å®šåç³»ç»Ÿæ ‘çš„éƒ¨åˆ†ã€‚ç»“æžœï¼Œ-mm 作为一ç§
+最åŽæ‰‹æ®µçš„åç³»ç»Ÿæ ‘è¿è¡Œï¼›å¦‚果没有其他明显的路径å¯ä»¥è®©è¡¥ä¸è¿›å…¥ä¸»çº¿ï¼Œé‚£ä¹ˆå®ƒå¾ˆ
+å¯èƒ½ä»¥-mm 结æŸã€‚累积在-mm ä¸çš„å„ç§è¡¥ä¸æœ€ç»ˆå°†è¢«è½¬å‘到适当的åç³»ç»Ÿæ ‘ï¼Œæˆ–è€…ç›´æŽ¥
+å‘é€åˆ°Linus。在典型的开å‘周期ä¸ï¼Œå¤§çº¦5-10%çš„è¡¥ä¸é€šè¿‡-mm 进入主线。
+
+当å‰-mm è¡¥ä¸å¯åœ¨â€œmmotmâ€ï¼ˆ-mm of the moment）目录ä¸æ‰¾åˆ°ï¼Œåœ°å€ï¼š
+
+ http://www.ozlabs.org/~akpm/mmotm/
+
+然而，使用mmotmæ ‘å¯èƒ½æ˜¯ä¸€ç§ä»¤äººæ²®ä¸§çš„体验；它甚至å¯èƒ½æ— 法编译。
+
+下一个周期补ä¸åˆå¹¶çš„主è¦æ ‘是linux-next，由Stephen Rothwell ç»´æŠ¤ã€‚æ ¹æ®è®¾è®¡
+linux-next 是下一个åˆå¹¶çª—å£å…³é—åŽä¸»çº¿çš„快照。linux-nextæ ‘åœ¨Linux-kernel å’Œ
+Linux-next 邮件列表ä¸å‘布，å¯ä»Žä»¥ä¸‹ä½ç½®ä¸‹è½½ï¼š
+
+ http://www.kernel.org/pub/linux/kernel/next/
+
+Linux-next å·²ç»æˆä¸ºå†…æ ¸å¼€å‘过程ä¸ä¸å¯æˆ–缺的一部分；在一个给定的åˆå¹¶çª—å£ä¸åˆå¹¶
+的所有补ä¸éƒ½åº”该在åˆå¹¶çª—å£æ‰“开之å‰çš„一段时间内找到进入Linux-next 的方法。
+
+Staging æ ‘
+----------
+
+å†…æ ¸æºä»£ç æ ‘åŒ…å«drivers/staging/directory，其ä¸æœ‰è®¸å¤šé©±åŠ¨ç¨‹åºæˆ–文件系统的
+å目录æ£åœ¨è¢«æ·»åŠ åˆ°å†…æ ¸æ ‘ä¸ã€‚它们然需è¦æ›´å¤šçš„工作的时候å¯ä»¥ä¿ç•™åœ¨
+driver/staging目录ä¸ï¼›ä¸€æ—¦å®Œæˆï¼Œå°±å¯ä»¥å°†å®ƒä»¬ç§»åˆ°å†…æ ¸ä¸ã€‚这是一ç§è·Ÿè¸ªä¸ç¬¦åˆ
+Linuxå†…æ ¸ç¼–ç 或质é‡æ ‡å‡†çš„驱动程åºçš„方法，但人们å¯èƒ½å¸Œæœ›ä½¿ç”¨å®ƒä»¬å¹¶è·Ÿè¸ªå¼€å‘。
+
+Greg Kroah Hartman ç›®å‰è´Ÿè´£ç»´æŠ¤staging æ ‘ã€‚ä»éœ€è¦å·¥ä½œçš„驱动程åºå°†å‘é€ç»™ä»–，
+æ¯ä¸ªé©±åŠ¨ç¨‹åºåœ¨drivers/staging/ä¸éƒ½æœ‰è‡ªå·±çš„å目录。除了驱动程åºæºæ–‡ä»¶ä¹‹å¤–，
+目录ä¸è¿˜åº”该有一个TODO文件。todo文件列出了驱动程åºéœ€è¦æŽ¥å—的挂起的工作，
+以åŠé©±åŠ¨ç¨‹åºçš„任何补ä¸éƒ½åº”该抄é€çš„人员列表。当å‰çš„规则è¦æ±‚，staging的驱动
+程åºå¿…须至少æ£ç¡®ç¼–译。
+
+Staging 是一ç§ç›¸å¯¹å®¹æ˜“的方法，å¯ä»¥è®©æ–°çš„驱动程åºè¿›å…¥ä¸»çº¿ï¼Œå¹¸è¿çš„是，他们会
+引起其他开å‘人员的注æ„，并迅速改进。然而，进入staging并ä¸æ˜¯æ•…事的结尾；
+stagingä¸æ²¡æœ‰çœ‹åˆ°å¸¸è§„进展的代ç æœ€ç»ˆå°†è¢«åˆ é™¤ã€‚ç»é”€å•†ä¹Ÿå€¾å‘于相对ä¸æ„¿æ„使用
+staging驱动程åºã€‚å› æ¤ï¼Œåœ¨æˆä¸ºä¸€ååˆé€‚的主线驱动的路上，staging å……å…¶é‡åªæ˜¯
+一个åœç•™ã€‚
+
+工具
+----
+
+从上é¢çš„文本å¯ä»¥çœ‹å‡ºï¼Œå†…æ ¸å¼€å‘过程在很大程度上ä¾èµ–于在ä¸åŒæ–¹å‘上èšé›†è¡¥ä¸çš„
+èƒ½åŠ›ã€‚å¦‚æžœæ²¡æœ‰é€‚å½“å¼ºå¤§çš„å·¥å…·ï¼Œæ•´ä¸ªç³»ç»Ÿå°†æ— æ³•åœ¨ä»»ä½•åœ°æ–¹æ£å¸¸å·¥ä½œã€‚关于如何使用
+这些工具的教程远远超出了本文档的范围，但是还是有一些指å—的空间。
+
+到目å‰ä¸ºæ¢ï¼Œå†…æ ¸ç¤¾åŒºä½¿ç”¨çš„ä¸»è¦æºä»£ç 管ç†ç³»ç»Ÿæ˜¯git。Git是在自由软件社区ä¸å¼€å‘
+的许多分布å¼ç‰ˆæœ¬æŽ§åˆ¶ç³»ç»Ÿä¹‹ä¸€ã€‚它éžå¸¸é€‚åˆå†…æ ¸å¼€å‘ï¼Œå› ä¸ºå®ƒåœ¨å¤„ç†å¤§åž‹å˜å‚¨åº“å’Œ
+大é‡è¡¥ä¸æ—¶æ€§èƒ½éžå¸¸å¥½ã€‚它还有一个难以å¦ä¹ 和使用的å声，尽管éšç€æ—¶é—´çš„推移它
+å˜å¾—æ›´å¥½äº†ã€‚å¯¹äºŽå†…æ ¸å¼€å‘人员æ¥è¯´ï¼Œå¯¹Gitçš„æŸç§ç†Ÿæ‚‰å‡ 乎是一ç§è¦æ±‚ï¼›å³ä½¿ä»–们ä¸
+将它用于自己的工作，他们也需è¦Gitæ¥è·Ÿä¸Šå…¶ä»–å¼€å‘人员（以åŠä¸»çº¿ï¼‰æ£åœ¨åšçš„事情。
+
+çŽ°åœ¨å‡ ä¹Žæ‰€æœ‰çš„Linuxå‘行版都打包了Git。主页ä½äºŽï¼š
+
+ http://git-scm.com/
+
+那个页é¢æœ‰æŒ‡å‘文档和教程的指针。
+
+在ä¸ä½¿ç”¨gitçš„å†…æ ¸å¼€å‘人员ä¸ï¼Œæœ€æµè¡Œçš„é€‰æ‹©å‡ ä¹Žè‚¯å®šæ˜¯mercurial：
+
+ http://www.seleric.com/mercurial/
+
+Mercurial与Git共享许多特性，但它æ供了一个界é¢ï¼Œè®¸å¤šäººè§‰å¾—它更易于使用。
+
+å¦ä¸€ä¸ªå€¼å¾—了解的工具是quilt:
+
+ http://savannah.nongnu.org/projects/quilt
+
+Quilt 是一个补ä¸ç®¡ç†ç³»ç»Ÿï¼Œè€Œä¸æ˜¯æºä»£ç 管ç†ç³»ç»Ÿã€‚它ä¸ä¼šéšç€æ—¶é—´çš„推移跟踪历å²ï¼›
+相å，它é¢å‘æ ¹æ®ä¸æ–å‘展的代ç 库跟踪一组特定的更改。一些主è¦çš„å系统维护人员
+使用Quiltæ¥ç®¡ç†æ‰“ç®—å‘上游移动的补ä¸ã€‚对于æŸäº›æ ‘的管ç†ï¼ˆä¾‹å¦‚-mm），quilt 是
+最好的工具。
+
+邮件列表
+--------
+
+大é‡çš„Linuxå†…æ ¸å¼€å‘工作是通过邮件列表完æˆçš„。如果ä¸åœ¨æŸä¸ªåœ°æ–¹åŠ 入至少一个列表，
+就很难æˆä¸ºç¤¾åŒºä¸ä¸€ä¸ªåŠŸèƒ½å®Œå¤‡çš„æˆå‘˜ã€‚但是，Linux邮件列表对开å‘人员æ¥è¯´ä¹Ÿæ˜¯ä¸€ä¸ª
+潜在的å±é™©ï¼Œä»–们å¯èƒ½ä¼šè¢«ä¸€å †ç”µå邮件淹没，è¿åLinux列表上使用的约定，或者
+两者兼而有之。
+
+å¤§å¤šæ•°å†…æ ¸é‚®ä»¶åˆ—è¡¨éƒ½åœ¨vger.kernel.org上è¿è¡Œï¼›ä¸»åˆ—表ä½äºŽï¼š
+
+ http://vger.kernel.org/vger-lists.html
+
+ä¸è¿‡ï¼Œä¹Ÿæœ‰ä¸€äº›åˆ—表托管在别处；其ä¸ä¸€äº›åˆ—表ä½äºŽlists.redhat.com。
+
+å½“ç„¶ï¼Œå†…æ ¸å¼€å‘çš„æ ¸å¿ƒé‚®ä»¶åˆ—è¡¨æ˜¯linux-kernel。这个åå•æ˜¯ä¸€ä¸ªä»¤äººç”Ÿç•çš„地方；
+æ¯å¤©çš„ä¿¡æ¯é‡å¯ä»¥è¾¾åˆ°500æ¡ï¼Œå™ªéŸ³å¾ˆé«˜ï¼Œè°ˆè¯æŠ€æœ¯æ€§å¾ˆå¼ºï¼Œå‚与者并ä¸æ€»æ˜¯è¡¨çŽ°å‡º
+高度的礼貌。但是，没有其他地方å¯ä»¥è®©å†…æ ¸å¼€å‘社区作为一个整体èšé›†åœ¨ä¸€èµ·ï¼›
+é¿å…使用æ¤åˆ—表的开å‘人员将错过é‡è¦ä¿¡æ¯ã€‚
+
+有一些æ示å¯ä»¥å¸®åŠ©åœ¨linux-kernel生å˜ï¼š
+
+- 将邮件转移到å•ç‹¬çš„文件夹，而ä¸æ˜¯ä¸»é‚®ç®±ã€‚我们必须能够æŒç»åœ°å¿½ç•¥æ´ªæµã€‚
+
+- ä¸è¦è¯•å›¾è·Ÿè¸ªæ¯ä¸€æ¬¡è°ˆè¯-其他人都ä¸ä¼šã€‚é‡è¦çš„是è¦å¯¹æ„Ÿå…´è¶£çš„主题（尽管请
+ 注æ„，长时间的对è¯å¯ä»¥åœ¨ä¸æ›´æ”¹ç”µå邮件主题行的情况下å离原始主题）和å‚与
+ 的人进行ç›é€‰ã€‚
+
+- ä¸è¦æŒ‘事。如果有人试图激起愤怒的å应，忽略他们。
+
+- 当å“应Linuxå†…æ ¸ç”µå邮件（或其他列表上的电å邮件）时，请为所有相关人员ä¿ç•™
+ cc:header。如果没有强有力的ç†ç”±ï¼ˆå¦‚明确的请求），则ä¸åº”åˆ é™¤æ”¶ä»¶äººã€‚ä¸€å®šè¦
+ ç¡®ä¿ä½ è¦å›žå¤çš„人在cc:listä¸ã€‚è¿™ä¸ªæƒ¯ä¾‹ä¹Ÿä½¿ä½ ä¸å¿…在回å¤é‚®ä»¶æ—¶æ˜Žç¡®è¦æ±‚被抄é€ã€‚
+
+- 在æ出问题之å‰ï¼Œæœç´¢åˆ—表档案（和整个网络）。有些开å‘人员å¯èƒ½ä¼šå¯¹é‚£äº›æ˜¾ç„¶
+ 没有完æˆå®¶åºä½œä¸šçš„人感到ä¸è€çƒ¦ã€‚
+
+- é¿å…è´´é¡¶å¸–ï¼ˆæŠŠä½ çš„ç”æ¡ˆæ”¾åœ¨ä½ è¦å›žå¤çš„引文上é¢çš„åšæ³•ï¼‰ã€‚è¿™ä¼šè®©ä½ çš„å›žç”æ›´éš¾
+ ç†è§£ï¼Œå°è±¡ä¹Ÿå¾ˆå·®ã€‚
+
+- 询问æ£ç¡®çš„邮件列表。linux-kernel å¯èƒ½æ˜¯é€šç”¨çš„讨论点，但它ä¸æ˜¯ä»Žæ‰€æœ‰å系统
+ ä¸å¯»æ‰¾å¼€å‘人员的最佳场所。
+
+最åŽä¸€ç‚¹â€”—找到æ£ç¡®çš„邮件列表——是开å‘人员出错的常è§åœ°æ–¹ã€‚在Linuxå†…æ ¸ä¸Šæ出与
+ç½‘ç»œç›¸å…³çš„é—®é¢˜çš„äººå‡ ä¹Žè‚¯å®šä¼šæ”¶åˆ°ä¸€ä¸ªç¤¼è²Œçš„å»ºè®®ï¼Œè½¬è€Œåœ¨netdev列表上æ出，
+å› ä¸ºè¿™æ˜¯å¤§å¤šæ•°ç½‘ç»œå¼€å‘人员ç»å¸¸å‡ºçŽ°çš„列表。还有其他列表å¯ç”¨äºŽscsiã€
+video4linuxã€ideã€filesystemç‰å系统。查找邮件列表的最佳ä½ç½®æ˜¯ä¸Žå†…æ ¸æºä»£ç
+一起打包的MAINTAINERS文件。
+
+å¼€å§‹å†…æ ¸å¼€å‘
+------------
+
+å…³äºŽå¦‚ä½•å¼€å§‹å†…æ ¸å¼€å‘过程的问题很常è§â€”—æ¥è‡ªä¸ªäººå’Œå…¬å¸ã€‚åŒæ ·å¸¸è§çš„是错误，这
+使得关系的开始比必须的更困难。
+
+å…¬å¸é€šå¸¸å¸Œæœ›è˜è¯·çŸ¥åçš„å¼€å‘人员æ¥å¯åŠ¨å¼€å‘团队。实际上，这是一ç§æœ‰æ•ˆçš„技术。
+但它也往往是昂贵的，而且没有增长ç»éªŒä¸°å¯Œçš„å†…æ ¸å¼€å‘人员储备。考虑到时间的
+投入，å¯ä»¥è®©å†…部开å‘äººå‘˜åŠ å¿«Linuxå†…æ ¸çš„å¼€å‘速度。花这个时间å¯ä»¥è®©é›‡ä¸»æ‹¥æœ‰
+ä¸€æ‰¹äº†è§£å†…æ ¸å’Œå…¬å¸çš„å¼€å‘人员，他们也å¯ä»¥å¸®åŠ©åŸ¹è®å…¶ä»–人。从ä¸æœŸæ¥çœ‹ï¼Œè¿™å¾€å¾€
+是更有利å¯å›¾çš„方法。
+
+å¯ä»¥ç†è§£çš„是，å•ä¸ªå¼€å‘人员往往对起æ¥æ„Ÿåˆ°èŒ«ç„¶ã€‚从一个大型项目开始å¯èƒ½ä¼šå¾ˆ
+å“人；人们往往想先用一些较å°çš„东西æ¥æµ‹è¯•æ°´åŸŸã€‚这是一些开å‘人员开始创建修补
+拼写错误或轻微编ç é£Žæ ¼é—®é¢˜çš„è¡¥ä¸çš„地方。ä¸å¹¸çš„æ˜¯ï¼Œè¿™æ ·çš„è¡¥ä¸ä¼šäº§ç”Ÿä¸€å®šç¨‹åº¦
+的噪音，这会分散整个开å‘社区的注æ„åŠ›ï¼Œå› æ¤ï¼Œè¶Šæ¥è¶Šå¤šçš„人看ä¸èµ·å®ƒä»¬ã€‚希望å‘
+社区介ç»è‡ªå·±çš„æ–°å¼€å‘äººå‘˜å°†æ— æ³•é€šè¿‡è¿™äº›æ–¹å¼èŽ·å¾—他们想è¦çš„é‚£ç§æŽ¥å¾…。
+
+Andrew Morton ä¸ºæœ‰æŠ±è´Ÿçš„å†…æ ¸å¼€å‘人员æ供了这个建议
+
+::
+
+ æ‰€æœ‰å†…æ ¸åˆå¦è€…çš„No.1项目肯定是“确ä¿å†…æ ¸åœ¨æ‰€æœ‰çš„æœºå™¨ä¸Šï¼Œä½ å¯ä»¥è§¦æ‘¸
+ 到的，始终è¿è¡Œè‰¯å¥½" é€šå¸¸è¿™æ ·åšçš„方法是与其他人一起解决问题（这
+ å¯èƒ½éœ€è¦åšæŒï¼ï¼‰ä½†è¿™å¾ˆå¥½â€”â€”è¿™æ˜¯å†…æ ¸å¼€å‘的一部分
+
+(http://lwn.net/articles/283982/)
+
+在没有明显问题需è¦è§£å†³çš„情况下，建议开å‘人员查看当å‰çš„回归和开放å¼é”™è¯¯åˆ—表.
+解决需è¦ä¿®å¤çš„问题没有任何缺点；通过解决这些问题，开å‘人员将获得处ç†è¿‡ç¨‹çš„
+ç»éªŒï¼ŒåŒæ—¶ä¸Žå¼€å‘社区的其他人建立尊é‡ã€‚
diff --git a/Documentation/translations/zh_CN/process/3.Early-stage.rst b/Documentation/translations/zh_CN/process/3.Early-stage.rst
new file mode 100644
index 0000000000000000000000000000000000000000..b8676aec60050b4dea792c36130b5cf4a171637d
--- /dev/null
+++ b/Documentation/translations/zh_CN/process/3.Early-stage.rst
@@ -0,0 +1,161 @@
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: :ref:`Documentation/process/3.Early-stage.rst <development_early_stage>`
+:Translator: Alex Shi <alex.shi@linux.alibaba.com>
+
+.. _cn_development_early_stage:
+
+早期规划
+========
+
+当考虑一个Linuxå†…æ ¸å¼€å‘项目时，很å¯èƒ½ä¼šç›´æŽ¥è·³è¿›åŽ»å¼€å§‹ç¼–ç 。然而，与任何é‡è¦
+çš„é¡¹ç›®ä¸€æ ·ï¼ŒæˆåŠŸçš„许多基础最好是在第一行代ç 编写之å‰å°±åšå¥½äº†ã€‚在早期计划和
+沟通ä¸èŠ±è´¹ä¸€äº›æ—¶é—´å¯ä»¥èŠ‚çœæ›´å¤šçš„时间。
+
+详述问题
+--------
+
+ä¸Žä»»ä½•å·¥ç¨‹é¡¹ç›®ä¸€æ ·ï¼ŒæˆåŠŸçš„å†…æ ¸å¢žå¼ºä»Žè¦è§£å†³çš„问题的清晰æ述开始。在æŸäº›æƒ…况
+下，这个æ¥éª¤å¾ˆå®¹æ˜“：例如，当æŸä¸ªç‰¹å®šç¡¬ä»¶éœ€è¦é©±åŠ¨ç¨‹åºæ—¶ã€‚ä¸è¿‡ï¼Œåœ¨å…¶ä»–æ–¹é¢ï¼Œ
+将实际问题与建议的解决方案混淆是很有诱惑力的，这å¯èƒ½ä¼šå¯¼è‡´å›°éš¾ã€‚
+
+举个例åï¼šå‡ å¹´å‰ï¼Œä½¿ç”¨Linux音频的开å‘人员寻求一ç§æ–¹æ³•æ¥è¿è¡Œåº”用程åºï¼Œè€Œä¸å›
+ç³»ç»Ÿå»¶è¿Ÿè¿‡å¤§è€Œå¯¼è‡´é€€å‡ºæˆ–å…¶ä»–å·¥ä»¶ã€‚ä»–ä»¬å¾—åˆ°çš„è§£å†³æ–¹æ¡ˆæ˜¯ä¸€ä¸ªå†…æ ¸æ¨¡å—，旨在连
+接到Linux安全模å—（LSM）框架ä¸ï¼›è¿™ä¸ªæ¨¡å—å¯ä»¥é…置为å…许特定的应用程åºè®¿é—®
+实时调度程åºã€‚这个模å—被实现并å‘é€åˆ°Linuxå†…æ ¸é‚®ä»¶åˆ—è¡¨ï¼Œåœ¨é‚£é‡Œå®ƒç«‹å³é‡åˆ°é—®é¢˜ã€‚
+
+对于音频开å‘人员æ¥è¯´ï¼Œè¿™ä¸ªå®‰å…¨æ¨¡å—足以解决他们当å‰çš„问题。但是，对于更广泛的
+å†…æ ¸ç¤¾åŒºæ¥è¯´ï¼Œè¿™è¢«è§†ä¸ºå¯¹LSM框架的滥用（LSM框架并ä¸æ‰“算授予他们原本ä¸å…·å¤‡çš„
+进程特æƒï¼‰ï¼Œå¹¶å¯¹ç³»ç»Ÿç¨³å®šæ€§é€ æˆé£Žé™©ã€‚他们首选的解决方案包括çŸæœŸçš„通过rlimit
+机制进行实时调度访问，以åŠé•¿æœŸçš„å‡å°‘延迟的工作。
+
+然而，音频社区看ä¸åˆ°ä»–们实施的特定解决方案的过去；他们ä¸æ„¿æ„接å—替代方案。
+ç”±æ¤äº§ç”Ÿçš„分æ§ä½¿è¿™äº›å¼€å‘äººå‘˜å¯¹æ•´ä¸ªå†…æ ¸å¼€å‘过程感到失望；其ä¸ä¸€ä¸ªå¼€å‘人员返回
+到音频列表并å‘布了以下内容：
+
+ 有很多éžå¸¸å¥½çš„Linuxå†…æ ¸å¼€å‘人员，但他们往往会被一群傲慢的傻瓜所压倒。
+ 试图å‘è¿™äº›äººä¼ è¾¾ç”¨æˆ·éœ€æ±‚æ˜¯æµªè´¹æ—¶é—´ã€‚ä»–ä»¬å¤ªâ€œèªæ˜Žâ€äº†ï¼Œæ ¹æœ¬å¬ä¸åˆ°å°‘数人
+ çš„è¯ã€‚
+
+（http://lwn.net/articles/131776/）
+
+实际情况ä¸åŒï¼›ä¸Žç‰¹å®šæ¨¡å—ç›¸æ¯”ï¼Œå†…æ ¸å¼€å‘人员更关心系统稳定性ã€é•¿æœŸç»´æŠ¤ä»¥åŠæ‰¾åˆ°
+æ£ç¡®çš„问题解决方案。这个故事的寓æ„是把é‡ç‚¹æ”¾åœ¨é—®é¢˜ä¸Šâ€”—而ä¸æ˜¯å…·ä½“的解决方案
+上——并在投入创建代ç 之å‰ä¸Žå¼€å‘社区讨论这个问题。
+
+å› æ¤ï¼Œåœ¨è€ƒè™‘ä¸€ä¸ªå†…æ ¸å¼€å‘项目时，我们应该得到一组简çŸé—®é¢˜çš„ç”案：
+
+ - 究竟需è¦è§£å†³çš„问题是什么？
+
+ - å—æ¤é—®é¢˜å½±å“的用户是è°ï¼Ÿè§£å†³æ–¹æ¡ˆåº”该解决哪些用例？
+
+ - å†…æ ¸çŽ°åœ¨ä¸ºä½•æ²¡èƒ½è§£å†³è¿™ä¸ªé—®é¢˜ï¼Ÿ
+
+åªæœ‰è¿™æ ·ï¼Œæ‰èƒ½å¼€å§‹è€ƒè™‘å¯èƒ½çš„解决方案。
+
+
+早期讨论
+--------
+
+åœ¨è®¡åˆ’å†…æ ¸å¼€å‘项目时，在开始实施之å‰ä¸Žç¤¾åŒºè¿›è¡Œè®¨è®ºæ˜¯å¾ˆæœ‰æ„义的。早期沟通å¯ä»¥
+通过多ç§æ–¹å¼èŠ‚çœæ—¶é—´å’Œéº»çƒ¦ï¼š
+
+ - 很å¯èƒ½é—®é¢˜æ˜¯ç”±å†…æ ¸ä»¥æ‚¨ä¸ç†è§£çš„æ–¹å¼è§£å†³çš„。Linuxå†…æ ¸å¾ˆå¤§ï¼Œå…·æœ‰è®¸å¤šä¸æ˜Žæ˜¾
+ 的特性和功能。并ä¸æ˜¯æ‰€æœ‰çš„å†…æ ¸åŠŸèƒ½éƒ½åƒäººä»¬æ‰€å¸Œæœ›çš„é‚£æ ·æœ‰æ–‡æ¡£è®°å½•ï¼Œè€Œä¸”å¾ˆ
+ 容易é—æ¼ä¸€äº›ä¸œè¥¿ã€‚ä½ çš„ä½œè€…å‘出了一个完整的驱动程åºï¼Œå¤åˆ¶äº†ä¸€ä¸ªæ–°ä½œè€…ä¸
+ 知é“的现有驱动程åºã€‚é‡æ–°è®¾è®¡çŽ°æœ‰è½®å的代ç ä¸ä»…浪费，而且ä¸ä¼šè¢«æŽ¥å—到主线
+ å†…æ ¸ä¸ã€‚
+
+ - 建议的解决方案ä¸å¯èƒ½æœ‰ä¸€äº›å…ƒç´ ä¸é€‚用于主线åˆå¹¶ã€‚在编写代ç 之å‰ï¼Œæœ€å¥½å…ˆ
+ äº†è§£è¿™æ ·çš„é—®é¢˜ã€‚
+
+ - 其他开å‘人员完全有å¯èƒ½è€ƒè™‘过这个问题；他们å¯èƒ½æœ‰æ›´å¥½çš„解决方案的想法，并且
+ å¯èƒ½æ„¿æ„帮助创建这个解决方案。
+
+åœ¨å†…æ ¸å¼€å‘社区的多年ç»éªŒç»™äº†æˆ‘们一个明确的教è®ï¼šé—门设计和开å‘çš„å†…æ ¸ä»£ç 总是
+有一些问题，这些问题åªæœ‰åœ¨ä»£ç å‘布到社区ä¸æ—¶æ‰ä¼šè¢«å‘现。有时这些问题很严é‡ï¼Œ
+需è¦æ•°æœˆæˆ–数年的努力æ‰èƒ½ä½¿ä»£ç è¾¾åˆ°å†…æ ¸ç¤¾åŒºçš„æ ‡å‡†ã€‚ä¸€äº›ä¾‹å包括：
+
+ - 设计并实现了å•å¤„ç†å™¨ç³»ç»Ÿçš„DeviceScapeç½‘ç»œæ ˆã€‚åªæœ‰ä½¿å…¶é€‚åˆäºŽå¤šå¤„ç†å™¨ç³»ç»Ÿï¼Œ
+ æ‰èƒ½å°†å…¶åˆå¹¶åˆ°ä¸»çº¿ä¸ã€‚在代ç ä¸æ”¹è£…é”ç‰ç‰æ˜¯ä¸€é¡¹å›°éš¾çš„ä»»åŠ¡ï¼›å› æ¤ï¼Œè¿™æ®µä»£ç
+ （现在称为mac80211）的åˆå¹¶è¢«æŽ¨è¿Ÿäº†ä¸€å¹´å¤šã€‚
+
+ - Reiser4文件系统包å«è®¸å¤šåŠŸèƒ½ï¼Œæ ¸å¿ƒå†…æ ¸å¼€å‘人员认为这些功能应该在虚拟文件
+ 系统层ä¸å®žçŽ°ã€‚它还包括一些特性，这些特性在ä¸å°†ç³»ç»Ÿæš´éœ²äºŽç”¨æˆ·å¼•èµ·çš„æ»é”çš„
+ 情况下是ä¸å®¹æ˜“实现的。这些问题的最新å‘现——以åŠå¯¹å…¶ä¸ä¸€äº›é—®é¢˜çš„æ‹’ç»â€”—已ç»
+ 导致Reiser4è¿œç¦»äº†ä¸»çº¿å†…æ ¸ã€‚
+
+ - Apparmor安全模å—以被认为ä¸å®‰å…¨å’Œä¸å¯é çš„æ–¹å¼ä½¿ç”¨å†…部虚拟文件系统数æ®ç»“构。
+ è¿™ç§æ‹…心（包括其他）使Apparmor多年ä¸åœ¨ä¸»çº¿ä¸Šã€‚
+
+在æ¯ä¸€ç§æƒ…å†µä¸‹ï¼Œé€šè¿‡ä¸Žå†…æ ¸å¼€å‘人员的早期讨论，å¯ä»¥é¿å…大é‡çš„痛苦和é¢å¤–的工作。
+
+找è°äº¤æµ
+--------
+
+当开å‘人员决定公开他们的计划时，下一个问题是：我们从哪里开始？ç”案是找到æ£ç¡®
+的邮件列表和æ£ç¡®çš„维护者。对于邮件列表，最好的方法是在维护者(MAINTAINERS)文件
+ä¸æŸ¥æ‰¾è¦å‘布的相关ä½ç½®ã€‚如果有一个åˆé€‚çš„å系统列表，那么å‘布它通常比在Linux
+å†…æ ¸ä¸Šå‘布更å¯å–；您更有å¯èƒ½æŽ¥è§¦åˆ°åœ¨ç›¸å…³å系统ä¸å…·æœ‰ä¸“业知识的开å‘人员，并且
+环境å¯èƒ½å…·æ”¯æŒæ€§ã€‚
+
+找到维护人员å¯èƒ½ä¼šæœ‰ç‚¹å›°éš¾ã€‚åŒæ ·ï¼Œç»´æŠ¤è€…文件是开始的地方。但是，该文件往往ä¸æ€»
+是最新的，并且并éžæ‰€æœ‰å系统都在那里表示。实际上，维护者文件ä¸åˆ—出的人员å¯èƒ½
+ä¸æ˜¯å½“å‰å®žé™…æ‹…ä»»è¯¥è§’è‰²çš„äººå‘˜ã€‚å› æ¤ï¼Œå½“对è”ç³»è°æœ‰ç–‘问时，一个有用的技巧是使用
+git（尤其是“git-logâ€ï¼‰æŸ¥çœ‹æ„Ÿå…´è¶£çš„å系统ä¸å½“å‰æ´»åŠ¨çš„用户。看看è°åœ¨å†™è¡¥ä¸ï¼Œ
+如果有人的è¯ï¼Œè°ä¼šåœ¨è¿™äº›è¡¥ä¸ä¸ŠåŠ 上用线ç¾å的。这些人将是帮助新开å‘项目的最佳
+人选。
+
+找到åˆé€‚的维护者的任务有时是éžå¸¸å…·æœ‰æŒ‘æˆ˜æ€§çš„ï¼Œä»¥è‡³äºŽå†…æ ¸å¼€å‘äººå‘˜æ·»åŠ äº†ä¸€ä¸ª
+脚本æ¥ç®€åŒ–过程：
+
+::
+
+ .../scripts/get_maintainer.pl
+
+当给定“-fâ€é€‰é¡¹æ—¶ï¼Œæ¤è„šæœ¬å°†è¿”回给定文件或目录的当å‰ç»´æŠ¤è€…ã€‚å¦‚æžœåœ¨å‘½ä»¤è¡Œä¸Šä¼ é€’
+了一个补ä¸ï¼Œå®ƒå°†åˆ—出å¯èƒ½æŽ¥æ”¶è¡¥ä¸å‰¯æœ¬çš„维护人员。有许多选项å¯ä»¥è°ƒèŠ‚
+get_maintainer.plæœç´¢ç»´æŠ¤è€…的难易程度；请å°å¿ƒä½¿ç”¨æ›´å…·æ”»å‡»æ€§çš„é€‰é¡¹ï¼Œå› ä¸ºæœ€ç»ˆ
+å¯èƒ½ä¼šåŒ…括对您æ£åœ¨ä¿®æ”¹çš„代ç 没有真æ£å…´è¶£çš„å¼€å‘人员。
+
+如果所有其他方法都失败了，那么与Andrew Morton交谈å¯ä»¥æˆä¸ºä¸€ç§æœ‰æ•ˆçš„方法æ¥è·Ÿè¸ª
+特定代ç 段的维护人员。
+
+何时邮寄？
+----------
+
+如果å¯èƒ½çš„è¯ï¼Œåœ¨æ—©æœŸé˜¶æ®µå‘å¸ƒä½ çš„è®¡åˆ’åªä¼šæœ‰å¸®åŠ©ã€‚æè¿°æ£åœ¨è§£å†³çš„问题以åŠå·²ç»
+制定的关于如何实施的任何计划。您å¯ä»¥æ供的任何信æ¯éƒ½å¯ä»¥å¸®åŠ©å¼€å‘社区为项目
+æ供有用的输入。
+
+在这个阶段å¯èƒ½å‘生的一件令人沮丧的事情ä¸æ˜¯æ•Œå¯¹çš„ååº”ï¼Œè€Œæ˜¯å¾ˆå°‘æˆ–æ ¹æœ¬æ²¡æœ‰
+å应。å¯æ‚²çš„事实是：（1ï¼‰å†…æ ¸å¼€å‘人员往往很忙；（2）ä¸ç¼ºå°‘有å®ä¼Ÿè®¡åˆ’和很少
+代ç （甚至代ç å‰æ™¯ï¼‰æ”¯æŒä»–们的人；（3）没有人有义务审查或评论别人å‘表的
+想法。除æ¤ä¹‹å¤–，高级设计常常éšè—一些问题，这些问题åªæœ‰åœ¨æœ‰äººçœŸæ£å°è¯•å®žçŽ°
+这些设计时æ‰ä¼šè¢«å‘çŽ°ï¼›å› æ¤ï¼Œå†…æ ¸å¼€å‘人员å®æ„¿çœ‹åˆ°ä»£ç 。
+
+如果å‘表评论的请求在评论的方å¼ä¸Šæ²¡æœ‰ä»€ä¹ˆæ•ˆæžœï¼Œä¸è¦å‡è®¾è¿™æ„味ç€å¯¹é¡¹ç›®æ²¡æœ‰
+兴趣。ä¸å¹¸çš„æ˜¯ï¼Œä½ ä¹Ÿä¸èƒ½å‡è®¾ä½ 的想法没有问题。在这ç§æƒ…况下，最好的åšæ³•æ˜¯
+继ç»è¿›è¡Œï¼ŒæŠŠä½ 的进展éšæ—¶é€šçŸ¥ç¤¾åŒºã€‚
+
+获得官方认å¯
+-----------------------
+
+如果您的工作是在公å¸çŽ¯å¢ƒä¸å®Œæˆçš„，就åƒå¤§å¤šæ•°Linuxå†…æ ¸å·¥ä½œä¸€æ ·ï¼Œæ˜¾ç„¶ï¼Œåœ¨æ‚¨å°†
+å…¬å¸çš„计划或代ç å‘布到公共邮件列表之å‰ï¼Œå¿…须获得适当授æƒçš„ç»ç†çš„许å¯ã€‚å‘布
+ä¸ç¡®å®šæ˜¯å¦å…¼å®¹GPL的代ç å¯èƒ½æ˜¯æœ‰ç‰¹åˆ«é—®é¢˜çš„；公å¸çš„管ç†å±‚和法律人员越早能够就
+å‘å¸ƒå†…æ ¸å¼€å‘项目达æˆä¸€è‡´ï¼Œå¯¹å‚与的æ¯ä¸ªäººéƒ½è¶Šå¥½ã€‚
+
+一些读者å¯èƒ½ä¼šè®¤ä¸ºä»–ä»¬çš„æ ¸å¿ƒå·¥ä½œæ˜¯ä¸ºäº†æ”¯æŒè¿˜æ²¡æœ‰æ£å¼æ‰¿è®¤å˜åœ¨çš„产å“。将雇主
+的计划公布在公共邮件列表上å¯èƒ½ä¸æ˜¯ä¸€ä¸ªå¯è¡Œçš„选择。在这ç§æƒ…况下，有必è¦è€ƒè™‘
+ä¿å¯†æ˜¯å¦çœŸçš„是必è¦çš„；通常ä¸éœ€è¦æŠŠå¼€å‘计划关在门内。
+
+也就是说，有些情况下，一家公å¸åœ¨å¼€å‘过程的早期就ä¸èƒ½åˆæ³•åœ°æŠ«éœ²å…¶è®¡åˆ’。拥有
+ç»éªŒä¸°å¯Œçš„å†…æ ¸å¼€å‘人员的公å¸å¯ä»¥é€‰æ‹©ä»¥å¼€çŽ¯çš„æ–¹å¼è¿›è¡Œï¼Œå‰æ是他们以åŽèƒ½å¤Ÿé¿å…
+严é‡çš„集æˆé—®é¢˜ã€‚对于没有这ç§å†…部专业知识的公å¸ï¼Œæœ€å¥½çš„选择往往是è˜è¯·å¤–部
+å¼€å‘å•†æ ¹æ®ä¿å¯†å议审查计划。Linux基金会è¿è¡Œäº†ä¸€ä¸ªNDA程åºï¼Œæ—¨åœ¨å¸®åŠ©è§£å†³è¿™ç§
+情况；
+
+ http://www.linuxfoundation.org/en/NDA_program
+
+è¿™ç§å®¡æŸ¥é€šå¸¸è¶³ä»¥é¿å…以åŽå‡ºçŽ°ä¸¥é‡é—®é¢˜ï¼Œè€Œæ— 需公开披露项目。
diff --git a/Documentation/translations/zh_CN/process/4.Coding.rst b/Documentation/translations/zh_CN/process/4.Coding.rst
new file mode 100644
index 0000000000000000000000000000000000000000..5301e9d55255496c40211f651c1ca9a150abe34a
--- /dev/null
+++ b/Documentation/translations/zh_CN/process/4.Coding.rst
@@ -0,0 +1,290 @@
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: :ref:`Documentation/process/4.Coding.rst <development_coding>`
+:Translator: Alex Shi <alex.shi@linux.alibaba.com>
+
+.. _cn_development_coding:
+
+使代ç æ£ç¡®
+======================
+
+虽然对于一个åšå®žçš„ã€é¢å‘社区的设计过程有很多è¯è¦è¯´ï¼Œä½†æ˜¯ä»»ä½•å†…æ ¸å¼€å‘项目的
+è¯æ˜Žéƒ½åœ¨ç”Ÿæˆçš„代ç ä¸ã€‚它是将由其他开å‘人员检查并åˆå¹¶ï¼ˆæˆ–ä¸åˆå¹¶ï¼‰åˆ°ä¸»çº¿æ ‘ä¸
+的代ç 。所以这段代ç çš„è´¨é‡å†³å®šäº†é¡¹ç›®çš„最终æˆåŠŸã€‚
+
+本节将检查编ç è¿‡ç¨‹ã€‚æˆ‘ä»¬å°†ä»Žå†…æ ¸å¼€å‘äººå‘˜å‡ºé”™çš„å‡ ç§æ–¹å¼å¼€å§‹ã€‚然åŽé‡ç‚¹å°†è½¬ç§»
+到æ£ç¡®çš„事情和å¯ä»¥å¸®åŠ©è¿™ä¸ªä»»åŠ¡çš„工具上。
+
+陷阱
+----
+
+ç¼–ç é£Žæ ¼
+********
+
+å†…æ ¸é•¿æœŸä»¥æ¥éƒ½æœ‰ä¸€ç§æ ‡å‡†çš„ç¼–ç é£Žæ ¼ï¼Œå¦‚
+:ref:`Documentation/translations/zh_CN/process/coding-style.rst <cn_codingstyle>`
+ä¸æ‰€è¿°ã€‚在大部分时间里，该文件ä¸æ述的政ç–è¢«è®¤ä¸ºè‡³å¤šæ˜¯å»ºè®®æ€§çš„ã€‚å› æ¤ï¼Œå†…æ ¸
+ä¸å˜åœ¨å¤§é‡ä¸ç¬¦åˆç¼–ç é£Žæ ¼å‡†åˆ™çš„ä»£ç 。代ç çš„å˜åœ¨ä¼šç»™å†…æ ¸å¼€å‘人员带æ¥ä¸¤ä¸ªç‹¬ç«‹
+çš„å±å®³ã€‚
+
+首先，è¦ç›¸ä¿¡å†…æ ¸ç¼–ç æ ‡å‡†å¹¶ä¸é‡è¦ï¼Œä¹Ÿä¸å¼ºåˆ¶æ‰§è¡Œã€‚äº‹å®žä¸Šï¼Œå¦‚æžœæ²¡æœ‰æŒ‰ç…§æ ‡å‡†å¯¹ä»£
+ç 进行编ç ，那么å‘å†…æ ¸æ·»åŠ æ–°ä»£ç 是éžå¸¸å›°éš¾çš„；许多开å‘人员甚至会在审查代ç 之
+å‰è¦æ±‚对代ç 进行é‡æ–°æ ¼å¼åŒ–ã€‚ä¸€ä¸ªä¸Žå†…æ ¸ä¸€æ ·å¤§çš„ä»£ç 库需è¦ä¸€äº›ç»Ÿä¸€çš„代ç ，以使
+å¼€å‘人员能够快速ç†è§£å…¶ä¸çš„任何部分。所以已ç»æ²¡æœ‰ç©ºé—´æ¥å˜æ”¾å¥‡æ€ªçš„æ ¼å¼åŒ–代ç 了。
+
+å¶å°”ï¼Œå†…æ ¸çš„ç¼–ç é£Žæ ¼ä¼šä¸Žé›‡ä¸»çš„å¼ºåˆ¶é£Žæ ¼å‘生冲çªã€‚在这ç§æƒ…å†µä¸‹ï¼Œå†…æ ¸çš„é£Žæ ¼å¿…é¡»
+在代ç åˆå¹¶ä¹‹å‰èŽ·èƒœã€‚将代ç æ”¾å…¥å†…æ ¸æ„味ç€ä»¥å¤šç§æ–¹å¼æ”¾å¼ƒä¸€å®šç¨‹åº¦çš„控制æƒâ€”—包括
+控制代ç çš„æ ¼å¼åŒ–æ–¹å¼ã€‚
+
+å¦ä¸€ä¸ªé™·é˜±æ˜¯å‡å®šå·²ç»åœ¨å†…æ ¸ä¸çš„代ç 迫切需è¦ç¼–ç æ ·å¼çš„ä¿®å¤ã€‚å¼€å‘人员å¯èƒ½ä¼šå¼€å§‹
+生æˆé‡æ–°æ ¼å¼åŒ–è¡¥ä¸ï¼Œä½œä¸ºç†Ÿæ‚‰è¿‡ç¨‹çš„一ç§æ–¹å¼ï¼Œæˆ–者作为将其åç§°å†™å…¥å†…æ ¸å˜æ›´æ—¥å¿—
+的一ç§æ–¹å¼ï¼Œæˆ–者两者兼而有之。但是纯编ç é£Žæ ¼çš„ä¿®å¤è¢«å¼€å‘社区视为噪音；它们往
+å¾€å—到冷é‡ã€‚å› æ¤ï¼Œæœ€å¥½é¿å…使用这ç§ç±»åž‹çš„è¡¥ä¸ã€‚ç”±äºŽå…¶ä»–åŽŸå› ï¼Œåœ¨å¤„ç†ä¸€æ®µä»£ç çš„
+åŒæ—¶ä¿®å¤å®ƒçš„æ ·å¼æ˜¯å¾ˆè‡ªç„¶çš„，但是编ç æ ·å¼çš„更改ä¸åº”该仅为了更改而进行。
+
+ç¼–ç é£Žæ ¼çš„æ–‡æ¡£ä¹Ÿä¸åº”该被视为ç»å¯¹çš„法律，这是永远ä¸ä¼šè¢«è¿å的。如果有一个很好
+çš„ç†ç”±å对这ç§æ ·å¼ï¼ˆä¾‹å¦‚，如果拆分为适åˆ80列é™åˆ¶çš„行，那么它的å¯è¯»æ€§å°±ä¼šå¤§å¤§
+é™ä½Žï¼‰ï¼Œé‚£ä¹ˆå°±è¿™æ ·åšã€‚
+
+请注æ„，您还å¯ä»¥ä½¿ç”¨ ``clang-format`` 工具æ¥å¸®åŠ©æ‚¨å¤„ç†è¿™äº›è§„则，自动é‡æ–°æ ¼å¼
+化部分代ç ，并查看完整的文件，以å‘现编ç æ ·å¼é”™è¯¯ã€æ‹¼å†™é”™è¯¯å’Œå¯èƒ½çš„改进。它还
+å¯ä»¥æ–¹ä¾¿åœ°è¿›è¡ŒæŽ’åºï¼ŒåŒ…括对é½å˜é‡/å®ã€å›žæµæ–‡æœ¬å’Œå…¶ä»–类似任务。有关详细信æ¯ï¼Œè¯·
+å‚阅文件 :ref:`Documentation/process/clang-format.rst <clangformat>`
+
+抽象层
+******
+
+计算机科å¦æ•™æŽˆæ•™å¦ç”Ÿä»¥çµæ´»æ€§å’Œä¿¡æ¯éšè—çš„åä¹‰å¹¿æ³›ä½¿ç”¨æŠ½è±¡å±‚ã€‚å½“ç„¶ï¼Œå†…æ ¸å¹¿æ³›
+地使用了抽象；任何涉åŠæ•°ç™¾ä¸‡è¡Œä»£ç 的项目都ä¸èƒ½åšåˆ°è¿™ä¸€ç‚¹å¹¶å˜æ´»ä¸‹æ¥ã€‚但ç»éªŒ
+表明，过度或过早的抽象å¯èƒ½å’Œè¿‡æ—©çš„ä¼˜åŒ–ä¸€æ ·æœ‰å®³ã€‚æŠ½è±¡åº”ç”¨äºŽæ‰€éœ€çš„çº§åˆ«ï¼Œ
+ä¸è¦è¿‡åº¦ã€‚
+
+在一个简å•çš„级别上，考虑一个函数的å‚数，该å‚æ•°æ€»æ˜¯ç”±æ‰€æœ‰è°ƒç”¨æ–¹ä½œä¸ºé›¶ä¼ é€’ã€‚
+我们å¯ä»¥ä¿ç•™è¿™ä¸ªè®ºç‚¹: 以防有人最终需è¦ä½¿ç”¨å®ƒæ供的é¢å¤–çµæ´»æ€§ã€‚ä¸è¿‡ï¼Œåˆ°é‚£æ—¶ï¼Œ
+实现这个é¢å¤–å‚数的代ç 很有å¯èƒ½ä»¥æŸç§ä»Žæœªè¢«æ³¨æ„到的微妙方å¼è¢«ç ´åâ€”â€”å› ä¸ºå®ƒä»Ž
+未被使用过。或者，当需è¦é¢å¤–çš„çµæ´»æ€§æ—¶ï¼Œå®ƒä¸ä¼šä»¥ç¬¦åˆç¨‹åºå‘˜æ—©æœŸæœŸæœ›çš„æ–¹å¼æ¥
+è¿™æ ·åšã€‚å†…æ ¸å¼€å‘人员通常会æ交补ä¸æ¥åˆ 除未使用的å‚数；一般æ¥è¯´ï¼Œé¦–å…ˆä¸åº”该
+æ·»åŠ è¿™äº›å‚数。
+
+éšè—硬件访问的抽象层——通常å…许大é‡çš„驱动程åºåœ¨å¤šä¸ªæ“作系统ä¸ä½¿ç”¨â€”—尤其ä¸å—
+æ¬¢è¿Žã€‚è¿™æ ·çš„å±‚ä½¿ä»£ç å˜å¾—模糊，å¯èƒ½ä¼šé€ æˆæ€§èƒ½æŸå¤±ï¼›å®ƒä»¬ä¸å±žäºŽLinuxå†…æ ¸ã€‚
+
+å¦ä¸€æ–¹é¢ï¼Œå¦‚果您å‘现自己从å¦ä¸€ä¸ªå†…æ ¸å系统å¤åˆ¶äº†å¤§é‡çš„代ç ，那么现在是时候
+问一下，事实上，将这些代ç ä¸çš„一些æå–到å•ç‹¬çš„库ä¸ï¼Œæˆ–者在更高的层次上实现
+这些功能是å¦æœ‰æ„ä¹‰ã€‚åœ¨æ•´ä¸ªå†…æ ¸ä¸å¤åˆ¶ç›¸åŒçš„代ç 没有价值。
+
+#ifdef 和预处ç†
+***************
+
+C预处ç†å™¨ä¼¼ä¹Žç»™ä¸€äº›C程åºå‘˜å¸¦æ¥äº†å¼ºå¤§çš„诱惑，他们认为它是一ç§æœ‰æ•ˆåœ°å°†å¤§é‡çµ
+活性编ç 到æºæ–‡ä»¶ä¸çš„方法。但是预处ç†å™¨ä¸æ˜¯C，大é‡ä½¿ç”¨å®ƒä¼šå¯¼è‡´ä»£ç 对其他人æ¥
+说更难读å–，对编译器æ¥è¯´æ›´éš¾æ£€æŸ¥æ£ç¡®æ€§ã€‚大é‡çš„预处ç†å™¨å‡ 乎总是代ç 需è¦ä¸€äº›
+清ç†å·¥ä½œçš„æ ‡å¿—ã€‚
+
+使用ifdefçš„æ¡ä»¶ç¼–è¯‘å®žé™…ä¸Šæ˜¯ä¸€ä¸ªå¼ºå¤§çš„åŠŸèƒ½ï¼Œå®ƒåœ¨å†…æ ¸ä¸ä½¿ç”¨ã€‚但是很少有人希望
+看到代ç 被大é‡åœ°æ’’上ifdefå—。作为一般规则，ifdef的使用应尽å¯èƒ½é™åˆ¶åœ¨å¤´æ–‡ä»¶
+ä¸ã€‚有æ¡ä»¶ç¼–译的代ç å¯ä»¥é™åˆ¶å‡½æ•°ï¼Œå¦‚果代ç ä¸å˜åœ¨ï¼Œè¿™äº›å‡½æ•°å°±ä¼šå˜æˆç©ºçš„。然åŽ
+编译器将悄悄地优化对空函数的调用。结果是代ç æ›´åŠ æ¸…æ™°ï¼Œæ›´å®¹æ˜“ç†è§£ã€‚
+
+C预处ç†å™¨å®å˜åœ¨è®¸å¤šå±é™©ï¼ŒåŒ…括å¯èƒ½å¯¹å…·æœ‰å‰¯ä½œç”¨ä¸”没有类型安全性的表达å¼è¿›è¡Œå¤š
+é‡è¯„估。如果您试图定义å®ï¼Œè¯·è€ƒè™‘创建一个内è”函数。结果相åŒçš„代ç ，但是内è”
+函数更容易读å–，ä¸ä¼šå¤šæ¬¡è®¡ç®—å…¶å‚数，并且å…许编译器对å‚数和返回值执行类型检查。
+
+内è”函数
+********
+
+ä¸è¿‡ï¼Œå†…è”函数本身也å˜åœ¨é£Žé™©ã€‚程åºå‘˜å¯ä»¥å€¾å¿ƒäºŽé¿å…函数调用和用内è”函数填充æº
+文件所固有的效率。然而，这些功能实际上会é™ä½Žæ€§èƒ½ã€‚å› ä¸ºå®ƒä»¬çš„ä»£ç 在æ¯ä¸ªè°ƒç”¨ç«™
+点都被å¤åˆ¶ï¼Œæ‰€ä»¥å®ƒä»¬æœ€ç»ˆä¼šå¢žåŠ ç¼–è¯‘å†…æ ¸çš„å¤§å°ã€‚å过æ¥ï¼Œè¿™ä¼šå¯¹å¤„ç†å™¨çš„内å˜ç¼“å˜
+é€ æˆåŽ‹åŠ›ï¼Œä»Žè€Œå¤§å¤§é™ä½Žæ‰§è¡Œé€Ÿåº¦ã€‚通常，内è”函数应该éžå¸¸å°ï¼Œè€Œä¸”相对较少。毕竟，
+函数调用的æˆæœ¬å¹¶ä¸é«˜ï¼›å¤§é‡å†…è”函数的创建是过早优化的典型例å。
+
+一般æ¥è¯´ï¼Œå†…æ ¸ç¨‹åºå‘˜ä¼šå¿½ç•¥ç¼“å˜æ•ˆæžœï¼Œè¿™ä¼šå¸¦æ¥å±é™©ã€‚在开始的数æ®ç»“构课程ä¸ï¼Œç»
+典的时间/空间æƒè¡¡é€šå¸¸ä¸é€‚ç”¨äºŽå½“ä»£ç¡¬ä»¶ã€‚ç©ºé—´å°±æ˜¯æ—¶é—´ï¼Œå› ä¸ºä¸€ä¸ªå¤§çš„ç¨‹åºæ¯”一个
+更紧凑的程åºè¿è¡Œå¾—慢。
+
+最近的编译器在决定一个给定函数是å¦åº”该被内è”æ–¹é¢æ‰®æ¼”ç€è¶Šæ¥è¶Šç§¯æžçš„角色。
+å› æ¤ï¼Œâ€œinlineâ€å…³é”®å—的自由放置å¯èƒ½ä¸ä»…仅是过度的，它也å¯èƒ½æ˜¯æ— 关的。
+
+é”
+**
+
+2006å¹´5月，“deviceescapeâ€ç½‘ç»œå †æ ˆåœ¨GPL下å‘å¸ƒï¼Œå¹¶è¢«çº³å…¥ä¸»çº¿å†…æ ¸ã€‚è¿™æ˜¯ä¸€ä¸ªå—
+欢迎的消æ¯ï¼›å¯¹Linuxä¸æ— 线网络的支æŒå……å…¶é‡è¢«è®¤ä¸ºæ˜¯ä¸åˆæ ¼çš„，而deviceescape
+å †æ ˆæ供了修å¤è¿™ç§æƒ…况的承诺。然而，直到2007å¹´6月（2.6.22），这段代ç æ‰çœŸ
+æ£è¿›å…¥ä¸»çº¿ã€‚å‘生了什么？
+
+这段代ç 显示了许多é—é—¨é€ è½¦çš„è¿¹è±¡ã€‚ä½†ä¸€ä¸ªç‰¹åˆ«å¤§çš„é—®é¢˜æ˜¯ï¼Œå®ƒå¹¶ä¸æ˜¯è®¾è®¡ç”¨äºŽå¤š
+处ç†å™¨ç³»ç»Ÿã€‚在åˆå¹¶è¿™ä¸ªç½‘ç»œå †æ ˆï¼ˆçŽ°åœ¨ç§°ä¸ºmac80211）之å‰ï¼Œéœ€è¦å¯¹å…¶è¿›è¡Œä¸€ä¸ªé”
+æ–¹æ¡ˆçš„æ”¹é€ ã€‚
+
+曾ç»ï¼ŒLinuxå†…æ ¸ä»£ç å¯ä»¥åœ¨ä¸è€ƒè™‘多处ç†å™¨ç³»ç»Ÿæ‰€å¸¦æ¥çš„并å‘性问题的情况下进行
+å¼€å‘。然而，现在，这个文件是写在åŒæ ¸ç¬”记本电脑上的。å³ä½¿åœ¨å•å¤„ç†å™¨ç³»ç»Ÿä¸Šï¼Œ
+为æ高å“应能力所åšçš„工作也会æé«˜å†…æ ¸å†…çš„å¹¶å‘æ€§æ°´å¹³ã€‚ç¼–å†™å†…æ ¸ä»£ç 而ä¸è€ƒè™‘é”
+çš„æ—¥åå·²ç»è¿‡åŽ»å¾ˆé•¿äº†ã€‚
+
+å¯ä»¥ç”±å¤šä¸ªçº¿ç¨‹å¹¶å‘访问的任何资æºï¼ˆæ•°æ®ç»“æž„ã€ç¡¬ä»¶å¯„å˜å™¨ç‰ï¼‰å¿…须由é”ä¿æŠ¤ã€‚æ–°
+的代ç 应该记ä½è¿™ä¸€è¦æ±‚；事åŽæ”¹è£…é”æ˜¯ä¸€é¡¹ç›¸å½“å›°éš¾çš„ä»»åŠ¡ã€‚å†…æ ¸å¼€å‘人员应该花
+时间充分了解å¯ç”¨çš„é”原è¯ï¼Œä»¥ä¾¿ä¸ºä½œä¸šé€‰æ‹©æ£ç¡®çš„工具。显示对并å‘性缺ä¹å…³æ³¨çš„
+代ç 进入主线将很困难。
+
+回归
+****
+
+最åŽä¸€ä¸ªå€¼å¾—一æçš„å±é™©æ˜¯ï¼šå®ƒå¯èƒ½ä¼šå¼•èµ·æ”¹å˜ï¼ˆè¿™å¯èƒ½ä¼šå¸¦æ¥å¾ˆå¤§çš„改进），从而
+导致现有用户的æŸäº›ä¸œè¥¿ä¸æ–。这ç§å˜åŒ–被称为“回归â€ï¼Œå›žå½’å·²ç»æˆä¸ºä¸»çº¿å†…æ ¸æœ€ä¸
+å—欢迎的。除少数例外情况外，如果回归ä¸èƒ½åŠæ—¶ä¿®æ£ï¼Œä¼šå¯¼è‡´å›žå½’çš„å˜åŒ–将被å–消。
+最好首先é¿å…回归。
+
+人们常常争论，如果回归让更多人å¯ä»¥å·¥ä½œï¼Œè¿œè¶…过产生问题，那么回归是åˆç†çš„。
+å¦‚æžœå®ƒç ´å的一个系统å´ä¸ºå个系统带æ¥æ–°çš„功能，为什么ä¸è¿›è¡Œæ›´æ”¹å‘¢ï¼Ÿ2007å¹´7月，
+Linus对这个问题给出了最佳ç”案:
+
+::
+ 所以我们ä¸ä¼šé€šè¿‡å¼•å…¥æ–°é—®é¢˜æ¥ä¿®å¤é”™è¯¯ã€‚é‚£æ ·çš„è°Žè¨€å¾ˆç–¯ç‹‚ï¼Œæ²¡æœ‰äººçŸ¥é“
+ ä½ æ˜¯å¦çœŸçš„有进展。是å‰è¿›ä¸¤æ¥ï¼ŒåŽé€€ä¸€æ¥ï¼Œè¿˜æ˜¯å‘å‰ä¸€æ¥ï¼Œå‘åŽä¸¤æ¥ï¼Ÿ
+
+（http://lwn.net/articles/243460/）
+
+一ç§ç‰¹åˆ«ä¸å—欢迎的回归类型是用户空间ABI的任何å˜åŒ–。一旦接å£è¢«å¯¼å‡ºåˆ°ç”¨æˆ·ç©ºé—´ï¼Œ
+å°±å¿…é¡»æ— é™æœŸåœ°æ”¯æŒå®ƒã€‚这一事实使得用户空间接å£çš„åˆ›å»ºç‰¹åˆ«å…·æœ‰æŒ‘æˆ˜æ€§ï¼šå› ä¸ºå®ƒä»¬
+ä¸èƒ½ä»¥ä¸å…¼å®¹çš„æ–¹å¼è¿›è¡Œæ›´æ”¹ï¼Œæ‰€ä»¥å¿…须第一次æ£ç¡®åœ°è¿›è¡Œæ›´æ”¹ã€‚å› æ¤ï¼Œç”¨æˆ·ç©ºé—´ç•Œé¢
+总是需è¦å¤§é‡çš„æ€è€ƒã€æ¸…晰的文档和广泛的审查。
+
+
+代ç 检查工具
+------------
+
+至少目å‰ï¼Œç¼–å†™æ— é”™è¯¯ä»£ç ä»ç„¶æ˜¯æˆ‘们ä¸å¾ˆå°‘人能达到的ç†æƒ³çŠ¶æ€ã€‚ä¸è¿‡ï¼Œæˆ‘们希望åš
+的是，在代ç è¿›å…¥ä¸»çº¿å†…æ ¸ä¹‹å‰ï¼Œå°½å¯èƒ½å¤šåœ°æ•èŽ·å¹¶ä¿®å¤è¿™äº›é”™è¯¯ã€‚为æ¤ï¼Œå†…æ ¸å¼€å‘人
+员已ç»ç»„装了一系列令人å°è±¡æ·±åˆ»çš„工具，å¯ä»¥è‡ªåŠ¨æ•èŽ·å„ç§å„æ ·çš„æ¨¡ç³Šé—®é¢˜ã€‚è®¡ç®—æœº
+å‘现的任何问题都是一个以åŽä¸ä¼šå›°æ‰°ç”¨æˆ·çš„é—®é¢˜ï¼Œå› æ¤ï¼Œåªè¦æœ‰å¯èƒ½ï¼Œå°±åº”该使用
+自动化工具。
+
+第一æ¥åªæ˜¯æ³¨æ„编译器产生的è¦å‘Šã€‚当代版本的GCCå¯ä»¥æ£€æµ‹ï¼ˆå¹¶è¦å‘Šï¼‰å¤§é‡æ½œåœ¨é”™è¯¯ã€‚
+通常，这些è¦å‘Šéƒ½æŒ‡å‘真æ£çš„问题。æ交以供审阅的代ç 通常ä¸ä¼šäº§ç”Ÿä»»ä½•ç¼–译器è¦å‘Šã€‚
+在消除è¦å‘Šæ—¶ï¼Œæ³¨æ„了解真æ£çš„åŽŸå› ï¼Œå¹¶å°½é‡é¿å…“修å¤â€ï¼Œä½¿è¦å‘Šæ¶ˆå¤±è€Œä¸è§£å†³å…¶åŽŸå› 。
+
+请注æ„，并éžæ‰€æœ‰ç¼–译器è¦å‘Šéƒ½é»˜è®¤å¯ç”¨ã€‚使用“make EXTRA_CFLAGS=-Wâ€æž„å»ºå†…æ ¸ä»¥
+获得完整集åˆã€‚
+
+å†…æ ¸æä¾›äº†å‡ ä¸ªé…置选项，å¯ä»¥æ‰“开调试功能；大多数é…置选项ä½äºŽâ€œkernel hackingâ€
+åèœå•ä¸ã€‚对于任何用于开å‘æˆ–æµ‹è¯•ç›®çš„çš„å†…æ ¸ï¼Œéƒ½åº”è¯¥å¯ç”¨å…¶ä¸å‡ 个选项。特别是，
+您应该打开：
+
+ - å¯ç”¨ ENABLE_MUST_CHECK and FRAME_WARN 以获得一组é¢å¤–çš„è¦å‘Šï¼Œä»¥è§£å†³ä½¿ç”¨ä¸
+ 推è使用的接å£æˆ–忽略函数的é‡è¦è¿”回值ç‰é—®é¢˜ã€‚这些è¦å‘Šç”Ÿæˆçš„输出å¯èƒ½æ˜¯å†—é•¿
+ 的，但您ä¸å¿…担心æ¥è‡ªå†…æ ¸å…¶ä»–éƒ¨åˆ†çš„è¦å‘Šã€‚
+
+ - DEBUG_OBJECTS å°†æ·»åŠ ä»£ç ï¼Œä»¥è·Ÿè¸ªå†…æ ¸åˆ›å»ºçš„å„ç§å¯¹è±¡çš„生å˜æœŸï¼Œå¹¶åœ¨å‡ºçŽ°é—®é¢˜æ—¶
+ å‘出è¦å‘Šã€‚如果è¦æ·»åŠ 创建（和导出）自己的å¤æ‚对象的åç³»ç»Ÿï¼Œè¯·è€ƒè™‘æ·»åŠ å¯¹å¯¹è±¡
+ 调试基础结构的支æŒã€‚
+
+ - DEBUG_SLAB å¯ä»¥å‘现å„ç§å†…å˜åˆ†é…和使用错误；它应该用于大多数开å‘å†…æ ¸ã€‚
+
+ - DEBUG_SPINLOCK, DEBUG_ATOMIC_SLEEP and DEBUG_MUTEXES 会å‘现许多常è§çš„
+ é”定错误.
+
+还有很多其他调试选项，其ä¸ä¸€äº›å°†åœ¨ä¸‹é¢è®¨è®ºã€‚å…¶ä¸ä¸€äº›å…·æœ‰æ˜¾è‘—的性能影å“，ä¸åº”
+一直使用。但是，在å¦ä¹ å¯ç”¨é€‰é¡¹ä¸ŠèŠ±è´¹çš„一些时间å¯èƒ½ä¼šåœ¨çŸæœŸå†…得到多次回报。
+
+å…¶ä¸ä¸€ä¸ªè¾ƒé‡çš„调试工具是é”定检查器或“lockdepâ€ã€‚该工具将跟踪系统ä¸æ¯ä¸ªé”
+（spinlock或mutex）的获å–和释放ã€èŽ·å–é”的相对顺åºã€å½“å‰ä¸æ–环境ç‰ç‰ã€‚然åŽï¼Œ
+它å¯ä»¥ç¡®ä¿æ€»æ˜¯ä»¥ç›¸åŒçš„顺åºèŽ·å–é”，相åŒçš„ä¸æ–å‡è®¾é€‚用于所有情况，ç‰ç‰ã€‚æ¢å¥è¯
+说，lockdepå¯ä»¥æ‰¾åˆ°è®¸å¤šåœºæ™¯ï¼Œåœ¨è¿™äº›åœºæ™¯ä¸ï¼Œç³»ç»Ÿå¾ˆå°‘会æ»é”。在部署的系统ä¸ï¼Œ
+è¿™ç§é—®é¢˜å¯èƒ½ä¼šå¾ˆç—›è‹¦ï¼ˆå¯¹äºŽå¼€å‘人员和用户而言）；LockDepå…许æå‰ä»¥è‡ªåŠ¨æ–¹å¼
+å‘现问题。具有任何类型的éžæ™®é€šé”定的代ç 在æ交包å«å‰åº”在å¯ç”¨lockdep的情况
+下è¿è¡Œã€‚
+
+ä½œä¸ºä¸€ä¸ªå‹¤å¥‹çš„å†…æ ¸ç¨‹åºå‘˜ï¼Œæ¯«æ— 疑问，您将检查任何å¯èƒ½å¤±è´¥çš„æ“作（如内å˜åˆ†é…）
+的返回状æ€ã€‚然而，事实上，最终的故障æ¢å¤è·¯å¾„å¯èƒ½å®Œå…¨æ²¡æœ‰ç»è¿‡æµ‹è¯•ã€‚未测试的
+代ç å¾€å¾€ä¼šè¢«ç ´å；如果所有这些错误处ç†è·¯å¾„éƒ½è¢«æ‰§è¡Œäº†å‡ æ¬¡ï¼Œé‚£ä¹ˆæ‚¨å¯èƒ½å¯¹ä»£ç
+更有信心。
+
+å†…æ ¸æ供了一个å¯ä»¥åšåˆ°è¿™ä¸€ç‚¹çš„错误注入框架，特别是在涉åŠå†…å˜åˆ†é…的情况下。
+å¯ç”¨æ•…障注入åŽï¼Œå†…å˜åˆ†é…çš„å¯é…置百分比将失败；这些失败å¯ä»¥é™åˆ¶åœ¨ç‰¹å®šçš„代ç
+范围内。在å¯ç”¨äº†æ•…障注入的情况下è¿è¡Œï¼Œç¨‹åºå‘˜å¯ä»¥çœ‹åˆ°å½“情况æ¶åŒ–时代ç 如何å“
+应。有关如何使用æ¤å·¥å…·çš„详细信æ¯ï¼Œè¯·å‚阅
+Documentation/fault-injection/fault-injection.txt。
+
+使用“sparseâ€é™æ€åˆ†æžå·¥å…·å¯ä»¥å‘现其他类型的错误。对于sparse，å¯ä»¥è¦å‘Šç¨‹åºå‘˜
+ç”¨æˆ·ç©ºé—´å’Œå†…æ ¸ç©ºé—´åœ°å€ä¹‹é—´çš„æ··æ·†ã€big endianå’Œsmall endianæ•°é‡çš„æ··åˆã€åœ¨éœ€
+è¦ä¸€ç»„ä½æ ‡å¿—çš„åœ°æ–¹ä¼ é€’æ•´æ•°å€¼ç‰ç‰ã€‚sparseå¿…é¡»å•ç‹¬å®‰è£…(如果您的分å‘æœåŠ¡å™¨æ²¡
+有将其打包，å¯ä»¥åœ¨ https://sparse.wiki.kernel.org/index.php/Main_page)找到,
+然åŽå¯ä»¥é€šè¿‡åœ¨make命令ä¸æ·»åŠ “C=1â€åœ¨ä»£ç 上è¿è¡Œå®ƒã€‚
+
+“Coccinelleâ€å·¥å…· :ref:`http://coccinelle.lip6.fr/ <devtools_coccinelle>`
+能够å‘现å„ç§æ½œåœ¨çš„ç¼–ç 问题；它还å¯ä»¥ä¸ºè¿™äº›é—®é¢˜æ出修å¤æ–¹æ¡ˆã€‚在
+scripts/coccinelle目录下已ç»æ‰“åŒ…äº†ç›¸å½“å¤šçš„å†…æ ¸â€œè¯ä¹‰è¡¥ä¸â€ï¼›è¿è¡Œ
+“make coccicheckâ€å°†è¿è¡Œè¿™äº›è¯ä¹‰è¡¥ä¸å¹¶æŠ¥å‘Šå‘现的任何问题。有关详细信æ¯ï¼Œè¯·å‚阅
+:ref:`Documentation/dev-tools/coccinelle.rst <devtools_coccinelle>`
+
+
+其他类型的å¯ç§»æ¤æ€§é”™è¯¯æœ€å¥½é€šè¿‡ä¸ºå…¶ä»–体系结构编译代ç æ¥å‘现。如果没有S/390系统
+或Blackfinå¼€å‘æ¿ï¼Œæ‚¨ä»ç„¶å¯ä»¥æ‰§è¡Œç¼–译æ¥éª¤ã€‚å¯ä»¥åœ¨ä»¥ä¸‹ä½ç½®æ‰¾åˆ°ä¸€ç»„用于x86系统的
+大型交å‰ç¼–译器：
+
+ http://www.kernel.org/pub/tools/crosstool/
+
+花一些时间安装和使用这些编译器将有助于é¿å…以åŽçš„尴尬。
+
+文档
+----
+
+æ–‡æ¡£é€šå¸¸æ¯”å†…æ ¸å¼€å‘规则更为例外。å³ä¾¿å¦‚æ¤ï¼Œè¶³å¤Ÿçš„文档将有助于简化将新代ç åˆå¹¶
+åˆ°å†…æ ¸ä¸çš„过程，使其他开å‘人员的生活更轻æ¾ï¼Œå¹¶å¯¹æ‚¨çš„用户有所帮助。在许多情况
+ä¸‹ï¼Œæ–‡ä»¶çš„æ·»åŠ å·²åŸºæœ¬ä¸Šæˆä¸ºå¼ºåˆ¶æ€§çš„。
+
+任何补ä¸çš„第一个文档是其关è”çš„å˜æ›´æ—¥å¿—。日志æ¡ç›®åº”该æè¿°æ£åœ¨è§£å†³çš„问题ã€è§£å†³
+方案的形å¼ã€å¤„ç†è¡¥ä¸çš„人员ã€å¯¹æ€§èƒ½çš„任何相关影å“，以åŠç†è§£è¡¥ä¸å¯èƒ½éœ€è¦çš„任何
+其他内容。确ä¿changelog说明了为什么补ä¸å€¼å¾—应用；大é‡å¼€å‘人员未能æ供这些信æ¯ã€‚
+
+ä»»ä½•æ·»åŠ æ–°ç”¨æˆ·ç©ºé—´ç•Œé¢çš„代ç （包括新的sysfs或/proc文件）都应该包å«è¯¥ç•Œé¢çš„
+文档，该文档使用户空间开å‘人员能够知é“他们在使用什么。请å‚阅
+Documentation/abi/readmeï¼Œäº†è§£å¦‚ä½•æ ¼å¼åŒ–æ¤æ–‡æ¡£ä»¥åŠéœ€è¦æ供哪些信æ¯ã€‚
+
+文件 :ref:`Documentation/admin-guide/kernel-parameters.rst <kernelparameters>`
+æè¿°äº†å†…æ ¸çš„æ‰€æœ‰å¼•å¯¼æ—¶é—´å‚æ•°ã€‚ä»»ä½•æ·»åŠ æ–°å‚æ•°çš„è¡¥ä¸éƒ½åº”该å‘è¯¥æ–‡ä»¶æ·»åŠ é€‚å½“çš„
+æ¡ç›®ã€‚
+
+任何新的é…置选项都必须附有帮助文本，帮助文本清楚地解释了这些选项以åŠç”¨æˆ·å¯èƒ½
+希望何时选择它们。
+
+许多å系统的内部APIä¿¡æ¯é€šè¿‡ä¸“é—¨æ ¼å¼åŒ–的注释进行记录；这些注释å¯ä»¥é€šè¿‡
+“kernel-docâ€è„šæœ¬ä»¥å¤šç§æ–¹å¼æå–å’Œæ ¼å¼åŒ–。如果您在具有kerneldoc注释的å系统ä¸
+å·¥ä½œï¼Œåˆ™åº”è¯¥ç»´æŠ¤å®ƒä»¬ï¼Œå¹¶æ ¹æ®éœ€è¦ä¸ºå¤–部å¯ç”¨çš„åŠŸèƒ½æ·»åŠ å®ƒä»¬ã€‚å³ä½¿åœ¨æ²¡æœ‰å¦‚æ¤è®°å½•
+的领域ä¸ï¼Œä¸ºå°†æ¥æ·»åŠ kerneldoc注释也没有å处；实际上，这对于刚开始开å‘å†…æ ¸çš„äºº
+æ¥è¯´æ˜¯ä¸€ä¸ªæœ‰ç”¨çš„æ´»åŠ¨ã€‚è¿™äº›æ³¨é‡Šçš„æ ¼å¼ä»¥åŠå¦‚何创建kerneldoc模æ¿çš„一些信æ¯å¯ä»¥åœ¨
+:ref:`Documentation/doc-guide/ <doc_guide>` 上找到。
+
+任何阅读大é‡çŽ°æœ‰å†…æ ¸ä»£ç 的人都会注æ„到，注释的缺失往往是最值得注æ„的。å†ä¸€æ¬¡ï¼Œ
+对新代ç 的期望比过去更高；åˆå¹¶æœªæ³¨é‡Šçš„代ç å°†æ›´åŠ å›°éš¾ã€‚è¿™å°±æ˜¯è¯´ï¼Œäººä»¬å‡ ä¹Žä¸å¸Œæœ›
+用è¯è¨€æ³¨é‡Šä»£ç 。代ç 本身应该是å¯è¯»çš„，注释解释了更微妙的方é¢ã€‚
+
+æŸäº›äº‹æƒ…应该总是被注释。使用内å˜å±éšœæ—¶ï¼Œåº”附上一行文å—，解释为什么需è¦è®¾ç½®å†…å˜
+å±éšœã€‚æ•°æ®ç»“æž„çš„é”定规则通常需è¦åœ¨æŸä¸ªåœ°æ–¹è§£é‡Šã€‚一般æ¥è¯´ï¼Œä¸»è¦æ•°æ®ç»“构需è¦å…¨é¢
+的文档。应该指出å•ç‹¬ä»£ç ä½ä¹‹é—´ä¸æ˜Žæ˜¾çš„ä¾èµ–性。任何å¯èƒ½è¯±ä½¿ä»£ç 看门人进行错误的
+“清ç†â€çš„事情都需è¦ä¸€ä¸ªæ³¨é‡Šæ¥è¯´æ˜Žä¸ºä»€ä¹ˆè¦è¿™æ ·åšã€‚ç‰ç‰ã€‚
+
+
+内部API更改
+-----------
+
+å†…æ ¸æ供给用户空间的二进制接å£ä¸èƒ½è¢«ç ´å，除éžåœ¨æœ€ä¸¥é‡çš„情况下。相åï¼Œå†…æ ¸çš„
+内部编程接å£æ˜¯é«˜åº¦æµåŠ¨çš„，当需è¦æ—¶å¯ä»¥æ›´æ”¹ã€‚å¦‚æžœä½ å‘现自己ä¸å¾—ä¸å¤„ç†ä¸€ä¸ªå†…æ ¸
+APIï¼Œæˆ–è€…ä»…ä»…å› ä¸ºå®ƒä¸æ»¡è¶³ä½ 的需求而ä¸ä½¿ç”¨ç‰¹å®šçš„功能，这å¯èƒ½æ˜¯API需è¦æ”¹å˜çš„一
+ä¸ªæ ‡å¿—ã€‚ä½œä¸ºå†…æ ¸å¼€å‘人员，您有æƒè¿›è¡Œæ¤ç±»æ›´æ”¹ã€‚
+
+当然, å¯ä»¥è¿›è¡ŒAPI更改，但它们必须是åˆç†çš„ã€‚å› æ¤ï¼Œä»»ä½•è¿›è¡Œå†…部API更改的补ä¸éƒ½
+应该附带一个关于更改内容和必è¦åŽŸå› çš„æ述。这ç§å˜åŒ–也应该分解æˆä¸€ä¸ªå•ç‹¬çš„è¡¥ä¸ï¼Œ
+而ä¸æ˜¯åŸ‹åœ¨ä¸€ä¸ªæ›´å¤§çš„è¡¥ä¸ä¸ã€‚
+
+å¦ä¸€ä¸ªè¦ç‚¹æ˜¯ï¼Œæ›´æ”¹å†…部APIçš„å¼€å‘人员通常è¦è´Ÿè´£ä¿®å¤å†…æ ¸æ ‘ä¸è¢«æ›´æ”¹ç ´å的任何代ç 。
+对于一个广泛使用的函数，这个èŒè´£å¯ä»¥å¯¼è‡´æˆç™¾ä¸Šåƒçš„å˜åŒ–，其ä¸è®¸å¤šå˜åŒ–å¯èƒ½ä¸Žå…¶ä»–
+å¼€å‘人员æ£åœ¨åšçš„工作相冲çªã€‚ä¸ç”¨è¯´ï¼Œè¿™å¯èƒ½æ˜¯ä¸€é¡¹å¤§å·¥ä½œï¼Œæ‰€ä»¥æœ€å¥½ç¡®ä¿ç†ç”±æ˜¯
+å¯é 的。请注æ„，coccinelle工具å¯ä»¥å¸®åŠ©è¿›è¡Œå¹¿æ³›çš„API更改。
+
+在进行ä¸å…¼å®¹çš„API更改时，应尽å¯èƒ½ç¡®ä¿ç¼–译器æ•èŽ·æœªæ›´æ–°çš„代ç 。这将帮助您确ä¿æ‰¾
+到该接å£çš„æ ‘å†…ç”¨å¤„ã€‚å®ƒè¿˜å°†è¦å‘Šå¼€å‘äººå‘˜æ ‘å¤–ä»£ç å˜åœ¨ä»–们需è¦å“应的更改。支æŒæ ‘外
+代ç ä¸æ˜¯å†…æ ¸å¼€å‘人员需è¦æ‹…心的事情，但是我们也ä¸å¿…ä½¿æ ‘å¤–å¼€å‘人员的生活有ä¸å¿…è¦
+的困难。
diff --git a/Documentation/translations/zh_CN/process/5.Posting.rst b/Documentation/translations/zh_CN/process/5.Posting.rst
new file mode 100644
index 0000000000000000000000000000000000000000..41aba21ff050ba2debfe9594b360c5044d0d9ad4
--- /dev/null
+++ b/Documentation/translations/zh_CN/process/5.Posting.rst
@@ -0,0 +1,240 @@
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: :ref:`Documentation/process/5.Posting.rst <development_posting>`
+:Translator: Alex Shi <alex.shi@linux.alibaba.com>
+
+.. _cn_development_posting:
+
+å‘é€è¡¥ä¸
+========
+
+迟早，当您的工作准备好æ交给社区进行审查，并最终包å«åˆ°ä¸»çº¿å†…æ ¸ä¸æ—¶ã€‚ä¸å‡ºæ‰€æ–™ï¼Œ
+å†…æ ¸å¼€å‘社区已ç»å‘展出一套用于å‘布补ä¸çš„约定和过程；éµå¾ªè¿™äº›çº¦å®šå’Œè¿‡ç¨‹å°†ä½¿
+å‚与其ä¸çš„æ¯ä¸ªäººçš„ç”Ÿæ´»æ›´åŠ è½»æ¾ã€‚本文件将试图åˆç†è¯¦ç»†åœ°æ¶µç›–这些期望；更多信æ¯
+也å¯åœ¨ä»¥ä¸‹æ–‡ä»¶ä¸æ‰¾åˆ°
+:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`,
+:ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>`
+和 :ref:`Documentation/translations/zh_CN/process/submit-checklist.rst <cn_submitchecklist>`.
+
+何时邮寄
+--------
+
+在补ä¸å®Œå…¨â€œå‡†å¤‡å¥½â€ä¹‹å‰ï¼Œæœ‰ä¸€ä¸ªä¸æ–的诱惑æ¥é¿å…å‘布补ä¸ã€‚对于简å•çš„è¡¥ä¸ï¼Œ
+è¿™ä¸æ˜¯é—®é¢˜ã€‚但是，如果æ£åœ¨å®Œæˆçš„工作很å¤æ‚，那么在工作完æˆä¹‹å‰ä»Žç¤¾åŒºèŽ·å¾—
+å馈就å¯ä»¥èŽ·å¾—å¾ˆå¤šå¥½å¤„ã€‚å› æ¤ï¼Œæ‚¨åº”该考虑å‘布æ£åœ¨è¿›è¡Œçš„工作，甚至使Gitæ ‘
+å¯ç”¨ï¼Œä»¥ä¾¿æ„Ÿå…´è¶£çš„å¼€å‘人员å¯ä»¥éšæ—¶èµ¶ä¸Šæ‚¨çš„工作。
+
+当å‘布还没有准备好包å«çš„代ç 时，最好在å‘布本身ä¸è¿™æ ·è¯´ã€‚还应æåŠä»»ä½•æœ‰å¾…完æˆ
+的主è¦å·¥ä½œå’Œä»»ä½•å·²çŸ¥é—®é¢˜ã€‚很少有人会看到那些被认为是åŠç”Ÿä¸ç†Ÿçš„è¡¥ä¸ï¼Œä½†æ˜¯é‚£äº›
+人会想到他们å¯ä»¥å¸®åŠ©ä½ 把工作推å‘æ£ç¡®çš„æ–¹å‘。
+
+创建补ä¸ä¹‹å‰
+------------
+
+在考虑将补ä¸å‘é€åˆ°å¼€å‘社区之å‰ï¼Œæœ‰è®¸å¤šäº‹æƒ…应该åšã€‚这些包括：
+
+ - å°½å¯èƒ½åœ°æµ‹è¯•ä»£ç ã€‚åˆ©ç”¨å†…æ ¸çš„è°ƒè¯•å·¥å…·ï¼Œç¡®ä¿å†…æ ¸ä½¿ç”¨æ‰€æœ‰åˆç†çš„é…置选项组åˆ
+ 进行构建，使用跨编译器为ä¸åŒçš„体系结构进行构建ç‰ã€‚
+
+ - ç¡®ä¿æ‚¨çš„代ç 符åˆå†…æ ¸ç¼–ç é£Žæ ¼æŒ‡å—。
+
+ - 您的更改是å¦å…·æœ‰æ€§èƒ½å½±å“ï¼Ÿå¦‚æžœæ˜¯è¿™æ ·ï¼Œæ‚¨åº”è¯¥è¿è¡ŒåŸºå‡†æµ‹è¯•æ¥æ˜¾ç¤ºæ‚¨çš„å˜æ›´çš„
+ å½±å“（或好处）；结果的摘è¦åº”该包å«åœ¨è¡¥ä¸ä¸ã€‚
+
+ - ç¡®ä¿æ‚¨æœ‰æƒå‘布代ç 。如果这项工作是为雇主完æˆçš„，雇主对这项工作具有所有æƒï¼Œ
+ 并且必须åŒæ„æ ¹æ®GPL对其进行放行。
+
+一般æ¥è¯´ï¼Œåœ¨å‘布代ç 之å‰è¿›è¡Œä¸€äº›é¢å¤–çš„æ€è€ƒï¼Œå‡ 乎总是能在çŸæ—¶é—´å†…得到回报。
+
+è¡¥ä¸å‡†å¤‡
+--------
+
+准备å‘布补ä¸å¯èƒ½æ˜¯ä¸€ä¸ªæƒŠäººçš„工作é‡ï¼Œä½†å†æ¬¡å°è¯•èŠ‚çœæ—¶é—´åœ¨è¿™é‡Œé€šå¸¸æ˜¯ä¸æ˜Žæ™ºçš„，
+å³ä½¿åœ¨çŸæœŸå†…。
+
+å¿…é¡»é’ˆå¯¹å†…æ ¸çš„ç‰¹å®šç‰ˆæœ¬å‡†å¤‡è¡¥ä¸ã€‚作为一般规则，补ä¸ç¨‹åºåº”该基于Linusçš„Gitæ ‘ä¸
+的当å‰ä¸»çº¿ã€‚当以主线为基础时，从一个众所周知的å‘布点开始——一个稳定的或RCçš„
+å‘布——而ä¸æ˜¯åœ¨ä¸€ä¸ªä¸»çº¿åˆ†æ”¯ä»»æ„点。
+
+但是，å¯èƒ½éœ€è¦é’ˆå¯¹-mmã€linux-next或åç³»ç»Ÿæ ‘ç”Ÿæˆç‰ˆæœ¬ï¼Œä»¥ä¾¿äºŽæ›´å¹¿æ³›çš„测试和审查。
+æ ¹æ®è¡¥ä¸çš„区域以åŠå…¶ä»–åœ°æ–¹çš„æƒ…å†µï¼Œé’ˆå¯¹è¿™äº›å…¶ä»–æ ‘å»ºç«‹è¡¥ä¸å¯èƒ½éœ€è¦å¤§é‡çš„工作æ¥
+解决冲çªå’Œå¤„ç†API更改。
+
+åªæœ‰æœ€ç®€å•çš„更改æ‰åº”æ ¼å¼åŒ–为å•ä¸ªè¡¥ä¸ï¼›å…¶ä»–所有更改都应作为一系列逻辑更改进行。
+分割补ä¸æ˜¯ä¸€é—¨è‰ºæœ¯ï¼›ä¸€äº›å¼€å‘人员花了很长时间æ¥å¼„清楚如何按照社区期望的方å¼æ¥
+åšã€‚然而，有一些ç»éªŒæ³•åˆ™å¯ä»¥å¤§å¤§å¸®åŠ©ï¼š
+
+ - 您å‘布的补ä¸ç¨‹åºç³»åˆ—å‡ ä¹Žè‚¯å®šä¸ä¼šæ˜¯å·¥ä½œç³»ç»Ÿä¸çš„一系列更改。相å，您所åšçš„
+ 更改需è¦åœ¨æœ€ç»ˆå½¢å¼ä¸åŠ 以考虑，然åŽä»¥æœ‰æ„义的方å¼è¿›è¡Œæ‹†åˆ†ã€‚å¼€å‘人员对离散的ã€
+ 自包å«çš„更改感兴趣，而ä¸æ˜¯æ‚¨èŽ·å–这些更改的路径。
+
+ - æ¯ä¸ªé€»è¾‘上独立的å˜æ›´éƒ½åº”è¯¥æ ¼å¼åŒ–为å•ç‹¬çš„è¡¥ä¸ã€‚这些更改å¯ä»¥æ˜¯å°çš„（“å‘æ¤
+ ç»“æž„æ·»åŠ å—段â€ï¼‰æˆ–å¤§çš„ï¼ˆä¾‹å¦‚ï¼Œæ·»åŠ ä¸€ä¸ªé‡è¦çš„新驱动程åºï¼‰ï¼Œä½†å®ƒä»¬åœ¨æ¦‚念上
+ 应该是å°çš„，并且å¯ä»¥æŽ¥å—一行æ述。æ¯ä¸ªè¡¥ä¸éƒ½åº”该åšä¸€ä¸ªç‰¹å®šçš„更改，å¯ä»¥å•ç‹¬
+ 检查并验è¯å®ƒæ‰€åšçš„事情。
+
+ - 作为é‡ç”³ä¸Šè¿°å‡†åˆ™çš„一ç§æ–¹æ³•ï¼šä¸è¦åœ¨åŒä¸€è¡¥ä¸ä¸æ··åˆä¸åŒç±»åž‹çš„更改。如果一个
+ è¡¥ä¸ä¿®å¤äº†ä¸€ä¸ªå…³é”®çš„安全æ¼æ´žï¼Œé‡æ–°æŽ’列了一些结构，并é‡æ–°æ ¼å¼åŒ–了代ç ，那么
+ 很有å¯èƒ½å®ƒä¼šè¢«å¿½ç•¥ï¼Œè€Œé‡è¦çš„ä¿®å¤å°†ä¸¢å¤±ã€‚
+
+ - æ¯ä¸ªè¡¥ä¸éƒ½åº”è¯¥äº§ç”Ÿä¸€ä¸ªå†…æ ¸ï¼Œå®ƒå¯ä»¥æ£ç¡®åœ°æž„建和è¿è¡Œï¼›å¦‚果补ä¸ç³»åˆ—在ä¸é—´è¢«
+ ä¸æ–，那么结果应该ä»ç„¶æ˜¯ä¸€ä¸ªå·¥ä½œçš„å†…æ ¸ã€‚è¡¥ä¸ç³»åˆ—的部分应用是使用
+ “git bisctâ€å·¥å…·æŸ¥æ‰¾å›žå½’的一个常è§åœºæ™¯ï¼›å¦‚果结果是一个æŸåçš„å†…æ ¸ï¼Œé‚£ä¹ˆå¯¹äºŽ
+ 那些从事追踪问题的高尚工作的开å‘人员和用户æ¥è¯´ï¼Œå°†ä½¿ä»–ä»¬çš„ç”Ÿæ´»æ›´åŠ è‰°éš¾ã€‚
+
+ - ä¸è¿‡ï¼Œä¸è¦è¿‡åˆ†ã€‚一ä½å¼€å‘人员曾ç»å°†ä¸€ç»„编辑内容作为500个å•ç‹¬çš„è¡¥ä¸å‘布到一个
+ 文件ä¸ï¼Œè¿™å¹¶æ²¡æœ‰ä½¿ä»–æˆä¸ºå†…æ ¸é‚®ä»¶åˆ—è¡¨ä¸æœ€å—欢迎的人。一个补ä¸å¯ä»¥ç›¸å½“大，
+ åªè¦å®ƒä»ç„¶åŒ…å«ä¸€ä¸ªå•ä¸€çš„逻辑å˜æ›´ã€‚
+
+ - 用一系列补ä¸æ·»åŠ 一个全新的基础设施是很有诱惑力的，但是在系列ä¸çš„最åŽä¸€ä¸ª
+ è¡¥ä¸å¯ç”¨æ•´ä¸ªè¡¥ä¸ä¹‹å‰ï¼Œè¯¥åŸºç¡€è®¾æ–½æ˜¯ä¸ä½¿ç”¨çš„。如果å¯èƒ½çš„è¯ï¼Œåº”该é¿å…è¿™ç§
+ è¯±æƒ‘ï¼›å¦‚æžœè¿™ä¸ªç³»åˆ—å¢žåŠ äº†å›žå½’ï¼Œé‚£ä¹ˆäºŒåˆ†æ³•å°†æŒ‡å‡ºæœ€åŽä¸€ä¸ªè¡¥ä¸æ˜¯å¯¼è‡´é—®é¢˜çš„
+ è¡¥ä¸ï¼Œå³ä½¿çœŸæ£çš„bug在其他地方。åªè¦æœ‰å¯èƒ½ï¼Œæ·»åŠ 新代ç çš„è¡¥ä¸ç¨‹åºåº”该立å³
+ 激活该代ç 。
+
+创建完美补ä¸ç³»åˆ—的工作å¯èƒ½æ˜¯ä¸€ä¸ªä»¤äººæ²®ä¸§çš„过程，在完æˆâ€œçœŸæ£çš„工作â€ä¹‹åŽéœ€è¦èŠ±è´¹
+大é‡çš„时间和æ€è€ƒã€‚但是，如果åšå¾—好，这是一段很好的时间。
+
+è¡¥ä¸æ ¼å¼å’Œæ›´æ”¹æ—¥å¿—
+------------------
+
+æ‰€ä»¥çŽ°åœ¨ä½ æœ‰äº†ä¸€ç³»åˆ—å®Œç¾Žçš„è¡¥ä¸å¯ä»¥å‘布，但是这项工作还没有完æˆã€‚æ¯ä¸ªè¡¥ä¸éƒ½
+需è¦è¢«æ ¼å¼åŒ–æˆä¸€æ¡æ¶ˆæ¯ï¼Œå®ƒå¯ä»¥å¿«é€Ÿè€Œæ¸…æ™°åœ°å°†å…¶ç›®çš„ä¼ è¾¾ç»™ä¸–ç•Œå…¶ä»–åœ°æ–¹ã€‚ä¸ºæ¤ï¼Œ
+æ¯ä¸ªè¡¥ä¸å°†ç”±ä»¥ä¸‹éƒ¨åˆ†ç»„æˆï¼š
+
+ - 命åè¡¥ä¸ä½œè€…çš„å¯é€‰â€œfromâ€è¡Œã€‚åªæœ‰å½“ä½ é€šè¿‡ç”µåé‚®ä»¶ä¼ é€’åˆ«äººçš„è¡¥ä¸æ—¶ï¼Œè¿™ä¸€è¡Œ
+ æ‰æ˜¯å¿…è¦çš„ï¼Œä½†æ˜¯å¦‚æžœæœ‰ç–‘é—®ï¼Œæ·»åŠ å®ƒä¸ä¼šæœ‰ä»»ä½•ä¼¤å®³ã€‚
+
+ - 一行æè¿°è¡¥ä¸çš„作用。对于没有其他上下文的读者æ¥è¯´ï¼Œæ¤æ¶ˆæ¯åº”该足够了解补ä¸
+ 的范围；这是将在“çŸæ ¼å¼â€å˜æ›´æ—¥å¿—ä¸æ˜¾ç¤ºçš„行。æ¤æ¶ˆæ¯é€šå¸¸é¦–先用相关的å系统
+ åç§°æ ¼å¼åŒ–，然åŽæ˜¯è¡¥ä¸çš„目的。例如：
+
+ ::
+
+ gpio: fix build on CONFIG_GPIO_SYSFS=n
+
+ - 一个空白行，åŽé¢æ˜¯è¡¥ä¸å†…容的详细æ述。这个æè¿°å¯ä»¥æ˜¯å¿…需的；它应该说明补ä¸
+ 的作用以åŠä¸ºä»€ä¹ˆå®ƒåº”è¯¥åº”ç”¨äºŽå†…æ ¸ã€‚
+
+ - ä¸€ä¸ªæˆ–å¤šä¸ªæ ‡è®°è¡Œï¼Œè‡³å°‘æœ‰ä¸€ä¸ªç”±è¡¥ä¸ä½œè€…的：signed-off-by ç¾å。ç¾å将在下é¢
+ 更详细地æ述。
+
+上é¢çš„项目一起构æˆè¡¥ä¸çš„å˜æ›´æ—¥å¿—。写一篇好的å˜æ›´æ—¥å¿—是一门至关é‡è¦ä½†å¸¸å¸¸è¢«
+忽视的艺术；值得花一点时间æ¥è®¨è®ºè¿™ä¸ªé—®é¢˜ã€‚å½“ä½ å†™ä¸€ä¸ªå˜æ›´æ—¥å¿—æ—¶ï¼Œä½ åº”è¯¥è®°ä½
+有很多ä¸åŒçš„äººä¼šè¯»ä½ çš„è¯ã€‚å…¶ä¸åŒ…括å系统维护人员和审查人员，他们需è¦å†³å®šæ˜¯å¦
+应该包括补ä¸ï¼Œåˆ†é”€å•†å’Œå…¶ä»–维护人员试图决定是å¦åº”该将补ä¸åå‘移æ¤åˆ°å…¶ä»–å†…æ ¸ï¼Œ
+bugæœå¯»äººå‘˜æƒ³çŸ¥é“è¡¥ä¸æ˜¯å¦è´Ÿè´£ä»–们æ£åœ¨è¿½æŸ¥çš„问题，想知é“å†…æ ¸å¦‚ä½•å˜åŒ–的用户。
+ç‰ç‰ã€‚一个好的å˜æ›´æ—¥å¿—以最直接和最简æ´çš„æ–¹å¼å‘æ‰€æœ‰è¿™äº›äººä¼ è¾¾æ‰€éœ€çš„ä¿¡æ¯ã€‚
+
+为æ¤ï¼Œæ€»ç»“行应该æè¿°å˜æ›´çš„å½±å“和动机，以åŠåœ¨ä¸€è¡Œçº¦æŸæ¡ä»¶ä¸‹å¯èƒ½å‘生的å˜åŒ–。
+然åŽï¼Œè¯¦ç»†çš„æè¿°å¯ä»¥è¯¦è¿°è¿™äº›ä¸»é¢˜ï¼Œå¹¶æ供任何需è¦çš„é™„åŠ ä¿¡æ¯ã€‚如果补ä¸ä¿®å¤äº†
+一个bug，请引用引入该bugçš„commit（如果å¯èƒ½ï¼Œè¯·åœ¨å¼•ç”¨commitsæ—¶åŒæ—¶æä¾›commit id
+å’Œæ ‡é¢˜ï¼‰ã€‚å¦‚æžœæŸä¸ªé—®é¢˜ä¸Žç‰¹å®šçš„日志或编译器输出相关è”，请包å«è¯¥è¾“出以帮助其他
+人æœç´¢åŒä¸€é—®é¢˜çš„解决方案。如果更改是为了支æŒä»¥åŽè¡¥ä¸ä¸çš„其他更改，那么就这么
+说。如果更改了内部API，请详细说明这些更改以åŠå…¶ä»–å¼€å‘人员应该如何å“应。一般
+æ¥è¯´ï¼Œä½ 越能把自己放在æ¯ä¸ªé˜…è¯»ä½ çš„changelog的人的ä½ç½®ä¸Šï¼Œchangelogï¼ˆå’Œå†…æ ¸
+作为一个整体）就越好。
+
+ä¸ç”¨è¯´ï¼Œå˜æ›´æ—¥å¿—应该是将å˜æ›´æ交到修订控制系统时使用的文本。接下æ¥æ˜¯ï¼š
+
+ - è¡¥ä¸æœ¬èº«ï¼Œé‡‡ç”¨ç»Ÿä¸€çš„（“-uâ€ï¼‰è¡¥ä¸æ ¼å¼ã€‚将“-pâ€é€‰é¡¹ç”¨äºŽdiff将使函数å与更改
+ 相关è”，从而使结果补ä¸æ›´å®¹æ˜“被其他人读å–。
+
+您应该é¿å…在补ä¸ä¸åŒ…括对ä¸ç›¸å…³æ–‡ä»¶ï¼ˆä¾‹å¦‚，由构建过程生æˆçš„文件或编辑器
+备份文件）的更改。文档目录ä¸çš„文件“dontdiffâ€åœ¨è¿™æ–¹é¢æœ‰å¸®åŠ©ï¼›ä½¿ç”¨â€œ-Xâ€é€‰é¡¹å°†
+å…¶ä¼ é€’ç»™diff。
+
+上é¢æåˆ°çš„æ ‡ç¾ç”¨äºŽæè¿°å„ç§å¼€å‘人员如何与这个补ä¸çš„å¼€å‘相关è”。
+:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
+文档ä¸å¯¹å®ƒä»¬è¿›è¡Œäº†è¯¦ç»†æ述；下é¢æ˜¯ä¸€ä¸ªç®€çŸçš„总结。æ¯ä¸€è¡Œçš„æ ¼å¼å¦‚下：
+
+::
+
+ tag: Full Name <email address> optional-other-stuff
+
+å¸¸ç”¨çš„æ ‡ç¾æœ‰ï¼š
+
+ - Signed-off-by: 这是一个开å‘人员的è¯æ˜Žï¼Œä»–或她有æƒæ交补ä¸ä»¥åŒ…å«åˆ°å†…æ ¸ä¸ã€‚
+ 这是开å‘æ¥æºè®¤è¯å议，其全文å¯åœ¨
+ :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
+ ä¸æ‰¾åˆ°ï¼Œå¦‚果没有适当的ç¾å—，则ä¸èƒ½åˆå¹¶åˆ°ä¸»çº¿ä¸ã€‚
+
+ - Co-developed-by: 声明补ä¸æ˜¯ç”±å¤šä¸ªå¼€å‘人员共åŒåˆ›å»ºçš„ï¼›å½“å‡ ä¸ªäººåœ¨ä¸€ä¸ªè¡¥ä¸ä¸Š
+ 工作时，它用于将属性赋予共åŒä½œè€…（除了 From: æ‰€èµ‹äºˆçš„ä½œè€…ä¹‹å¤–ï¼‰ã€‚å› ä¸º
+ Co-developed-by: 表示作者身份，所以æ¯ä¸ªå…±åŒå¼€å‘人, 必须紧跟在相关åˆä½œä½œè€…
+ çš„ç¾å之åŽã€‚具体内容和示例å¯ä»¥åœ¨ä»¥ä¸‹æ–‡ä»¶ä¸æ‰¾åˆ°
+ :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
+
+ - Acked-by: 表示å¦ä¸€ä¸ªå¼€å‘人员（通常是相关代ç 的维护人员）åŒæ„è¡¥ä¸é€‚åˆåŒ…å«
+ åœ¨å†…æ ¸ä¸ã€‚
+
+ - Tested-by: 声明指定的人已ç»æµ‹è¯•äº†è¡¥ä¸å¹¶å‘现它å¯ä»¥å·¥ä½œã€‚
+
+ - Reviewed-by: 指定的开å‘人员已ç»å®¡æŸ¥äº†è¡¥ä¸çš„æ£ç¡®æ€§ï¼›æœ‰å…³è¯¦ç»†ä¿¡æ¯ï¼Œè¯·å‚阅
+ :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
+
+ - Reported-by: 指定报告æ¤è¡¥ä¸ä¿®å¤çš„问题的用户；æ¤æ ‡è®°ç”¨äºŽæ供感谢。
+
+ - Cc：指定的人收到了补ä¸çš„副本，并有机会对æ¤å‘表评论。
+
+在补ä¸ä¸æ·»åŠ æ ‡ç¾æ—¶è¦å°å¿ƒï¼šåªæœ‰cc:æ‰é€‚åˆåœ¨æ²¡æœ‰æŒ‡å®šäººå‘˜æ˜Žç¡®è®¸å¯çš„æƒ…å†µä¸‹æ·»åŠ ã€‚
+
+å‘é€è¡¥ä¸
+--------
+
+在邮寄补ä¸ä¹‹å‰ï¼Œæ‚¨è¿˜éœ€è¦æ³¨æ„ä»¥ä¸‹å‡ ç‚¹ï¼š
+
+ - 您确定您的邮件å‘é€ç¨‹åºä¸ä¼šæŸåè¡¥ä¸å—？有å…费的空白更改或由邮件客户端
+ 执行的行包装的补ä¸ä¸ä¼šåœ¨å¦ä¸€ç«¯å¤åŽŸï¼Œå¹¶ä¸”通常ä¸ä¼šè¿›è¡Œä»»ä½•è¯¦ç»†æ£€æŸ¥ã€‚如果有
+ 任何疑问，把补ä¸å¯„ç»™ä½ è‡ªå·±ï¼Œè®©ä½ è‡ªå·±ç›¸ä¿¡å®ƒæ˜¯å®Œå¥½æ— æŸçš„。
+
+ :ref:`Documentation/translations/zh_CN/process/email-clients.rst <cn_email_clients>`
+ æ供了一些有用的æ示，å¯ä»¥è®©ç‰¹å®šçš„邮件客户机工作以å‘é€è¡¥ä¸ã€‚
+
+ - ä½ ç¡®å®šä½ çš„è¡¥ä¸æ²¡æœ‰æ„šè ¢çš„错误å—？您应该始终通过scripts/checkpatch.plè¿è¡Œ
+ è¡¥ä¸ç¨‹åºï¼Œå¹¶è§£å†³å®ƒæ出的投诉。请记ä½ï¼Œcheckpatch.pl虽然是大é‡æ€è€ƒå†…æ ¸
+ è¡¥ä¸åº”è¯¥æ˜¯ä»€ä¹ˆæ ·å的体现，但它并ä¸æ¯”您èªæ˜Žã€‚如果修å¤checkpatch.pl投诉会
+ 使代ç å˜å¾—更糟，请ä¸è¦è¿™æ ·åšã€‚
+
+è¡¥ä¸åº”始终以纯文本形å¼å‘é€ã€‚请ä¸è¦å°†å®ƒä»¬ä½œä¸ºé™„件å‘é€ï¼›è¿™ä½¿å¾—审阅者在ç”å¤ä¸æ›´éš¾
+引用补ä¸çš„部分。相å，åªéœ€å°†è¡¥ä¸ç›´æŽ¥æ”¾åˆ°æ‚¨çš„消æ¯ä¸ã€‚
+
+邮寄补ä¸æ—¶ï¼Œé‡è¦çš„是将副本å‘é€ç»™ä»»ä½•å¯èƒ½æ„Ÿå…´è¶£çš„人。与其他一些项目ä¸åŒï¼Œå†…æ ¸
+鼓励人们错误地å‘é€è¿‡å¤šçš„副本；ä¸è¦å‡å®šç›¸å…³äººå‘˜ä¼šçœ‹åˆ°æ‚¨åœ¨é‚®ä»¶åˆ—表ä¸çš„å‘布。
+尤其是，副本应å‘é€è‡³ï¼š
+
+ - å—å½±å“å系统的维护人员。如å‰æ‰€è¿°ï¼Œç»´æŠ¤äººå‘˜æ–‡ä»¶æ˜¯æŸ¥æ‰¾è¿™äº›äººå‘˜çš„第一个地方。
+
+ - 其他在åŒä¸€é¢†åŸŸå·¥ä½œçš„å¼€å‘人员，尤其是那些现在å¯èƒ½åœ¨é‚£é‡Œå·¥ä½œçš„å¼€å‘人员。使用
+ git查看还有è°ä¿®æ”¹äº†æ‚¨æ£åœ¨å¤„ç†çš„文件，这很有帮助。
+
+ - 如果您对错误报告或功能请求åšå‡ºå“应，也å¯ä»¥æŠ„é€åŽŸå§‹å‘é€äººã€‚
+
+ - 将副本å‘é€åˆ°ç›¸å…³é‚®ä»¶åˆ—表，或者，如果没有其他应用，则å‘é€åˆ°Linuxå†…æ ¸åˆ—è¡¨ã€‚
+
+ - 如果您æ£åœ¨ä¿®å¤ä¸€ä¸ªbug，请考虑该修å¤æ˜¯å¦åº”è¿›å…¥ä¸‹ä¸€ä¸ªç¨³å®šæ›´æ–°ã€‚å¦‚æžœæ˜¯è¿™æ ·ï¼Œ
+ stable@vger.kernel.org 应该得到补ä¸çš„副本。å¦å¤–，在补ä¸æœ¬èº«çš„æ ‡ç¾ä¸æ·»åŠ
+ 一个“cc:stable@vger.kernel.orgâ€ï¼›è¿™å°†ä½¿ç¨³å®šå›¢é˜Ÿåœ¨ä¿®å¤è¿›å…¥ä¸»çº¿æ—¶æ”¶åˆ°é€šçŸ¥ã€‚
+
+当为一个补ä¸é€‰æ‹©æŽ¥æ”¶è€…时，最好知é“ä½ è®¤ä¸ºè°æœ€ç»ˆä¼šæŽ¥å—这个补ä¸å¹¶å°†å…¶åˆå¹¶ã€‚虽然
+å¯ä»¥å°†è¡¥ä¸ç›´æŽ¥å‘é€ç»™LinusTorvalds并让他åˆå¹¶ï¼Œä½†é€šå¸¸æƒ…况下ä¸ä¼šè¿™æ ·åšã€‚Linus
+很忙，并且有åç³»ç»Ÿç»´æŠ¤äººå‘˜è´Ÿè´£ç›‘è§†å†…æ ¸çš„ç‰¹å®šéƒ¨åˆ†ã€‚é€šå¸¸æ‚¨ä¼šå¸Œæœ›ç»´æŠ¤äººå‘˜åˆå¹¶æ‚¨
+çš„è¡¥ä¸ã€‚如果没有明显的维护人员，Andrew Morton通常是最åŽçš„è¡¥ä¸ç›®æ ‡ã€‚
+
+è¡¥ä¸éœ€è¦å¥½çš„主题行。补ä¸ç¨‹åºè¡Œçš„è§„èŒƒæ ¼å¼å¦‚下：
+
+::
+
+ [PATCH nn/mm] subsys: one-line description of the patch
+
+å…¶ä¸â€œnnâ€æ˜¯è¡¥ä¸çš„åºå·ï¼Œâ€œmmâ€æ˜¯ç³»åˆ—ä¸è¡¥ä¸çš„总数，“subsysâ€æ˜¯å—å½±å“å系统的å称。
+显然，一个å•ç‹¬çš„è¡¥ä¸å¯ä»¥çœç•¥nn/mm。
+
+如果您有一系列é‡è¦çš„è¡¥ä¸ï¼Œé‚£ä¹ˆé€šå¸¸å°†ä»‹ç»æ€§æ述作为零部分å‘é€ã€‚ä¸è¿‡ï¼Œè¿™ç§çº¦å®š
+并没有得到普ééµå¾ªï¼›å¦‚果您使用它，请记ä½ç®€ä»‹ä¸çš„ä¿¡æ¯ä¸ä¼šä½¿å®ƒè¿›å…¥å†…æ ¸å˜æ›´æ—¥å¿—。
+å› æ¤ï¼Œè¯·ç¡®ä¿è¡¥ä¸æœ¬èº«å…·æœ‰å®Œæ•´çš„å˜æ›´æ—¥å¿—ä¿¡æ¯ã€‚
+
+一般æ¥è¯´ï¼Œå¤šéƒ¨åˆ†è¡¥ä¸çš„第二部分和åŽç»éƒ¨åˆ†åº”作为对第一部分的回å¤å‘é€ï¼Œä»¥ä¾¿å®ƒä»¬
+在接收端都连接在一起。åƒgitå’Œcoiltè¿™æ ·çš„å·¥å…·æœ‰å‘½ä»¤ï¼Œå¯ä»¥é€šè¿‡é€‚当的线程å‘é€
+一组补ä¸ã€‚但是，如果您有一个长系列，并且æ£åœ¨ä½¿ç”¨git，请远离–chain reply-to
+选项，以é¿å…创建异常深的嵌套。
diff --git a/Documentation/translations/zh_CN/process/6.Followthrough.rst b/Documentation/translations/zh_CN/process/6.Followthrough.rst
new file mode 100644
index 0000000000000000000000000000000000000000..f509e077e1cb08ebd549632499dc16c4a752c9e1
--- /dev/null
+++ b/Documentation/translations/zh_CN/process/6.Followthrough.rst
@@ -0,0 +1,145 @@
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: :ref:`Documentation/process/6.Followthrough.rst <development_followthrough>`
+:Translator: Alex Shi <alex.shi@linux.alibaba.com>
+
+.. _cn_development_followthrough:
+
+è·Ÿè¿›
+====
+
+在这一点上，您已ç»éµå¾ªäº†åˆ°ç›®å‰ä¸ºæ¢ç»™å‡ºçš„指导方针，并且，éšç€æ‚¨è‡ªå·±çš„工程技能
+çš„å¢žåŠ ï¼Œå·²ç»å‘布了一系列完美的补ä¸ã€‚å³ä½¿æ˜¯ç»éªŒä¸°å¯Œçš„å†…æ ¸å¼€å‘人员也能犯的最大
+错误之一是，认为他们的工作现在已ç»å®Œæˆäº†ã€‚事实上，å‘布补ä¸æ„味ç€è¿›å…¥æµç¨‹çš„下
+一个阶段，å¯èƒ½è¿˜éœ€è¦åšå¾ˆå¤šå·¥ä½œã€‚
+
+一个补ä¸åœ¨ç¬¬ä¸€æ¬¡å‘布时就éžå¸¸å‡ºè‰²ï¼Œæ²¡æœ‰æ”¹è¿›çš„余地,这是很罕è§çš„ã€‚å†…æ ¸å¼€å‘æµç¨‹
+è®¤è¯†åˆ°è¿™ä¸€äº‹å®žï¼Œå› æ¤ï¼Œå®ƒéžå¸¸æ³¨é‡å¯¹å·²å‘布代ç 的改进。作为代ç 的作者，您应该与
+å†…æ ¸ç¤¾åŒºåˆä½œï¼Œä»¥ç¡®ä¿æ‚¨çš„代ç 符åˆå†…æ ¸çš„è´¨é‡æ ‡å‡†ã€‚如果ä¸å‚与这个过程，很å¯èƒ½ä¼š
+阻æ¢å°†è¡¥ä¸åŒ…å«åˆ°ä¸»çº¿ä¸ã€‚
+
+与审阅者åˆä½œ
+------------
+
+任何æ„义上的补ä¸éƒ½ä¼šå¯¼è‡´å…¶ä»–å¼€å‘人员在审查代ç æ—¶å‘表大é‡è¯„论。对于许多开å‘
+人员æ¥è¯´ï¼Œä¸Žå®¡æŸ¥äººå‘˜åˆä½œå¯èƒ½æ˜¯å†…æ ¸å¼€å‘过程ä¸æœ€ä»¤äººç”Ÿç•çš„部分。但是，如果ä½
+è®°ä½ä¸€äº›äº‹æƒ…，生活会å˜å¾—容易得多：
+
+ - å¦‚æžœä½ å·²ç»å¾ˆå¥½åœ°è§£é‡Šäº†ä½ çš„è¡¥ä¸ï¼Œè¯„论人员会ç†è§£å®ƒçš„价值，以åŠä¸ºä»€ä¹ˆä½ 会
+ 费尽心æ€åŽ»å†™å®ƒã€‚但是这个并ä¸èƒ½é˜»æ¢ä»–们æ出一个基本的问题：五年或åå¹´åŽ
+ 用这个代ç ç»´æŠ¤ä¸€ä¸ªå†…æ ¸ä¼šæ˜¯ä»€ä¹ˆæ„Ÿè§‰ï¼Ÿä½ å¯èƒ½è¢«è¦æ±‚åšå‡ºçš„许多改å˜â€”—从编ç é£Žæ ¼
+ 的调整到大é‡çš„é‡å†™â€”—都æ¥è‡ªäºŽå¯¹Linuxçš„ç†è§£ï¼Œå³ä»ŽçŽ°åœ¨èµ·åå¹´åŽï¼ŒLinuxä»å°†åœ¨
+ å¼€å‘ä¸ã€‚
+
+ - 代ç 审查是一项艰苦的工作，这是一项相对åƒåŠ›ä¸è®¨å¥½çš„工作；人们记得è°ç¼–写了
+ å†…æ ¸ä»£ç ，但对于那些审查它的人æ¥è¯´ï¼Œå‡ 乎没有什么æŒä¹…çš„åå£°ã€‚å› æ¤ï¼Œè¯„论
+ 人员å¯èƒ½ä¼šå˜å¾—æš´èºï¼Œå°¤å…¶æ˜¯å½“他们看到åŒæ ·çš„错误被一éåˆä¸€é地犯下时。如果
+ ä½ å¾—åˆ°äº†ä¸€ä¸ªçœ‹èµ·æ¥æ„¤æ€’ã€ä¾®è¾±æˆ–å®Œå…¨å†’çŠ¯ä½ çš„è¯„è®ºï¼ŒæŠµåˆ¶ä»¥åŒæ ·æ–¹å¼å›žåº”的冲动。
+ 代ç 审查是关于代ç 的，而ä¸æ˜¯å…³äºŽäººçš„，代ç 审查人员ä¸ä¼šäº²è‡ªæ”»å‡»æ‚¨ã€‚
+
+ - åŒæ ·ï¼Œä»£ç 审查人员也ä¸æƒ³ä»¥ç‰ºç‰²ä½ 雇主的利益为代价æ¥å®£ä¼ 他们雇主的议程。
+ å†…æ ¸å¼€å‘人员通常希望今åŽå‡ å¹´èƒ½åœ¨å†…æ ¸ä¸Šå·¥ä½œï¼Œä½†ä»–ä»¬æ˜Žç™½ä»–ä»¬çš„é›‡ä¸»å¯èƒ½ä¼šæ”¹
+ å˜ã€‚ä»–ä»¬çœŸçš„ï¼Œå‡ ä¹Žæ¯«æ— ä¾‹å¤–åœ°ï¼Œè‡´åŠ›äºŽåˆ›é€ ä»–ä»¬æ‰€èƒ½åšåˆ°çš„æœ€å¥½çš„å†…æ ¸ï¼›ä»–ä»¬å¹¶
+ æ²¡æœ‰è¯•å›¾ç»™é›‡ä¸»çš„ç«žäº‰å¯¹æ‰‹é€ æˆä¸é€‚。
+
+æ‰€æœ‰è¿™äº›å½’æ ¹ç»“åº•éƒ½æ˜¯ï¼Œå½“å®¡é˜…è€…å‘您å‘é€è¯„论时，您需è¦æ³¨æ„他们æ£åœ¨è¿›è¡Œçš„技术
+观察。ä¸è¦è®©ä»–们的表达方å¼æˆ–ä½ è‡ªå·±çš„éª„å‚²é˜»æ¢è¿™ç§äº‹æƒ…çš„å‘ç”Ÿã€‚å½“ä½ åœ¨ä¸€ä¸ªè¡¥ä¸
+上得到评论时，花点时间去ç†è§£è¯„论人想说什么。如果å¯èƒ½çš„è¯ï¼Œè¯·ä¿®å¤å®¡é˜…者è¦æ±‚
+您修å¤çš„内容。然åŽå›žå¤å®¡ç¨¿äººï¼šè°¢è°¢ä»–们，并æè¿°ä½ å°†å¦‚ä½•å›žç”他们的问题。
+
+请注æ„，您ä¸å¿…åŒæ„审阅者建议的æ¯ä¸ªæ›´æ”¹ã€‚如果您认为审阅者误解了您的代ç ，请
+解释到底å‘生了什么。如果您对建议的更改有技术上的异议，请æ述它并è¯æ˜Žæ‚¨å¯¹è¯¥
+问题的解决方案是æ£ç¡®çš„ã€‚å¦‚æžœä½ çš„è§£é‡Šæœ‰é“ç†ï¼Œå®¡ç¨¿äººä¼šæŽ¥å—的。ä¸è¿‡ï¼Œå¦‚æžœä½ çš„
+解释ä¸èƒ½è¯æ˜Žæ˜¯æœ‰è¯´æœåŠ›çš„，尤其是当其他人开始åŒæ„审稿人的观点时，请花些时间
+é‡æ–°è€ƒè™‘ä¸€ä¸‹ã€‚ä½ å¾ˆå®¹æ˜“å¯¹è‡ªå·±è§£å†³é—®é¢˜çš„æ–¹æ³•è§†è€Œä¸è§ï¼Œä»¥è‡³äºŽä½ 没有æ„识到æŸä¸ª
+é—®é¢˜æ ¹æœ¬æ˜¯é”™è¯¯çš„ï¼Œæˆ–è€…ä½ ç”šè‡³æ²¡æœ‰è§£å†³æ£ç¡®çš„问题。
+
+Andrew Morton建议，æ¯ä¸€æ¡ä¸ä¼šå¯¼è‡´ä»£ç 更改的评论都应该导致é¢å¤–的代ç 注释；
+è¿™å¯ä»¥å¸®åŠ©æœªæ¥çš„评论人员é¿å…出现第一次出现的问题。
+
+一个致命的错误是忽视评论，希望它们会消失。他们ä¸ä¼šèµ°çš„。如果您在没有对之å‰
+收到的注释åšå‡ºå“应的情况下é‡æ–°å‘布代ç ，那么很å¯èƒ½ä¼šå‘现补ä¸æ¯«æ— 用处。
+
+说到é‡æ–°å‘布代ç ：请记ä½ï¼Œå®¡é˜…者ä¸ä¼šè®°ä½æ‚¨ä¸Šæ¬¡å‘布的代ç çš„æ‰€æœ‰ç»†èŠ‚ã€‚å› æ¤ï¼Œ
+æ醒审查人员以å‰æ出的问题以åŠæ‚¨å¦‚何处ç†è¿™äº›é—®é¢˜æ€»æ˜¯ä¸€ä¸ªå¥½ä¸»æ„；补ä¸å˜æ›´
+日志是æä¾›æ¤ç±»ä¿¡æ¯çš„好地方。审阅者ä¸å¿…æœç´¢åˆ—表档案æ¥ç†Ÿæ‚‰ä¸Šæ¬¡æ‰€è¯´çš„内容；
+如果您帮助他们开始è¿è¡Œï¼Œå½“他们é‡æ–°è®¿é—®æ‚¨çš„代ç 时，他们的心情会更好。
+
+å¦‚æžœä½ å·²ç»è¯•ç€åšæ£ç¡®çš„事情，但事情ä»ç„¶æ²¡æœ‰è¿›å±•å‘¢ï¼Ÿå¤§å¤šæ•°æŠ€æœ¯ä¸Šçš„分æ§éƒ½å¯ä»¥
+通过讨论æ¥è§£å†³ï¼Œä½†æœ‰æ—¶äººä»¬åªéœ€è¦åšå‡ºå†³å®šã€‚å¦‚æžœä½ çœŸçš„è®¤ä¸ºè¿™ä¸ªå†³å®šå¯¹ä½ ä¸åˆ©ï¼Œ
+ä½ å¯ä»¥è¯•ç€å‘更高的æƒåŠ›ä¸Šè¯‰ã€‚åœ¨è¿™ç¯‡æ–‡ç« ä¸ï¼Œæ›´é«˜çš„æƒåŠ›å€¾å‘于Andrew Morton。
+Andrewåœ¨å†…æ ¸å¼€å‘社区ä¸å—i很大的尊é‡ï¼›ä»–ç»å¸¸ä¸ºä¼¼ä¹Žè¢«ç»æœ›åœ°é˜»å¡žäº‹æƒ…清障。
+尽管如æ¤ï¼Œå¯¹Andrew的呼åä¸åº”轻而易举，也ä¸åº”在所有其他替代方案都被探索之å‰
+使用。当然，记ä½ï¼Œä»–也å¯èƒ½ä¸åŒæ„ä½ çš„æ„è§ã€‚
+
+接下æ¥ä¼šå‘生什么
+----------------
+
+如果一个补ä¸è¢«è®¤ä¸ºæ˜¯æ·»åŠ åˆ°å†…æ ¸ä¸çš„一件好事，并且一旦大多数审查问题得到解决，
+下一æ¥é€šå¸¸æ˜¯è¿›å…¥åç³»ç»Ÿç»´æŠ¤äººå‘˜çš„æ ‘ä¸ã€‚工作方å¼å› å系统而异；æ¯ä¸ªç»´æŠ¤äººå‘˜éƒ½
+有自己的工作方å¼ã€‚特别是，å¯èƒ½æœ‰ä¸æ¢ä¸€æ£µæ ‘â€”â€”ä¸€æ£µæ ‘ï¼Œä¹Ÿè®¸ï¼Œä¸“é—¨ç”¨äºŽè®¡åˆ’ä¸‹ä¸€
+个åˆå¹¶çª—å£çš„è¡¥ä¸ï¼Œå¦ä¸€æ£µæ ‘用于长期工作。
+
+对于应用于没有明显åç³»ç»Ÿæ ‘ï¼ˆä¾‹å¦‚å†…å˜ç®¡ç†ä¿®è¡¥ç¨‹åºï¼‰çš„区域的修补程åºï¼Œé»˜è®¤æ ‘
+通常以-mm结尾。影å“多个å系统的补ä¸ä¹Ÿå¯ä»¥æœ€ç»ˆé€šè¿‡-mmæ ‘ã€‚
+
+包å«åœ¨åç³»ç»Ÿæ ‘ä¸å¯ä»¥æ高补ä¸çš„å¯è§æ€§ã€‚çŽ°åœ¨ï¼Œä½¿ç”¨è¯¥æ ‘çš„å…¶ä»–å¼€å‘人员将默认获
+å¾—è¡¥ä¸ã€‚åç³»ç»Ÿæ ‘é€šå¸¸ä¹Ÿä¸ºLinuxæ供支æŒï¼Œä½¿å…¶å†…容对整个开å‘社区å¯è§ã€‚在这一点
+上，您很å¯èƒ½ä¼šä»Žä¸€ç»„新的审阅者那里得到更多的评论；这些评论需è¦åƒä¸Šä¸€è½®é‚£æ ·
+得到回ç”。
+
+在这一点上也会å‘生什么，这å–å†³äºŽä½ çš„è¡¥ä¸çš„性质，是与其他人æ£åœ¨åšçš„工作å‘生
+冲çªã€‚在最å的情况下，严é‡çš„è¡¥ä¸å†²çªå¯èƒ½ä¼šå¯¼è‡´ä¸€äº›å·¥ä½œè¢«æ置，以便剩余的补ä¸
+å¯ä»¥æˆå½¢å¹¶åˆå¹¶ã€‚å¦ä¸€äº›æ—¶å€™ï¼Œå†²çªè§£å†³å°†æ¶‰åŠåˆ°ä¸Žå…¶ä»–å¼€å‘人员åˆä½œï¼Œå¯èƒ½è¿˜ä¼š
+åœ¨æ ‘ä¹‹é—´ç§»åŠ¨ä¸€äº›è¡¥ä¸ï¼Œä»¥ç¡®ä¿æ‰€æœ‰çš„应用都是干净的。这项工作å¯èƒ½æ˜¯ä¸€ä»¶ç—›è‹¦çš„
+事情，但è¦è®¡ç®—您的ç¦ç¥‰ï¼šåœ¨Linuxä¸‹ä¸€æ£µæ ‘å‡ºçŽ°ä¹‹å‰ï¼Œè¿™äº›å†²çªé€šå¸¸åªåœ¨åˆå¹¶çª—å£
+ä¸å‡ºçŽ°ï¼Œå¿…须迅速解决。现在å¯ä»¥åœ¨åˆå¹¶çª—å£æ‰“开之å‰ï¼Œåœ¨ç©ºé—²æ—¶è§£å†³è¿™äº›é—®é¢˜ã€‚
+
+有æœä¸€æ—¥ï¼Œå¦‚果一切顺利，您将登录并看到您的补ä¸å·²ç»åˆå¹¶åˆ°ä¸»çº¿å†…æ ¸ä¸ã€‚ç¥è´ºä½ ï¼
+然而，一旦庆ç¥æ´»åŠ¨å®Œæˆï¼ˆå¹¶ä¸”您已ç»å°†è‡ªå·±æ·»åŠ 到维护人员文件ä¸ï¼‰ï¼Œå°±å€¼å¾—è®°ä½
+一个é‡è¦çš„å°äº‹å®žï¼šå·¥ä½œä»ç„¶æ²¡æœ‰å®Œæˆã€‚并入主线带æ¥äº†è‡ªèº«çš„挑战。
+
+首先，补ä¸çš„å¯è§æ€§å†æ¬¡æ高。å¯èƒ½ä¼šæœ‰æ–°ä¸€è½®çš„å¼€å‘者评论，他们以å‰ä¸çŸ¥é“è¿™
+个补ä¸ã€‚忽略它们å¯èƒ½å¾ˆæœ‰è¯±æƒ‘åŠ›ï¼Œå› ä¸ºæ‚¨çš„ä»£ç ä¸å†å˜åœ¨ä»»ä½•è¢«åˆå¹¶çš„问题。但是，
+è¦æŠµåˆ¶è¿™ç§è¯±æƒ‘，您ä»ç„¶éœ€è¦å¯¹æœ‰é—®é¢˜æˆ–建议的开å‘人员作出å“应。
+
+ä¸è¿‡ï¼Œæ›´é‡è¦çš„是：将代ç 包å«åœ¨ä¸»çº¿ä¸ä¼šå°†ä»£ç 交给更大的一组测试人员。å³ä½¿æ‚¨
+为尚未æ供的硬件æ供了驱动程åºï¼Œæ‚¨ä¹Ÿä¼šæƒŠè®¶äºŽæœ‰å¤šå°‘人会将您的代ç æž„å»ºåˆ°å†…æ ¸
+ä¸ã€‚当然，如果有测试人员，也会有错误报告。
+
+æœ€ç³Ÿç³•çš„é”™è¯¯æŠ¥å‘Šæ˜¯å›žå½’ã€‚å¦‚æžœä½ çš„è¡¥ä¸å¯¼è‡´å›žå½’ï¼Œä½ ä¼šå‘现很多ä¸èˆ’æœçš„眼ç›ç›¯ç€
+ä½ ï¼›å›žå½’éœ€è¦å°½å¿«ä¿®å¤ã€‚如果您ä¸æ„¿æ„æˆ–æ— æ³•ä¿®å¤å›žå½’（其他人都ä¸ä¼šä¸ºæ‚¨ä¿®å¤ï¼‰ï¼Œ
+那么在稳定期内，您的补ä¸å‡ 乎肯定会被移除。除了å¦å®šæ‚¨ä¸ºä½¿è¡¥ä¸è¿›å…¥ä¸»çº¿æ‰€åšçš„
+所有工作之外，如果由于未能修å¤å›žå½’而å–消补ä¸ï¼Œå¾ˆå¯èƒ½ä¼šä½¿å°†æ¥çš„工作更难åˆå¹¶ã€‚
+
+在处ç†å®Œä»»ä½•å›žå½’之åŽï¼Œå¯èƒ½è¿˜æœ‰å…¶ä»–普通的bug需è¦å¤„ç†ã€‚稳定期是修å¤è¿™äº›é”™è¯¯å¹¶
+ç¡®ä¿ä»£ç åœ¨ä¸»çº¿å†…æ ¸ç‰ˆæœ¬ä¸çš„首次å‘布尽å¯èƒ½å¯é 的最好机会。所以，请回ç”错误
+报告，并尽å¯èƒ½è§£å†³é—®é¢˜ã€‚这就是稳定期的目的；一旦解决了旧补ä¸çš„任何问题，就
+å¯ä»¥å¼€å§‹åˆ›å»ºé…·çš„æ–°è¡¥ä¸ã€‚
+
+别忘了，还有其他里程碑也å¯èƒ½ä¼šåˆ›å»ºbug报告：下一个主线稳定版本，当著åçš„å‘è¡Œ
+商选择包å«è¡¥ä¸çš„å†…æ ¸ç‰ˆæœ¬æ—¶ï¼Œç‰ç‰ã€‚继ç»å“应这些报告是您工作的基本骄傲。但是，
+如果这ä¸æ˜¯è¶³å¤Ÿçš„动机，那么也值得考虑的是，开å‘社区会记ä½é‚£äº›åœ¨åˆå¹¶åŽå¯¹ä»£ç
+失去兴趣的开å‘äººå‘˜ã€‚ä¸‹ä¸€æ¬¡ä½ å‘布补ä¸æ—¶ï¼Œä»–ä»¬ä¼šä»¥ä½ ä»¥åŽä¸ä¼šåœ¨èº«è¾¹ç»´æŠ¤å®ƒä¸ºå‡
+设æ¥è¯„估它。
+
+其他å¯èƒ½å‘生的事情
+------------------
+
+æœ‰ä¸€å¤©ï¼Œä½ å¯ä»¥æ‰“å¼€ä½ çš„é‚®ä»¶å®¢æˆ·ç«¯ï¼Œçœ‹åˆ°æœ‰äººç»™ä½ å¯„äº†ä¸€ä¸ªä»£ç è¡¥ä¸ã€‚毕竟，这是
+让您的代ç 公开å˜åœ¨çš„好处之一。如果您åŒæ„这个补ä¸ï¼Œæ‚¨å¯ä»¥å°†å®ƒè½¬å‘ç»™å系统
+维护人员（确ä¿åŒ…å«ä¸€ä¸ªæ£ç¡®çš„From:è¡Œï¼Œè¿™æ ·å±žæ€§æ˜¯æ£ç¡®çš„ï¼Œå¹¶æ·»åŠ ä¸€ä¸ªæ‚¨è‡ªå·±
+çš„ç¾å‡†ï¼‰ï¼Œæˆ–者回å¤ä¸€ä¸ªAcked-by，让原始å‘é€è€…å‘上å‘é€å®ƒã€‚
+
+如果您ä¸åŒæ„è¡¥ä¸ï¼Œè¯·å‘é€ä¸€ä¸ªç¤¼è²Œçš„回å¤ï¼Œè§£é‡ŠåŽŸå› 。如果å¯èƒ½çš„è¯ï¼Œå‘Šè¯‰ä½œè€…需è¦
+åšå“ªäº›æ›´æ”¹æ‰èƒ½è®©æ‚¨æŽ¥å—è¡¥ä¸ã€‚对于代ç 的编写者和维护者所å对的åˆå¹¶è¡¥ä¸ï¼Œå˜åœ¨ç€
+一定的阻力，但仅æ¤è€Œå·²ã€‚å¦‚æžœä½ è¢«è®¤ä¸ºä¸å¿…è¦çš„阻ç¢äº†å¥½çš„工作，那么这些补ä¸æœ€
+终会ç»è¿‡ä½ 身边并进入主线。在Linuxå†…æ ¸ä¸ï¼Œæ²¡æœ‰äººå¯¹ä»»ä½•ä»£ç 拥有ç»å¯¹çš„å¦å†³æƒã€‚
+除了Linus。
+
+在éžå¸¸ç½•è§çš„情况下，您å¯èƒ½ä¼šçœ‹åˆ°å®Œå…¨ä¸åŒçš„东西：å¦ä¸€ä¸ªå¼€å‘人员å‘布了针对您
+的问题的ä¸åŒè§£å†³æ–¹æ¡ˆã€‚在这一点上，两个补ä¸ä¸çš„一个å¯èƒ½ä¸ä¼šåˆå¹¶ï¼Œâ€œæˆ‘的在这里
+是第一个â€ä¸è¢«è®¤ä¸ºæ˜¯ä¸€ä¸ªä»¤äººä¿¡æœçš„技术论æ®ã€‚如果有人的补ä¸å–ä»£äº†ä½ çš„è¡¥ä¸è€Œè¿›
+入了主线，那么åªæœ‰ä¸€ç§æ–¹æ³•å¯ä»¥å›žåº”ä½ ï¼šé«˜å…´ä½ çš„é—®é¢˜å¾—åˆ°è§£å†³ï¼Œç»§ç»ä½ 的工作。
+以这ç§æ–¹å¼æŠŠä¸€ä¸ªäººçš„工作推到一边å¯èƒ½ä¼šä¼¤å®³å’Œæ°”é¦ï¼Œä½†æ˜¯åœ¨ä»–们忘记了è°çš„è¡¥ä¸
+真æ£è¢«åˆå¹¶å¾ˆä¹…之åŽï¼Œç¤¾åŒºä¼šè®°ä½ä½ çš„å应。
diff --git a/Documentation/translations/zh_CN/process/7.AdvancedTopics.rst b/Documentation/translations/zh_CN/process/7.AdvancedTopics.rst
new file mode 100644
index 0000000000000000000000000000000000000000..956815edbd18a526b5eb74ff97a8d8c0cb1dc374
--- /dev/null
+++ b/Documentation/translations/zh_CN/process/7.AdvancedTopics.rst
@@ -0,0 +1,124 @@
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: :ref:`Documentation/process/7.AdvancedTopics.rst <development_advancedtopics>`
+:Translator: Alex Shi <alex.shi@linux.alibaba.com>
+
+.. _cn_development_advancedtopics:
+
+高级主题
+========
+
+现在，希望您能够掌æ¡å¼€å‘æµç¨‹çš„工作方å¼ã€‚然而，还有更多的东西è¦å¦ï¼æœ¬èŠ‚将介ç»
+一些主题，这些主题对希望æˆä¸ºLinuxå†…æ ¸å¼€å‘过程常规部分的开å‘人员有帮助。
+
+使用Git管ç†è¡¥ä¸
+---------------
+
+å†…æ ¸ä½¿ç”¨åˆ†å¸ƒå¼ç‰ˆæœ¬æŽ§åˆ¶å§‹äºŽ2002å¹´åˆï¼Œå½“æ—¶Linus首次开始使用专有的Bitkeeper应用
+程åºã€‚虽然bitkeeperå˜åœ¨äº‰è®®ï¼Œä½†å®ƒæ‰€ä½“现的软件版本管ç†æ–¹æ³•å´è‚¯å®šä¸æ˜¯ã€‚分布å¼
+版本控制å¯ä»¥ç«‹å³åŠ é€Ÿå†…æ ¸å¼€å‘项目。在当å‰çš„æ—¶ä»£ï¼Œæœ‰å‡ ç§å…费的比特ä¿æŒå™¨æ›¿ä»£å“。
+æ— è®ºå¥½åï¼Œå†…æ ¸é¡¹ç›®éƒ½å°†Git作为其选择的工具。
+
+使用Git管ç†è¡¥ä¸å¯ä»¥ä½¿å¼€å‘äººå‘˜çš„ç”Ÿæ´»æ›´åŠ è½»æ¾ï¼Œå°¤å…¶æ˜¯éšç€è¡¥ä¸æ•°é‡çš„å¢žåŠ ã€‚Git
+也有其粗糙的边缘和一定的å±é™©ï¼Œå®ƒæ˜¯ä¸€ä¸ªå¹´è½»å’Œå¼ºå¤§çš„工具，ä»ç„¶åœ¨å…¶å¼€å‘人员完善
+ä¸ã€‚本文档ä¸ä¼šè¯•å›¾æ•™ä¼šè¯»è€…如何使用git；这会是个巨长的文档。相å，这里的é‡ç‚¹
+将是Git如何特别适åˆå†…æ ¸å¼€å‘过程。想è¦åŠ å¿«Gitçš„å¼€å‘人员å¯ä»¥åœ¨ä»¥ä¸‹ç½‘站上找到
+更多信æ¯ï¼š
+
+ http://git-scm.com/
+
+ http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
+
+在å°è¯•ä½¿ç”¨å®ƒä½¿è¡¥ä¸å¯ä¾›å…¶ä»–人使用之å‰ï¼Œç¬¬ä¸€è¦åŠ¡æ˜¯é˜…读上述站点，对Git的工作
+æ–¹å¼æœ‰ä¸€ä¸ªæ‰Žå®žçš„了解。使用Gitçš„å¼€å‘人员应该能够获得主线å˜å‚¨åº“的副本，探索
+修订历å²ï¼Œæäº¤å¯¹æ ‘çš„æ›´æ”¹ï¼Œä½¿ç”¨åˆ†æ”¯ç‰ã€‚了解Git用于é‡å†™åŽ†å²çš„工具（如Rebase）
+也很有用。Git有自己的术è¯å’Œæ¦‚念；Git的新用户应该了解refsã€è¿œç¨‹åˆ†æ”¯ã€ç´¢å¼•ã€
+å¿«è¿›åˆå¹¶ã€æŽ¨æ‹‰ã€åˆ†ç¦»å¤´ç‰ã€‚一开始å¯èƒ½æœ‰ç‚¹å“人，但这些概念ä¸éš¾é€šè¿‡ä¸€ç‚¹å¦ä¹ æ¥
+ç†è§£ã€‚
+
+使用git生æˆé€šè¿‡ç”µå邮件æ交的补ä¸æ˜¯æé«˜é€Ÿåº¦çš„ä¸€ä¸ªå¾ˆå¥½çš„ç»ƒä¹ ã€‚
+
+当您准备好开始安装Gitæ ‘ä¾›å…¶ä»–äººæŸ¥çœ‹æ—¶ï¼Œæ‚¨å½“ç„¶éœ€è¦ä¸€ä¸ªå¯ä»¥ä»Žä¸æå–çš„æœåŠ¡å™¨ã€‚
+如果您有一个å¯ä»¥è®¿é—®Internet的系统，那么使用gitå®ˆæŠ¤è¿›ç¨‹è®¾ç½®è¿™æ ·çš„æœåŠ¡å™¨ç›¸
+对简å•ã€‚å¦åˆ™ï¼Œå…费的公共托管网站（例如github）开始出现在网络上。æˆç†Ÿçš„å¼€å‘
+人员å¯ä»¥åœ¨kernel.org上获得一个å¸æˆ·ï¼Œä½†è¿™äº›å¸æˆ·å¹¶ä¸å®¹æ˜“找到；有关更多信æ¯ï¼Œ
+请å‚阅 http://kernel.org/faq/
+
+æ£å¸¸çš„Git工作æµç¨‹æ¶‰åŠåˆ°è®¸å¤šåˆ†æ”¯çš„使用。æ¯ä¸€æ¡å¼€å‘线都å¯ä»¥åˆ†ä¸ºå•ç‹¬çš„“主题
+分支â€ï¼Œå¹¶ç‹¬ç«‹ç»´æŠ¤ã€‚Git的分支机构很便宜，没有ç†ç”±ä¸å…费使用它们。而且，在
+任何情况下，您都ä¸åº”该在任何您打算让其他人从ä¸å—益的分支ä¸è¿›è¡Œå¼€å‘。应该
+å°å¿ƒåœ°åˆ›å»ºå…¬å¼€å¯ç”¨çš„分支；当它们处于完整的形å¼å¹¶å‡†å¤‡å¥½è¿è¡Œæ—¶(而ä¸æ˜¯ä¹‹å‰ï¼‰ï¼Œ
+åˆå¹¶å¼€å‘分支的补ä¸ã€‚
+
+Gitæ供了一些强大的工具，å¯ä»¥è®©æ‚¨é‡å†™å¼€å‘历å²ã€‚一个ä¸æ–¹ä¾¿çš„è¡¥ä¸ï¼ˆæ¯”如说，
+ä¸€ä¸ªæ‰“ç ´äºŒåˆ†æ³•çš„è¡¥ä¸ï¼Œæˆ–者有其他一些明显的缺陷）å¯ä»¥åœ¨é€‚当的ä½ç½®ä¿®å¤ï¼Œæˆ–者
+完全从历å²ä¸æ¶ˆå¤±ã€‚一个补ä¸ç³»åˆ—å¯ä»¥è¢«é‡å†™ï¼Œå°±å¥½åƒå®ƒæ˜¯åœ¨ä»Šå¤©çš„主线之上写的
+ä¸€æ ·ï¼Œå³ä½¿ä½ å·²ç»èŠ±äº†å‡ 个月的时间在写它。å¯ä»¥é€æ˜Žåœ°å°†æ›´æ”¹ä»Žä¸€ä¸ªåˆ†æ”¯è½¬ç§»åˆ°å¦
+一个分支。ç‰ç‰ã€‚明智地使用git修改历å²çš„能力å¯ä»¥å¸®åŠ©åˆ›å»ºé—®é¢˜æ›´å°‘的干净补ä¸é›†ã€‚
+
+然而，过度使用这ç§èƒ½åŠ›å¯èƒ½ä¼šå¯¼è‡´å…¶ä»–问题，而ä¸ä»…仅是对创建完美项目历å²çš„
+简å•ç—´è¿·ã€‚é‡å†™åŽ†å²å°†é‡å†™è¯¥åŽ†å²ä¸åŒ…å«çš„更改，将ç»è¿‡æµ‹è¯•ï¼ˆå¸Œæœ›ï¼‰çš„å†…æ ¸æ ‘å˜
+为未ç»æµ‹è¯•çš„å†…æ ¸æ ‘ã€‚ä½†æ˜¯ï¼Œé™¤æ¤ä¹‹å¤–，如果开å‘人员没有对项目历å²çš„共享视图，
+ä»–ä»¬å°±æ— æ³•è½»æ¾åœ°å作；如果您é‡å†™äº†å…¶ä»–å¼€å‘人员拉入他们å˜å‚¨åº“的历å²ï¼Œæ‚¨å°†
+使这些开å‘äººå‘˜çš„ç”Ÿæ´»æ›´åŠ å›°éš¾ã€‚å› æ¤ï¼Œè¿™é‡Œæœ‰ä¸€ä¸ªç®€å•çš„ç»éªŒæ³•åˆ™ï¼šè¢«å¯¼å‡ºåˆ°å…¶ä»–
+人的历å²åœ¨æ¤åŽé€šå¸¸è¢«è®¤ä¸ºæ˜¯ä¸å¯å˜çš„。
+
+å› æ¤ï¼Œä¸€æ—¦å°†ä¸€ç»„更改推é€åˆ°å…¬å¼€å¯ç”¨çš„æœåŠ¡å™¨ä¸Šï¼Œå°±ä¸åº”该é‡å†™è¿™äº›æ›´æ”¹ã€‚如果您
+å°è¯•å¼ºåˆ¶è¿›è¡Œä¸ä¼šå¯¼è‡´å¿«è¿›åˆå¹¶ï¼ˆå³ä¸å…±äº«åŒä¸€åŽ†å²è®°å½•çš„更改）的更改，Gitå°†å°
+试强制执行æ¤è§„则。å¯ä»¥é‡å†™æ¤æ£€æŸ¥ï¼Œæœ‰æ—¶å¯èƒ½éœ€è¦é‡å†™å¯¼å‡ºçš„æ ‘ã€‚åœ¨æ ‘ä¹‹é—´ç§»åŠ¨å˜
+更集以é¿å…Linux-nextä¸çš„冲çªå°±æ˜¯ä¸€ä¸ªä¾‹å。但这ç§è¡Œä¸ºåº”该是罕è§çš„。这就是为
+什么开å‘应该在ç§æœ‰åˆ†æ”¯ä¸è¿›è¡Œï¼ˆå¿…è¦æ—¶å¯ä»¥é‡å†™ï¼‰å¹¶ä¸”åªæœ‰åœ¨å…¬å…±åˆ†æ”¯å¤„于åˆç†çš„
+高级状æ€æ—¶æ‰è½¬ç§»åˆ°å…¬å…±åˆ†æ”¯ä¸çš„åŽŸå› ä¹‹ä¸€ã€‚
+
+当主线（或其他一组å˜æ›´æ‰€åŸºäºŽçš„æ ‘ï¼‰å‰è¿›æ—¶ï¼Œå¾ˆå®¹æ˜“ä¸Žè¯¥æ ‘åˆå¹¶ä»¥ä¿æŒé¢†å…ˆåœ°ä½ã€‚
+对于一个ç§æœ‰çš„分支，rebasing å¯èƒ½æ˜¯ä¸€ä¸ªå¾ˆå®¹æ˜“跟上å¦ä¸€æ£µæ ‘的方法，但是一旦
+ä¸€æ£µæ ‘è¢«å¯¼å‡ºåˆ°å…¨ä¸–ç•Œï¼Œrebasingå°±ä¸æ˜¯ä¸€ä¸ªé€‰é¡¹ã€‚一旦å‘生这ç§æƒ…况，就必须进行
+完全åˆå¹¶ï¼ˆmerge）。åˆå¹¶æœ‰æ—¶æ˜¯å¾ˆæœ‰æ„义的，但是过于频ç¹çš„åˆå¹¶ä¼šä¸å¿…è¦åœ°æ‰°ä¹±
+历å²ã€‚在这ç§æƒ…况下，建议的技术是ä¸ç»å¸¸åˆå¹¶ï¼Œé€šå¸¸åªåœ¨ç‰¹å®šçš„å‘布点（如主线-rc
+å‘布）åˆå¹¶ã€‚å¦‚æžœæ‚¨å¯¹ç‰¹å®šçš„æ›´æ”¹æ„Ÿåˆ°ç´§å¼ ï¼Œåˆ™å¯ä»¥å§‹ç»ˆåœ¨ç§æœ‰åˆ†æ”¯ä¸æ‰§è¡Œæµ‹è¯•åˆå¹¶ã€‚
+在这ç§æƒ…况下，git rerere 工具很有用；它记ä½åˆå¹¶å†²çªæ˜¯å¦‚ä½•è§£å†³çš„ï¼Œè¿™æ ·æ‚¨å°±
+ä¸å¿…é‡å¤ç›¸åŒçš„工作。
+
+关于Gitè¿™æ ·çš„å·¥å…·çš„ä¸€ä¸ªæœ€å¤§çš„åå¤æŠ±æ€¨æ˜¯ï¼šè¡¥ä¸ä»Žä¸€ä¸ªå˜å‚¨åº“到å¦ä¸€ä¸ªå˜å‚¨åº“çš„
+大é‡ç§»åŠ¨ä½¿å¾—很容易陷入错误建议的å˜æ›´ä¸ï¼Œè¿™äº›å˜æ›´é¿å¼€å®¡æŸ¥é›·è¾¾è¿›å…¥ä¸»çº¿ã€‚当内
+æ ¸å¼€å‘人员看到这ç§æƒ…况å‘生时，他们往往会感到ä¸é«˜å…´ï¼›åœ¨Gitæ ‘ä¸Šæ”¾ç½®æœªæŸ¥çœ‹æˆ–
+主题外的补ä¸å¯èƒ½ä¼šå½±å“您将æ¥èŽ·å–æ ‘çš„èƒ½åŠ›ã€‚å¼•ç”¨Linus:
+
+::
+
+ ä½ å¯ä»¥ç»™æˆ‘å‘è¡¥ä¸ï¼Œä½†è¦æˆ‘ä»Žä½ å“ªé‡Œå–一个Gitè¡¥ä¸ï¼Œæˆ‘需è¦çŸ¥é“ä½ çŸ¥é“
+ ä½ åœ¨åšä»€ä¹ˆï¼Œæˆ‘需è¦èƒ½å¤Ÿç›¸ä¿¡äº‹æƒ…而ä¸åŽ»æ£€æŸ¥æ¯ä¸ªä¸ªäººæ”¹å˜ã€‚
+
+（http://lwn.net/articles/224135/）。
+
+为了é¿å…è¿™ç§æƒ…况，请确ä¿ç»™å®šåˆ†æ”¯ä¸çš„所有补ä¸éƒ½ä¸Žç›¸å…³ä¸»é¢˜ç´§å¯†ç›¸å…³ï¼›â€œé©±åŠ¨ç¨‹åº
+ä¿®å¤â€åˆ†æ”¯ä¸åº”æ›´æ”¹æ ¸å¿ƒå†…å˜ç®¡ç†ä»£ç 。而且，最é‡è¦çš„是，ä¸è¦ä½¿ç”¨Gitæ ‘æ¥ç»•è¿‡
+审查过程。ä¸æ—¶çš„å°†æ ‘çš„æ‘˜è¦å‘布到相关的列表ä¸ï¼Œå½“时间åˆé€‚时，请求
+Linux-next ä¸åŒ…å«è¯¥æ ‘。
+
+如果其他人开始å‘é€è¡¥ä¸ä»¥åŒ…å«åˆ°æ‚¨çš„æ ‘ä¸ï¼Œä¸è¦å¿˜è®°æŸ¥çœ‹å®ƒä»¬ã€‚还è¦ç¡®ä¿æ‚¨ç»´æŠ¤æ£ç¡®
+的作者信æ¯ï¼› ``git am`` 工具在这方é¢åšå¾—最好，但是如果它通过第三方转å‘给您，
+您å¯èƒ½éœ€è¦åœ¨è¡¥ä¸ä¸æ·»åŠ “From：â€è¡Œã€‚
+
+请求pullæ“作时，请务必æ供所有相关信æ¯ï¼šæ ‘çš„ä½ç½®ã€è¦æ‹‰çš„分支以åŠæ‹‰æ“作将导致
+的更改。在这方é¢ï¼Œgit request pull 命令éžå¸¸æœ‰ç”¨ï¼›å®ƒå°†æŒ‰ç…§å…¶ä»–å¼€å‘人员的预期
+æ ¼å¼åŒ–请求，并检查以确ä¿æ‚¨è®°ä½äº†å°†è¿™äº›æ›´æ”¹æŽ¨é€åˆ°å…¬å…±æœåŠ¡å™¨ã€‚
+
+审查补ä¸
+--------
+
+一些读者当然会å对将本节与“高级主题â€æ”¾åœ¨ä¸€èµ·ï¼Œå› 为å³ä½¿æ˜¯åˆšå¼€å§‹çš„å†…æ ¸å¼€å‘人员
+也应该检查补ä¸ã€‚当然，å¦ä¹ å¦‚ä½•åœ¨å†…æ ¸çŽ¯å¢ƒä¸ç¼–程没有比查看其他人å‘布的代ç 更好
+的方法了。æ¤å¤–，审阅者永远供ä¸åº”求；通过查看代ç ，您å¯ä»¥å¯¹æ•´ä¸ªæµç¨‹åšå‡ºé‡å¤§è´¡çŒ®ã€‚
+
+审查代ç å¯èƒ½æ˜¯ä¸€ä¸ªä»¤äººç”Ÿç•çš„å‰æ™¯ï¼Œç‰¹åˆ«æ˜¯å¯¹äºŽä¸€ä¸ªæ–°çš„å†…æ ¸å¼€å‘人员æ¥è¯´ï¼Œä»–们
+å¯èƒ½ä¼šå¯¹å…¬å¼€è¯¢é—®ä»£ç æ„Ÿåˆ°ç´§å¼ ï¼Œè€Œè¿™äº›ä»£ç 是由那些有更多ç»éªŒçš„人å‘布的。ä¸è¿‡ï¼Œ
+å³ä½¿æ˜¯æœ€æœ‰ç»éªŒçš„å¼€å‘人员编写的代ç 也å¯ä»¥å¾—到改进。也许对评审员（所有评审员）
+最好的建议是：把评审评论当æˆé—®é¢˜è€Œä¸æ˜¯æ‰¹è¯„。询问“在这æ¡è·¯å¾„ä¸å¦‚何释放é”？â€
+总是比说“这里的é”是错误的â€æ›´å¥½ã€‚
+
+ä¸åŒçš„å¼€å‘人员将从ä¸åŒçš„角度审查代ç 。一些主è¦å…³æ³¨çš„是编ç æ ·å¼ä»¥åŠä»£ç 行是
+å¦æœ‰å°¾éšç©ºæ ¼ã€‚其他人将主è¦å…³æ³¨è¡¥ä¸ä½œä¸ºä¸€ä¸ªæ•´ä½“实现的å˜æ›´æ˜¯å¦å¯¹å†…æ ¸æœ‰å¥½å¤„ã€‚
+然而，其他人会检查是å¦å˜åœ¨é”定问题ã€å †æ ˆä½¿ç”¨è¿‡åº¦ã€å¯èƒ½çš„安全问题ã€åœ¨å…¶ä»–
+地方å‘现的代ç é‡å¤ã€è¶³å¤Ÿçš„文档ã€å¯¹æ€§èƒ½çš„ä¸åˆ©å½±å“ã€ç”¨æˆ·ç©ºé—´ABI更改ç‰ã€‚所有
+类型的检查，如果它们导致更好的代ç è¿›å…¥å†…æ ¸ï¼Œéƒ½æ˜¯å—欢迎和值得的。
diff --git a/Documentation/translations/zh_CN/process/8.Conclusion.rst b/Documentation/translations/zh_CN/process/8.Conclusion.rst
new file mode 100644
index 0000000000000000000000000000000000000000..2bbd76161e10c53a959cb7b16fb811fcdc0aba84
--- /dev/null
+++ b/Documentation/translations/zh_CN/process/8.Conclusion.rst
@@ -0,0 +1,64 @@
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: :ref:`Documentation/process/8.Conclusion.rst <development_conclusion>`
+:Translator: Alex Shi <alex.shi@linux.alibaba.com>
+
+.. _cn_development_conclusion:
+
+更多信æ¯
+========
+
+关于Linuxå†…æ ¸å¼€å‘和相关主题的信æ¯æ¥æºå¾ˆå¤šã€‚é¦–å…ˆæ˜¯åœ¨å†…æ ¸æºä»£ç 分å‘ä¸æ‰¾åˆ°çš„
+文档目录。顶级 :ref:`Documentation/translations/zh_CN/process/howto.rst <cn_process_howto>`
+文件是一个é‡è¦çš„起点
+:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
+和 :ref:`process/submitting-drivers.rst <submittingdrivers>`
+ä¹Ÿæ˜¯æ‰€æœ‰å†…æ ¸å¼€å‘äººå‘˜éƒ½åº”è¯¥é˜…è¯»çš„å†…å®¹ã€‚è®¸å¤šå†…éƒ¨å†…æ ¸API都是使用kerneldoc机制
+记录的；“make htmldocsâ€æˆ–“make pdfdocsâ€å¯ç”¨äºŽä»¥HTML或PDFæ ¼å¼ç”Ÿæˆè¿™äº›æ–‡æ¡£ï¼ˆ
+尽管æŸäº›å‘行版æ供的tex版本会é‡åˆ°å†…部é™åˆ¶ï¼Œæ— 法æ£ç¡®å¤„ç†æ–‡æ¡£ï¼‰ã€‚
+
+ä¸åŒçš„网站在å„ä¸ªç»†èŠ‚å±‚æ¬¡ä¸Šè®¨è®ºå†…æ ¸å¼€å‘。您的作者想谦虚地建议用 http://lwn.net/
+作为æ¥æºï¼›æœ‰å…³è®¸å¤šç‰¹å®šå†…æ ¸ä¸»é¢˜çš„ä¿¡æ¯å¯ä»¥é€šè¿‡ä»¥ä¸‹ç½‘å€çš„lwnå†…æ ¸ç´¢å¼•æ‰¾åˆ°ï¼š
+
+ http://lwn.net/kernel/index/
+
+除æ¤ä¹‹å¤–ï¼Œå†…æ ¸å¼€å‘人员的一个å®è´µèµ„æºæ˜¯ï¼š
+
+ http://kernelnewbies.org/
+
+当然，我们ä¸åº”该忘记 http://kernel.org/ è¿™æ˜¯å†…æ ¸å‘布信æ¯çš„最终ä½ç½®ã€‚
+
+å…³äºŽå†…æ ¸å¼€å‘有很多书：
+
+ Linux设备驱动程åºï¼Œç¬¬ä¸‰ç‰ˆï¼ˆJonathan Corbetã€Alessandro Rubiniå’ŒGreg Kroah Hartman）。
+ 在线：http://lwn.net/kernel/ldd3/
+
+ Linuxå†…æ ¸å¼€å‘（Robert Love）。
+
+ 了解Linuxå†…æ ¸ï¼ˆDaniel Bovetå’ŒMarco Cesati）。
+
+然而，所有这些书都有一个共åŒçš„缺点：当它们上架时，它们往往有些过时，而且它们
+å·²ç»ä¸Šæž¶ä¸€æ®µæ—¶é—´äº†ã€‚ä¸è¿‡ï¼Œåœ¨é‚£é‡Œè¿˜å¯ä»¥æ‰¾åˆ°ç›¸å½“多的好信æ¯ã€‚
+
+有关git的文档，请访问：
+
+ http://www.kernel.org/pub/software/scm/git/docs/
+
+ http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
+
+结论
+====
+
+ç¥è´ºæ‰€æœ‰é€šè¿‡è¿™ç¯‡å†—长的文件的人。希望它能够帮助您ç†è§£Linuxå†…æ ¸æ˜¯å¦‚ä½•å¼€å‘的，
+以åŠæ‚¨å¦‚何å‚与这个过程。
+
+最åŽï¼Œé‡è¦çš„是å‚与。任何开æºè½¯ä»¶é¡¹ç›®éƒ½ä¸è¶…过其贡献者投入其ä¸çš„总和。Linuxå†…æ ¸
+çš„å‘展速度和以å‰ä¸€æ ·å¿«ï¼Œå› 为它得到了大é‡å¼€å‘人员的帮助，他们都在努力使它å˜å¾—
+æ›´å¥½ã€‚å†…æ ¸æ˜¯ä¸€ä¸ªä¸»è¦çš„例å，说明当æˆåƒä¸Šä¸‡çš„人为了一个共åŒçš„ç›®æ ‡ä¸€èµ·å·¥ä½œæ—¶ï¼Œ
+å¯ä»¥åšäº›ä»€ä¹ˆã€‚
+
+ä¸è¿‡ï¼Œå†…æ ¸æ€»æ˜¯å¯ä»¥ä»Žæ›´å¤§çš„å¼€å‘人员基础ä¸èŽ·ç›Šã€‚总有更多的工作è¦åšã€‚但是，åŒæ ·
+é‡è¦çš„是，Linux生æ€ç³»ç»Ÿä¸çš„大多数其他å‚与者å¯ä»¥é€šè¿‡ä¸ºå†…æ ¸åšå‡ºè´¡çŒ®è€Œå—益。使
+代ç 进入主线是æ高代ç è´¨é‡ã€é™ä½Žç»´æŠ¤å’Œåˆ†å‘æˆæœ¬ã€æé«˜å¯¹å†…æ ¸å¼€å‘æ–¹å‘çš„å½±å“程度
+ç‰çš„关键。这是一ç§äººäººéƒ½èµ¢çš„å±€é¢ã€‚è¸¢å¼€ä½ çš„ç¼–è¾‘ï¼Œæ¥åŠ 入我们å§ï¼Œä½ 会éžå¸¸å—
+欢迎的。
diff --git a/Documentation/translations/zh_CN/process/code-of-conduct-interpretation.rst b/Documentation/translations/zh_CN/process/code-of-conduct-interpretation.rst
new file mode 100644
index 0000000000000000000000000000000000000000..c323ce76e0cb550e09d91ea497ffaf8a9352ccc0
--- /dev/null
+++ b/Documentation/translations/zh_CN/process/code-of-conduct-interpretation.rst
@@ -0,0 +1,108 @@
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: :ref:`Documentation/process/code-of-conduct-interpretation.rst <code_of_conduct_interpretation>`
+:Translator: Alex Shi <alex.shi@linux.alibaba.com>
+
+.. _cn_code_of_conduct_interpretation:
+
+Linuxå†…æ ¸è´¡çŒ®è€…å¥‘çº¦è¡Œä¸ºå‡†åˆ™è§£é‡Š
+===============================
+
+:ref:`cn_code_of_conduct` å‡†åˆ™æ˜¯ä¸€ä¸ªé€šç”¨æ–‡æ¡£ï¼Œæ—¨åœ¨ä¸ºå‡ ä¹Žæ‰€æœ‰å¼€æºç¤¾åŒºæ供一套规则。
+æ¯ä¸ªå¼€æºç¤¾åŒºéƒ½æ˜¯ç‹¬ä¸€æ— 二的，Linuxå†…æ ¸ä¹Ÿä¸ä¾‹å¤–ã€‚å› æ¤ï¼Œæœ¬æ–‡æ述了Linuxå†…æ ¸ç¤¾åŒºä¸
+如何解释它。我们也ä¸å¸Œæœ›è¿™ç§è§£é‡Šéšç€æ—¶é—´çš„推移是é™æ€çš„ï¼Œå¹¶å°†æ ¹æ®éœ€è¦è¿›è¡Œè°ƒæ•´ã€‚
+
+与开å‘è½¯ä»¶çš„â€œä¼ ç»Ÿâ€æ–¹æ³•ç›¸æ¯”，Linuxå†…æ ¸å¼€å‘工作是一个éžå¸¸ä¸ªäººåŒ–çš„è¿‡ç¨‹ã€‚ä½ çš„è´¡çŒ®
+和背åŽçš„æƒ³æ³•å°†è¢«ä»”ç»†å®¡æŸ¥ï¼Œå¾€å¾€å¯¼è‡´æ‰¹åˆ¤å’Œæ‰¹è¯„ã€‚å®¡æŸ¥å°†å‡ ä¹Žæ€»æ˜¯éœ€è¦æ”¹è¿›ï¼Œææ–™æ‰
+èƒ½åŒ…æ‹¬åœ¨å†…æ ¸ä¸ã€‚è¦çŸ¥é“è¿™æ˜¯å› ä¸ºæ‰€æœ‰ç›¸å…³äººå‘˜éƒ½å¸Œæœ›çœ‹åˆ°Linux整体æˆåŠŸçš„最佳解决方
+案。这个开å‘过程已ç»è¢«è¯æ˜Žå¯ä»¥åˆ›å»ºæœ‰å²ä»¥æ¥æœ€å¥å£®çš„æ“ä½œç³»ç»Ÿå†…æ ¸ï¼Œæˆ‘ä»¬ä¸æƒ³åšä»»ä½•
+事情æ¥å¯¼è‡´æ交质é‡å’Œæœ€ç»ˆç»“果的下é™ã€‚
+
+维护者
+------
+
+行为准则多次使用“维护者â€ä¸€è¯ã€‚åœ¨å†…æ ¸ç¤¾åŒºä¸ï¼Œâ€œç»´æŠ¤è€…â€æ˜¯è´Ÿè´£å系统ã€é©±åŠ¨ç¨‹åºæˆ–
+æ–‡ä»¶çš„ä»»ä½•äººï¼Œå¹¶åœ¨å†…æ ¸æºä»£ç æ ‘çš„ç»´æŠ¤è€…æ–‡ä»¶ä¸åˆ—出。
+
+责任
+----
+
+《行为准则》æ到了维护人员的æƒåˆ©å’Œè´£ä»»ï¼Œè¿™éœ€è¦è¿›ä¸€æ¥æ¾„清。
+
+首先，最é‡è¦çš„是，有一个åˆç†çš„期望是由维护人员通过实例æ¥é¢†å¯¼ã€‚
+
+也就是说，我们的社区是广阔的，对维护者没有新的è¦æ±‚，他们å•æ–¹é¢å¤„ç†å…¶ä»–人在
+他们活跃的社区的行为。这一责任由我们所有人承担，最终《行为准则》记录了最终的
+上诉路径，以防有关行为问题的问题悬而未决。
+
+维护人员应该愿æ„在出现问题时æ供帮助，并在需è¦æ—¶ä¸Žç¤¾åŒºä¸çš„其他人åˆä½œã€‚如果您
+ä¸ç¡®å®šå¦‚何处ç†å‡ºçŽ°çš„情况，请ä¸è¦å®³æ€•è”系技术咨询委员会（TAB）或其他维护人员。
+除éžæ‚¨æ„¿æ„，å¦åˆ™ä¸ä¼šå°†å…¶è§†ä¸ºè¿è§„报告。如果您ä¸ç¡®å®šæ˜¯å¦è¯¥è”ç³»TAB 或任何其他维
+护人员，请è”系我们的冲çªè°ƒè§£äºº Mishi Choudhary <mishi@linux.com>。
+
+最åŽï¼Œâ€œå–„待对方â€æ‰æ˜¯æ¯ä¸ªäººçš„æœ€ç»ˆç›®æ ‡ã€‚æˆ‘ä»¬çŸ¥é“æ¯ä¸ªäººéƒ½æ˜¯äººï¼Œæœ‰æ—¶æˆ‘们都会失败，
+但我们所有人的首è¦ç›®æ ‡åº”该是努力å‹å¥½åœ°è§£å†³é—®é¢˜ã€‚执行行为准则将是最åŽçš„选择。
+
+æˆ‘ä»¬çš„ç›®æ ‡æ˜¯åˆ›å»ºä¸€ä¸ªå¼ºå¤§çš„ã€æŠ€æœ¯å…ˆè¿›çš„æ“作系统，以åŠæ‰€æ¶‰åŠçš„技术å¤æ‚性，这自
+然需è¦ä¸“业知识和决ç–。
+
+æ‰€éœ€çš„ä¸“ä¸šçŸ¥è¯†å› è´¡çŒ®é¢†åŸŸè€Œå¼‚ã€‚å®ƒä¸»è¦ç”±ä¸Šä¸‹æ–‡å’ŒæŠ€æœ¯å¤æ‚性决定，其次由贡献者和
+维护者的期望决定。
+
+专家的期望和决ç–都è¦ç»è¿‡è®¨è®ºï¼Œä½†åœ¨æœ€åŽï¼Œä¸ºäº†å–得进展，必须能够åšå‡ºå†³ç–。这一
+特æƒæŽŒæ¡åœ¨ç»´æŠ¤äººå‘˜å’Œé¡¹ç›®é¢†å¯¼çš„手ä¸ï¼Œé¢„计将善æ„使用。
+
+å› æ¤ï¼Œè®¾å®šä¸“业知识期望ã€ä½œå‡ºå†³å®šå’Œæ‹’ç»ä¸é€‚当的贡献ä¸è¢«è§†ä¸ºè¿å行为准则。
+
+虽然维护人员一般都欢迎新æ¥è€…，但他们帮助（新）贡献者克æœéšœç¢çš„能力有é™ï¼Œå› æ¤
+他们必须确定优先事项。这也ä¸åº”被视为è¿åäº†è¡Œä¸ºå‡†åˆ™ã€‚å†…æ ¸ç¤¾åŒºæ„识到这一点，并
+以å„ç§å½¢å¼æ供入门级节目，如 kernelnewbies.org 。
+
+范围
+----
+
+Linuxå†…æ ¸ç¤¾åŒºä¸»è¦åœ¨ä¸€ç»„公共电å邮件列表上进行交互，这些列表分布在由多个ä¸åŒ
+å…¬å¸æˆ–个人控制的多个ä¸åŒæœåŠ¡å™¨ä¸Šã€‚æ‰€æœ‰è¿™äº›åˆ—è¡¨éƒ½åœ¨å†…æ ¸æºä»£ç æ ‘ä¸çš„
+MAINTAINERS 文件ä¸å®šä¹‰ã€‚å‘é€åˆ°è¿™äº›é‚®ä»¶åˆ—表的任何电å邮件都被视为包å«åœ¨è¡Œä¸º
+准则ä¸ã€‚
+
+使用 kernel.org bugzilla和其他å系统bugzilla 或bug跟踪工具的开å‘人员应该éµå¾ª
+行为准则的指导原则。Linuxå†…æ ¸ç¤¾åŒºæ²¡æœ‰â€œå®˜æ–¹â€é¡¹ç›®ç”µå邮件地å€æˆ–“官方â€ç¤¾äº¤åª’体
+地å€ã€‚使用kernel.org电å邮件å¸æˆ·æ‰§è¡Œçš„任何活动必须éµå¾ªä¸ºkernel.orgå‘布的行为
+准则，就åƒä»»ä½•ä½¿ç”¨å…¬å¸ç”µå邮件å¸æˆ·çš„个人必须éµå¾ªè¯¥å…¬å¸çš„ç‰¹å®šè§„åˆ™ä¸€æ ·ã€‚
+
+行为准则并ä¸ç¦æ¢åœ¨é‚®ä»¶åˆ—表消æ¯ã€å†…æ ¸æ›´æ”¹æ—¥å¿—æ¶ˆæ¯æˆ–代ç 注释ä¸ç»§ç»åŒ…å«å称ã€
+电å邮件地å€å’Œç›¸å…³æ³¨é‡Šã€‚
+
+其他论å›ä¸çš„互动包括在适用于上述论å›çš„任何规则ä¸ï¼Œé€šå¸¸ä¸åŒ…括在行为准则ä¸ã€‚
+除了在æžç«¯æƒ…况下å¯è€ƒè™‘的例外情况。
+
+æäº¤ç»™å†…æ ¸çš„è´¡çŒ®åº”è¯¥ä½¿ç”¨é€‚å½“çš„è¯è¨€ã€‚在行为准则之å‰å·²ç»å˜åœ¨çš„内容现在ä¸ä¼šè¢«
+视为è¿å。然而，ä¸é€‚当的è¯è¨€å¯ä»¥è¢«è§†ä¸ºä¸€ä¸ªbug；如果任何相关方æ交补ä¸ï¼Œ
+è¿™æ ·çš„bug将被更快地修å¤ã€‚当å‰å±žäºŽç”¨æˆ·/å†…æ ¸API的一部分的表达å¼ï¼Œæˆ–者åæ˜ å·²
+å‘å¸ƒæ ‡å‡†æˆ–è§„èŒƒä¸ä½¿ç”¨çš„术è¯çš„表达å¼ï¼Œä¸è¢«è§†ä¸ºbug。
+
+执行
+----
+
+行为准则ä¸åˆ—出的地å€å±žäºŽè¡Œä¸ºå‡†åˆ™å§”员会。https://kernel.org/code-of-conduct.html
+列出了在任何给定时间接收这些电å邮件的确切æˆå‘˜ã€‚æˆå‘˜ä¸èƒ½è®¿é—®åœ¨åŠ 入委员会之å‰
+或离开委员会之åŽæ‰€åšçš„报告。
+
+最åˆçš„行为准则委员会由TAB的志愿者以åŠä½œä¸ºä¸ç«‹ç¬¬ä¸‰æ–¹çš„专业调解人组æˆã€‚委员会
+的首è¦ä»»åŠ¡æ˜¯å»ºç«‹æ–‡ä»¶åŒ–çš„æµç¨‹ï¼Œå¹¶å°†å…¶å…¬å¼€ã€‚
+
+如果报告人ä¸å¸Œæœ›å°†æ•´ä¸ªå§”员会纳入投诉或关切，å¯ç›´æŽ¥è”系委员会的任何æˆå‘˜ï¼ŒåŒ…括
+调解人。
+
+è¡Œä¸ºå‡†åˆ™å§”å‘˜ä¼šæ ¹æ®æµç¨‹å®¡æŸ¥æ¡ˆä¾‹ï¼ˆè§ä¸Šæ–‡ï¼‰ï¼Œå¹¶æ ¹æ®éœ€è¦å’Œé€‚当与TABå商，例如请求
+å’ŒæŽ¥æ”¶æœ‰å…³å†…æ ¸ç¤¾åŒºçš„ä¿¡æ¯ã€‚
+
+委员会åšå‡ºçš„任何决定都将æ交到表ä¸ï¼Œä»¥ä¾¿åœ¨å¿…è¦æ—¶ä¸Žç›¸å…³ç»´æŠ¤äººå‘˜ä¸€èµ·æ‰§è¡Œã€‚行为
+准则委员会的决定å¯ä»¥é€šè¿‡ä¸‰åˆ†ä¹‹äºŒçš„投票推翻。
+
+æ¯å£åº¦ï¼Œè¡Œä¸ºå‡†åˆ™å§”å‘˜ä¼šå’Œæ ‡ç¾å°†æ供一份报告，概述行为准则委员会收到的匿å报告
+åŠå…¶çŠ¶æ€ï¼Œä»¥åŠä»»ä½•å¦å†³å†³å®šçš„细节，包括完整和å¯è¯†åˆ«çš„投票细节。
+
+我们希望在å¯åŠ¨æœŸä¹‹åŽä¸ºè¡Œä¸ºå‡†åˆ™å§”员会人员é…备建立一个ä¸åŒçš„æµç¨‹ã€‚å‘生æ¤æƒ…况时，
+将使用该信æ¯æ›´æ–°æ¤æ–‡æ¡£ã€‚
diff --git a/Documentation/translations/zh_CN/process/code-of-conduct.rst b/Documentation/translations/zh_CN/process/code-of-conduct.rst
new file mode 100644
index 0000000000000000000000000000000000000000..99024df058e948176cfed35d58ef0fa3582518d6
--- /dev/null
+++ b/Documentation/translations/zh_CN/process/code-of-conduct.rst
@@ -0,0 +1,72 @@
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: :ref:`Documentation/process/code-of-conduct.rst <code_of_conduct>`
+:Translator: Alex Shi <alex.shi@linux.alibaba.com>
+
+.. _cn_code_of_conduct:
+
+贡献者契约行为准则
+++++++++++++++++++
+
+我们的誓言
+==========
+
+为了è¥é€ 一个开放ã€å‹å¥½çš„环境，我们作为贡献者和维护人承诺，让我们的社区和å‚
+ä¸Žè€…ï¼Œæ‹¥æœ‰ä¸€ä¸ªæ— éªšæ‰°çš„ä½“éªŒï¼Œæ— è®ºå¹´é¾„ã€ä½“åž‹ã€æ®‹ç–¾ã€ç§æ—ã€æ€§åˆ«ç‰¹å¾ã€æ€§åˆ«è®¤åŒ
+和表达ã€ç»éªŒæ°´å¹³ã€æ•™è‚²ç¨‹åº¦ã€ç¤¾ä¼šçŠ¶å†µï¼Œç»æµŽåœ°ä½ã€å›½ç±ã€ä¸ªäººå¤–貌ã€ç§æ—ã€å®—æ•™
+或性身份和å–å‘。
+
+æˆ‘ä»¬çš„æ ‡å‡†
+==========
+
+æœ‰åŠ©äºŽåˆ›é€ ç§¯æžçŽ¯å¢ƒçš„行为包括：
+
+* 使用欢迎和包容的è¯è¨€
+* å°Šé‡ä¸åŒçš„观点和ç»éªŒ
+* 优雅地接å—建设性的批评
+* 关注什么对社区最有利
+* 对其他社区æˆå‘˜è¡¨ç¤ºåŒæƒ…
+
+å‚与者的ä¸å¯æŽ¥å—行为包括：
+
+* 使用性æ„味的è¯è¨€æˆ–æ„象以åŠä¸å—欢迎的性注æ„或者更过分的行为
+* 煽动ã€ä¾®è¾±/è´¬æŸè¯„论以åŠä¸ªäººæˆ–政治攻击
+* 公开或ç§ä¸‹éªšæ‰°
+* 未ç»æ˜Žç¡®è®¸å¯ï¼Œå‘布他人的ç§äººä¿¡æ¯ï¼Œå¦‚物ç†æˆ–电å地å€ã€‚
+* 在专业场åˆè¢«åˆç†è®¤ä¸ºä¸é€‚当的其他行为
+
+我们的责任
+==========
+
+维护人员负责澄清å¯æŽ¥å—è¡Œä¸ºçš„æ ‡å‡†ï¼Œå¹¶åº”é’ˆå¯¹ä»»ä½•ä¸å¯æŽ¥å—行为采å–适当和公平的
+çº æ£æŽªæ–½ã€‚
+
+维护人员有æƒå’Œè´£ä»»åˆ 除ã€ç¼–辑或拒ç»ä¸Žæœ¬è¡Œä¸ºå‡†åˆ™ä¸ä¸€è‡´çš„评论ã€æ‰¿è¯ºã€ä»£ç ã€
+wiki编辑ã€é—®é¢˜å’Œå…¶ä»–贡献，或暂时或永久ç¦æ¢ä»»ä½•è´¡çŒ®è€…从事他们认为ä¸é€‚当ã€
+å¨èƒã€å†’犯或有害的其他行为。
+
+范围
+====
+
+当个人代表项目或其社区时，本行为准则既适用于项目空间，也适用于公共空间。
+代表一个项目或社区的例å包括使用一个æ£å¼çš„项目电å邮件地å€ï¼Œé€šè¿‡ä¸€ä¸ªæ£å¼
+的社交媒体å¸æˆ·å‘布，或者在在线或离线事件ä¸æ‹…任指定的代表。项目维护人员å¯ä»¥
+进一æ¥å®šä¹‰å’Œæ¾„清项目的表示。
+
+执行
+====
+
+如有滥用ã€éªšæ‰°æˆ–其他ä¸å¯æŽ¥å—的行为，å¯è”系行为准则委员会<conduct@kernel.org>。
+所有投诉都将接å—审查和调查，并将得到必è¦å’Œé€‚当的ç”å¤ã€‚行为准则委员会有义务
+对事件报告人ä¿å¯†ã€‚具体执行政ç–的进一æ¥ç»†èŠ‚å¯å•ç‹¬å…¬å¸ƒã€‚
+
+归属
+====
+
+本行为准则改编自《贡献者契约》，版本1.4，å¯ä»Ž
+https://www.contributor-covenant.org/version/1/4/code-of-conduct.html 获å–。
+
+解释
+====
+
+有关Linuxå†…æ ¸ç¤¾åŒºå¦‚ä½•è§£é‡Šæ¤æ–‡æ¡£ï¼Œè¯·å‚阅 :ref:`cn_code_of_conduct_interpretation`
diff --git a/Documentation/translations/zh_CN/coding-style.rst b/Documentation/translations/zh_CN/process/coding-style.rst
similarity index 97%
rename from Documentation/translations/zh_CN/coding-style.rst
rename to Documentation/translations/zh_CN/process/coding-style.rst
index 3cb09803e084683ce192441cf7f60b84fc7422ac..5479c591c2f71e9d6d1d83e5dc33e5285cf17c49 100644
--- a/Documentation/translations/zh_CN/coding-style.rst
+++ b/Documentation/translations/zh_CN/process/coding-style.rst
@@ -1,19 +1,10 @@
-Chinese translated version of Documentation/process/coding-style.rst
+.. include:: ../disclaimer-zh_CN.rst
-If you have any comment or update to the content, please post to LKML directly.
-However, if you have problem communicating in English you can also ask the
-Chinese maintainer for help. Contact the Chinese maintainer, if this
-translation is outdated or there is problem with translation.
+:Original: :ref:`Documentation/process/coding-style.rst <codingstyle>`
-Chinese maintainer: Zhang Le <r0bertz@gentoo.org>
+.. _cn_codingstyle:
----------------------------------------------------------------------
-
-Documentation/process/coding-style.rst çš„ä¸æ–‡ç¿»è¯‘
-
-如果想评论或更新本文的内容，请直接å‘信到LKMLã€‚å¦‚æžœä½ ä½¿ç”¨è‹±æ–‡äº¤æµæœ‰å›°éš¾çš„è¯ï¼Œ
-也å¯ä»¥å‘ä¸æ–‡ç‰ˆç»´æŠ¤è€…求助。如果本翻译更新ä¸åŠæ—¶æˆ–者翻译å˜åœ¨é—®é¢˜ï¼Œè¯·è”ç³»ä¸æ–‡ç‰ˆ
-维护者::
+译者::
ä¸æ–‡ç‰ˆç»´æŠ¤è€…： å¼ ä¹ Zhang Le <r0bertz@gentoo.org>
ä¸æ–‡ç‰ˆç¿»è¯‘者： å¼ ä¹ Zhang Le <r0bertz@gentoo.org>
@@ -23,10 +14,6 @@ Documentation/process/coding-style.rst çš„ä¸æ–‡ç¿»è¯‘
Li Zefan <lizf@cn.fujitsu.com>
Wang Chen <wangchen@cn.fujitsu.com>
-以下为æ£æ–‡
-
----------------------------------------------------------------------
-
Linux å†…æ ¸ä»£ç é£Žæ ¼
=========================
diff --git a/Documentation/translations/zh_CN/process/development-process.rst b/Documentation/translations/zh_CN/process/development-process.rst
new file mode 100644
index 0000000000000000000000000000000000000000..30cffe66c0758adcee01138a59b8db4e5c39b11d
--- /dev/null
+++ b/Documentation/translations/zh_CN/process/development-process.rst
@@ -0,0 +1,26 @@
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: :ref:`Documentation/process/development-process.rst <development_process_main>`
+:Translator: Alex Shi <alex.shi@linux.alibaba.com>
+
+.. _cn_development_process_main:
+
+å†…æ ¸å¼€å‘过程指å—
+================
+
+内容:
+
+.. toctree::
+ :numbered:
+ :maxdepth: 2
+
+ 1.Intro
+ 2.Process
+ 3.Early-stage
+ 4.Coding
+ 5.Posting
+ 6.Followthrough
+ 7.AdvancedTopics
+ 8.Conclusion
+
+本文档的目的是帮助开å‘人员（åŠå…¶ç»ç†ï¼‰ä»¥æœ€å°çš„挫折感与开å‘社区åˆä½œã€‚它试图记录这个社区如何以一ç§ä¸ç†Ÿæ‚‰Linuxå†…æ ¸å¼€å‘（或者实际上是自由软件开å‘）的人å¯ä»¥è®¿é—®çš„æ–¹å¼å·¥ä½œã€‚虽然这里有一些技术资料，但这是一个é¢å‘过程的讨论，ä¸éœ€è¦æ·±å…¥äº†è§£å†…æ ¸ç¼–ç¨‹å°±å¯ä»¥ç†è§£ã€‚
diff --git a/Documentation/translations/zh_CN/email-clients.txt b/Documentation/translations/zh_CN/process/email-clients.rst
similarity index 74%
rename from Documentation/translations/zh_CN/email-clients.txt
rename to Documentation/translations/zh_CN/process/email-clients.rst
index ec31d97e8d0e9f7a8e7217fffc56d46acb0be2e0..1020236511182f3345baf9b000497716057350ba 100644
--- a/Documentation/translations/zh_CN/email-clients.txt
+++ b/Documentation/translations/zh_CN/process/email-clients.rst
@@ -1,33 +1,34 @@
-Chinese translated version of Documentation/process/email-clients.rst
+.. _cn_email_clients:
-If you have any comment or update to the content, please contact the
-original document maintainer directly. However, if you have a problem
-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.
+.. include:: ../disclaimer-zh_CN.rst
-Chinese maintainer: Harry Wei <harryxiyou@gmail.com>
----------------------------------------------------------------------
-Documentation/process/email-clients.rst çš„ä¸æ–‡ç¿»è¯‘
+:Original: :ref:`Documentation/process/email-clients.rst <email_clients>`
-如果想评论或更新本文的内容，请直接è”ç³»åŽŸæ–‡æ¡£çš„ç»´æŠ¤è€…ã€‚å¦‚æžœä½ ä½¿ç”¨è‹±æ–‡
-交æµæœ‰å›°éš¾çš„è¯ï¼Œä¹Ÿå¯ä»¥å‘ä¸æ–‡ç‰ˆç»´æŠ¤è€…求助。如果本翻译更新ä¸åŠæ—¶æˆ–者翻
-译å˜åœ¨é—®é¢˜ï¼Œè¯·è”ç³»ä¸æ–‡ç‰ˆç»´æŠ¤è€…。
+译者::
-ä¸æ–‡ç‰ˆç»´æŠ¤è€…： è´¾å¨å¨ Harry Wei <harryxiyou@gmail.com>
-ä¸æ–‡ç‰ˆç¿»è¯‘者： è´¾å¨å¨ Harry Wei <harryxiyou@gmail.com>
-ä¸æ–‡ç‰ˆæ ¡è¯‘者： Yinglin Luan <synmyth@gmail.com>
- Xiaochen Wang <wangxiaochen0@gmail.com>
- yaxinsn <yaxinsn@163.com>
-
-以下为æ£æ–‡
----------------------------------------------------------------------
+ ä¸æ–‡ç‰ˆç»´æŠ¤è€…： è´¾å¨å¨ Harry Wei <harryxiyou@gmail.com>
+ ä¸æ–‡ç‰ˆç¿»è¯‘者： è´¾å¨å¨ Harry Wei <harryxiyou@gmail.com>
+ 时奎亮 Alex Shi <alex.shi@linux.alibaba.com>
+ ä¸æ–‡ç‰ˆæ ¡è¯‘者： Yinglin Luan <synmyth@gmail.com>
+ Xiaochen Wang <wangxiaochen0@gmail.com>
+ yaxinsn <yaxinsn@163.com>
Linux邮件客户端é…置信æ¯
-======================================================================
+=======================
+
+Git
+---
+
+现在大多数开å‘人员使用 ``git send-email`` 而ä¸æ˜¯å¸¸è§„的电å邮件客户端。这方é¢
+的手册éžå¸¸å¥½ã€‚在接收端，维护人员使用 ``git am`` åŠ è½½è¡¥ä¸ã€‚
+
+å¦‚æžœä½ æ˜¯ ``git`` æ–°æ‰‹ï¼Œé‚£ä¹ˆæŠŠä½ çš„ç¬¬ä¸€ä¸ªè¡¥ä¸å‘é€ç»™ä½ 自己。将其ä¿å˜ä¸ºåŒ…å«æ‰€æœ‰
+æ ‡é¢˜çš„åŽŸå§‹æ–‡æœ¬ã€‚è¿è¡Œ ``git am raw_email.txt`` ，然åŽä½¿ç”¨ ``git log`` 查看更
+改日志。如果工作æ£å¸¸ï¼Œå†å°†è¡¥ä¸å‘é€åˆ°ç›¸åº”的邮件列表。
+
普通é…ç½®
-----------------------------------------------------------------------
+--------
Linuxå†…æ ¸è¡¥ä¸æ˜¯é€šè¿‡é‚®ä»¶è¢«æ交的，最好把补ä¸ä½œä¸ºé‚®ä»¶ä½“的内嵌文本。有些维护者
æŽ¥æ”¶é™„ä»¶ï¼Œä½†æ˜¯é™„ä»¶çš„å†…å®¹æ ¼å¼åº”该是"text/plain"。然而，附件一般是ä¸èµžæˆçš„，
å› ä¸ºè¿™ä¼šä½¿è¡¥ä¸çš„引用部分在评论过程ä¸å˜çš„很困难。
@@ -56,7 +57,7 @@ Linuxå†…æ ¸è¡¥ä¸æ˜¯é€šè¿‡é‚®ä»¶è¢«æ交的，最好把补ä¸ä½œä¸ºé‚®ä»¶ä½“çš„
一些邮件客户端æ示
-----------------------------------------------------------------------
+------------------
这里给出一些详细的MUAé…ç½®æ示，å¯ä»¥ç”¨äºŽç»™Linuxå†…æ ¸å‘é€è¡¥ä¸ã€‚这些并ä¸æ„味是
所有的软件包é…置总结。
@@ -64,8 +65,8 @@ Linuxå†…æ ¸è¡¥ä¸æ˜¯é€šè¿‡é‚®ä»¶è¢«æ交的，最好把补ä¸ä½œä¸ºé‚®ä»¶ä½“çš„
TUI = 以文本为基础的用户接å£
GUI = 图形界é¢ç”¨æˆ·æŽ¥å£
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Alpine (TUI)
+~~~~~~~~~~~~
é…置选项：
在"Sending Preferences"部分：
@@ -76,8 +77,8 @@ Alpine (TUI)
å½“å†™é‚®ä»¶æ—¶ï¼Œå…‰æ ‡åº”è¯¥æ”¾åœ¨è¡¥ä¸ä¼šå‡ºçŽ°çš„地方，然åŽæŒ‰ä¸‹CTRL-R组åˆé”®ï¼Œä½¿æŒ‡å®šçš„
è¡¥ä¸æ–‡ä»¶åµŒå…¥åˆ°é‚®ä»¶ä¸ã€‚
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Evolution (GUI)
+~~~~~~~~~~~~~~~
一些开å‘者æˆåŠŸçš„使用它å‘é€è¡¥ä¸
@@ -89,8 +90,8 @@ Evolution (GUI)
ä½ è¿˜å¯ä»¥"diff -Nru old.c new.c | xclip"，选择Preformat，然åŽä½¿ç”¨ä¸é—´é”®è¿›è¡Œç²˜å¸–。
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kmail (GUI)
+~~~~~~~~~~~
一些开å‘者æˆåŠŸçš„使用它å‘é€è¡¥ä¸ã€‚
@@ -118,13 +119,13 @@ display"ï¼Œè¿™æ ·å†…åµŒé™„ä»¶æ›´å®¹æ˜“è®©è¯»è€…çœ‹åˆ°ã€‚
并且希望这将会被处ç†ã€‚邮件是以åªé’ˆå¯¹æŸä¸ªç”¨æˆ·å¯è¯»å†™çš„æƒé™è¢«ä¿å˜çš„ï¼Œæ‰€ä»¥å¦‚æžœä½ æƒ³æŠŠé‚®ä»¶å¤åˆ¶åˆ°å…¶ä»–地方，
ä½ ä¸å¾—ä¸æŠŠä»–们的æƒé™æ”¹ä¸ºç»„或者整体å¯è¯»ã€‚
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Lotus Notes (GUI)
+~~~~~~~~~~~~~~~~~
ä¸è¦ä½¿ç”¨å®ƒã€‚
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mutt (TUI)
+~~~~~~~~~~
很多Linuxå¼€å‘人员使用mutt客户端，所以è¯æ˜Žå®ƒè‚¯å®šå·¥ä½œçš„éžå¸¸æ¼‚亮。
@@ -142,12 +143,49 @@ Muttä¸è‡ªå¸¦ç¼–辑器，所以ä¸ç®¡ä½ 使用什么编辑器都ä¸åº”该带有
如果想è¦æŠŠè¡¥ä¸ä½œä¸ºå†…嵌文本。
(a)ttach工作的很好，ä¸å¸¦æœ‰"set paste"。
+ä½ å¯ä»¥é€šè¿‡ ``git format-patch`` 生æˆè¡¥ä¸ï¼Œç„¶åŽç”¨ Muttå‘é€å®ƒä»¬::
+
+ $ mutt -H 0001-some-bug-fix.patch
+
é…置选项：
它应该以默认设置的形å¼å·¥ä½œã€‚
然而，把"send_charset"设置为"us-ascii::utf-8"也是一个ä¸é”™çš„主æ„。
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Mutt 是高度å¯é…置的。 这里是个使用mutt通过 Gmail å‘é€çš„è¡¥ä¸çš„最å°é…ç½®::
+
+ # .muttrc
+ # ================ IMAP ====================
+ set imap_user = 'yourusername@gmail.com'
+ set imap_pass = 'yourpassword'
+ set spoolfile = imaps://imap.gmail.com/INBOX
+ set folder = imaps://imap.gmail.com/
+ set record="imaps://imap.gmail.com/[Gmail]/Sent Mail"
+ set postponed="imaps://imap.gmail.com/[Gmail]/Drafts"
+ set mbox="imaps://imap.gmail.com/[Gmail]/All Mail"
+
+ # ================ SMTP ====================
+ set smtp_url = "smtp://username@smtp.gmail.com:587/"
+ set smtp_pass = $imap_pass
+ set ssl_force_tls = yes # Require encrypted connection
+
+ # ================ Composition ====================
+ set editor = `echo \$EDITOR`
+ set edit_headers = yes # See the headers when editing
+ set charset = UTF-8 # value of $LANG; also fallback for send_charset
+ # Sender, email address, and sign-off line must match
+ unset use_domain # because joe@localhost is just embarrassing
+ set realname = "YOUR NAME"
+ set from = "username@gmail.com"
+ set use_from = yes
+
+Mutt文档å«æœ‰æ›´å¤šä¿¡æ¯:
+
+ http://dev.mutt.org/trac/wiki/UseCases/Gmail
+
+ http://dev.mutt.org/doc/manual.html
+
Pine (TUI)
+~~~~~~~~~~
Pineè¿‡åŽ»æœ‰ä¸€äº›ç©ºæ ¼åˆ å‡é—®é¢˜ï¼Œä½†æ˜¯è¿™äº›çŽ°åœ¨åº”该都被修å¤äº†ã€‚
@@ -158,8 +196,8 @@ Pineè¿‡åŽ»æœ‰ä¸€äº›ç©ºæ ¼åˆ å‡é—®é¢˜ï¼Œä½†æ˜¯è¿™äº›çŽ°åœ¨åº”该都被修å¤äº†
- "no-strip-whitespace-before-send"选项也是需è¦çš„。
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sylpheed (GUI)
+~~~~~~~~~~~~~~
- 内嵌文本å¯ä»¥å¾ˆå¥½çš„工作（或者使用附件）。
- å…许使用外部的编辑器。
@@ -168,8 +206,8 @@ Sylpheed (GUI)
- 在组æˆçª—å£ä¸æœ‰ä¸€ä¸ªå¾ˆæœ‰ç”¨çš„ruler bar。
- 给地å€æœ¬ä¸æ·»åŠ 地å€å°±ä¸ä¼šæ£ç¡®çš„了解显示å。
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Thunderbird (GUI)
+~~~~~~~~~~~~~~~~~
默认情况下，thunderbird很容易æŸå文本，但是还有一些方法å¯ä»¥å¼ºåˆ¶å®ƒå˜å¾—更好。
@@ -191,13 +229,13 @@ Thunderbird (GUI)
$EDITORæ¥è¯»å–或者åˆå¹¶è¡¥ä¸åˆ°æ–‡æœ¬ä¸ã€‚è¦å®žçŽ°å®ƒï¼Œå¯ä»¥ä¸‹è½½å¹¶ä¸”安装这个扩展，然åŽæ·»åŠ 一个使用它的
按键View->Toolbars->Customize...最åŽå½“ä½ ä¹¦å†™ä¿¡æ¯çš„时候仅仅点击它就å¯ä»¥äº†ã€‚
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TkRat (GUI)
+~~~~~~~~~~~
å¯ä»¥ä½¿ç”¨å®ƒã€‚使用"Insert file..."或者外部的编辑器。
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Gmail (Web GUI)
+~~~~~~~~~~~~~~~
ä¸è¦ä½¿ç”¨å®ƒå‘é€è¡¥ä¸ã€‚
diff --git a/Documentation/translations/zh_CN/HOWTO b/Documentation/translations/zh_CN/process/howto.rst
similarity index 70%
rename from Documentation/translations/zh_CN/HOWTO
rename to Documentation/translations/zh_CN/process/howto.rst
index 7a00a8a4eb15a571dfd43de6be25ee698d6cc8de..5b671178b17b9d61d3cd7a372538a4489f282c70 100644
--- a/Documentation/translations/zh_CN/HOWTO
+++ b/Documentation/translations/zh_CN/process/howto.rst
@@ -1,32 +1,22 @@
-Chinese translated version of Documentation/process/howto.rst
+.. _cn_process_howto:
-If you have any comment or update to the content, please contact the
-original document maintainer directly. However, if you have a problem
-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.
+.. include:: ../disclaimer-zh_CN.rst
-Maintainer: Greg Kroah-Hartman <greg@kroah.com>
-Chinese maintainer: Li Yang <leoli@freescale.com>
----------------------------------------------------------------------
-Documentation/process/howto.rst çš„ä¸æ–‡ç¿»è¯‘
+:Original: :ref:`Documentation/process/howto.rst <process_howto>`
-如果想评论或更新本文的内容，请直接è”ç³»åŽŸæ–‡æ¡£çš„ç»´æŠ¤è€…ã€‚å¦‚æžœä½ ä½¿ç”¨è‹±æ–‡
-交æµæœ‰å›°éš¾çš„è¯ï¼Œä¹Ÿå¯ä»¥å‘ä¸æ–‡ç‰ˆç»´æŠ¤è€…求助。如果本翻译更新ä¸åŠæ—¶æˆ–者翻
-译å˜åœ¨é—®é¢˜ï¼Œè¯·è”ç³»ä¸æ–‡ç‰ˆç»´æŠ¤è€…。
+译者::
-英文版维护者： Greg Kroah-Hartman <greg@kroah.com>
-ä¸æ–‡ç‰ˆç»´æŠ¤è€…： æŽé˜³ Li Yang <leoli@freescale.com>
-ä¸æ–‡ç‰ˆç¿»è¯‘者： æŽé˜³ Li Yang <leoli@freescale.com>
-ä¸æ–‡ç‰ˆæ ¡è¯‘者： 钟宇 TripleX Chung <xxx.phy@gmail.com>
- é™ˆç¦ Maggie Chen <chenqi@beyondsoft.com>
- çŽ‹èª Wang Cong <xiyou.wangcong@gmail.com>
-
-以下为æ£æ–‡
----------------------------------------------------------------------
+ 英文版维护者： Greg Kroah-Hartman <greg@kroah.com>
+ ä¸æ–‡ç‰ˆç»´æŠ¤è€…： æŽé˜³ Li Yang <leoyang.li@nxp.com>
+ ä¸æ–‡ç‰ˆç¿»è¯‘者： æŽé˜³ Li Yang <leoyang.li@nxp.com>
+ 时奎亮 Alex Shi <alex.shi@linux.alibaba.com>
+ ä¸æ–‡ç‰ˆæ ¡è¯‘者:
+ 钟宇 TripleX Chung <xxx.phy@gmail.com>
+ é™ˆç¦ Maggie Chen <chenqi@beyondsoft.com>
+ çŽ‹èª Wang Cong <xiyou.wangcong@gmail.com>
如何å‚与Linuxå†…æ ¸å¼€å‘
----------------------
+=====================
这是一篇将如何å‚与Linuxå†…æ ¸å¼€å‘的相关问题一网打尽的终æžç§˜ç¬ˆã€‚它将指导ä½
æˆä¸ºä¸€åLinuxå†…æ ¸å¼€å‘者，并且å¦ä¼šå¦‚何åŒLinuxå†…æ ¸å¼€å‘社区åˆä½œã€‚它尽å¯èƒ½ä¸
@@ -47,6 +37,7 @@ Linuxå†…æ ¸å¤§éƒ¨åˆ†æ˜¯ç”±Cè¯è¨€å†™æˆçš„，一些体系结构相关的代ç
å‚ä¸Žå†…æ ¸å¼€å‘ï¼Œä½ å¿…é¡»ç²¾é€šCè¯è¨€ã€‚除éžä½ 想为æŸä¸ªæž¶æž„å¼€å‘底层代ç ，å¦åˆ™ä½ 并
ä¸éœ€è¦äº†è§£ï¼ˆä»»ä½•ä½“系结构的）汇编è¯è¨€ã€‚下é¢åˆ—举的书ç±è™½ç„¶ä¸èƒ½æ›¿ä»£æ‰Žå®žçš„C
è¯è¨€æ•™è‚²å’Œå¤šå¹´çš„å¼€å‘ç»éªŒï¼Œä½†å¦‚果需è¦çš„è¯ï¼Œåšä¸ºå‚考还是ä¸é”™çš„：
+
- "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
《C程åºè®¾è®¡è¯è¨€ï¼ˆç¬¬2版·新版）》（å¾å®æ–‡ æŽå¿— 译）[机械工业出版社]
- "Practical C Programming" by Steve Oualline [O'Reilly]
@@ -71,9 +62,11 @@ Linuxå†…æ ¸ä½¿ç”¨GNU Cå’ŒGNU工具链开å‘。虽然它éµå¾ªISO C89æ ‡å‡†ï¼Œä½†
--------
Linuxå†…æ ¸æºä»£ç 都是在GPL（通用公共许å¯è¯ï¼‰çš„ä¿æŠ¤ä¸‹å‘布的。è¦äº†è§£è¿™ç§è®¸å¯
-的细节请查看æºä»£ç 主目录下的COPYINGæ–‡ä»¶ã€‚å¦‚æžœä½ å¯¹å®ƒè¿˜æœ‰æ›´æ·±å…¥é—®é¢˜è¯·è”ç³»
-律师，而ä¸è¦åœ¨Linuxå†…æ ¸é‚®ä»¶ç»„ä¸Šæé—®ã€‚å› ä¸ºé‚®ä»¶ç»„é‡Œçš„äººå¹¶ä¸æ˜¯å¾‹å¸ˆï¼Œä¸è¦æœŸ
-望他们的è¯æœ‰æ³•å¾‹æ•ˆåŠ›ã€‚
+的细节请查看æºä»£ç 主目录下的COPYING文件。Linuxå†…æ ¸è®¸å¯å‡†åˆ™å’Œå¦‚何使用
+`SPDX <https://spdx.org/>` æ ‡å¿—ç¬¦è¯´æ˜Žåœ¨è¿™ä¸ªæ–‡ä»¶ä¸
+:ref:`Documentation/translations/zh_CN/process/license-rules.rst <cn_kernel_licensing>`
+å¦‚æžœä½ å¯¹å®ƒè¿˜æœ‰æ›´æ·±å…¥é—®é¢˜è¯·è”系律师，而ä¸è¦åœ¨Linuxå†…æ ¸é‚®ä»¶ç»„ä¸Šæé—®ã€‚å› ä¸º
+邮件组里的人并ä¸æ˜¯å¾‹å¸ˆï¼Œä¸è¦æœŸæœ›ä»–们的è¯æœ‰æ³•å¾‹æ•ˆåŠ›ã€‚
对于GPL的常è§é—®é¢˜å’Œè§£ç”，请访问以下链接：
http://www.gnu.org/licenses/gpl-faq.html
@@ -89,65 +82,75 @@ Linuxå†…æ ¸ä»£ç ä¸åŒ…å«æœ‰å¤§é‡çš„文档。这些文档对于å¦ä¹ 如何与
的维护者解释这些å˜åŒ–。
ä»¥ä¸‹æ˜¯å†…æ ¸ä»£ç ä¸éœ€è¦é˜…读的文档：
- README
+ :ref:`Documentation/admin-guide/README.rst <readme>`
文件简è¦ä»‹ç»äº†Linuxå†…æ ¸çš„èƒŒæ™¯ï¼Œå¹¶ä¸”æ述了如何é…ç½®å’Œç¼–è¯‘å†…æ ¸ã€‚å†…æ ¸çš„
新用户应该从这里开始。
- Documentation/process/changes.rst
+
+ :ref:`Documentation/process/changes.rst <changes>`
文件给出了用æ¥ç¼–è¯‘å’Œä½¿ç”¨å†…æ ¸æ‰€éœ€è¦çš„最å°è½¯ä»¶åŒ…列表。
- Documentation/process/coding-style.rst
+ :ref:`Documentation/translations/zh_CN/process/coding-style.rst <cn_codingstyle>`
æè¿°Linuxå†…æ ¸çš„ä»£ç é£Žæ ¼å’Œç†ç”±ã€‚所有新代ç 需è¦éµå®ˆè¿™ç¯‡æ–‡æ¡£ä¸å®šä¹‰çš„规
范。大多数维护者åªä¼šæŽ¥æ”¶ç¬¦åˆè§„定的补ä¸ï¼Œå¾ˆå¤šäººä¹Ÿåªä¼šå¸®å¿™æ£€æŸ¥ç¬¦åˆé£Žæ ¼
的代ç 。
- Documentation/process/submitting-patches.rst
- Documentation/process/submitting-drivers.rst
+ :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
+ :ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>`
+
这两份文档明确æ述如何创建和å‘é€è¡¥ä¸ï¼Œå…¶ä¸åŒ…括（但ä¸ä»…é™äºŽ)：
- 邮件内容
- é‚®ä»¶æ ¼å¼
- 选择收件人
+
éµå®ˆè¿™äº›è§„定并ä¸èƒ½ä¿è¯æ交æˆåŠŸï¼ˆå› 为所有补ä¸éœ€è¦é€šè¿‡ä¸¥æ ¼çš„å†…å®¹å’Œé£Žæ ¼
å®¡æŸ¥ï¼‰ï¼Œä½†æ˜¯å¿½è§†ä»–ä»¬å‡ ä¹Žå°±æ„味ç€å¤±è´¥ã€‚
其他关于如何æ£ç¡®åœ°ç”Ÿæˆè¡¥ä¸çš„优秀文档包括：
"The Perfect Patch"
+
http://www.ozlabs.org/~akpm/stuff/tpp.txt
+
"Linux kernel patch submission format"
+
http://linux.yyz.us/patch-format.html
- Documentation/process/stable-api-nonsense.rst
+ :ref:`Documentation/translations/zh_CN/process/stable-api-nonsense.rst <cn_stable_api_nonsense>`
论è¯å†…æ ¸ä¸ºä»€ä¹ˆç‰¹æ„ä¸åŒ…æ‹¬ç¨³å®šçš„å†…æ ¸å†…éƒ¨API，也就是说ä¸åŒ…括åƒè¿™æ ·çš„特
性：
+
- å系统ä¸é—´å±‚（为了兼容性？）
- 在ä¸åŒæ“作系统间易于移æ¤çš„驱动程åº
- å‡ç¼“（甚至阻æ¢ï¼‰å†…æ ¸ä»£ç 的快速å˜åŒ–
+
这篇文档对于ç†è§£Linuxçš„å¼€å‘哲å¦è‡³å…³é‡è¦ã€‚对于将开å‘å¹³å°ä»Žå…¶ä»–æ“作系
统转移到Linux的人æ¥è¯´ä¹Ÿå¾ˆé‡è¦ã€‚
- Documentation/admin-guide/security-bugs.rst
+ :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
å¦‚æžœä½ è®¤ä¸ºè‡ªå·±å‘现了Linuxå†…æ ¸çš„å®‰å…¨æ€§é—®é¢˜ï¼Œè¯·æ ¹æ®è¿™ç¯‡æ–‡æ¡£ä¸çš„æ¥éª¤æ¥
æé†’å…¶ä»–å†…æ ¸å¼€å‘者并帮助解决这个问题。
- Documentation/process/management-style.rst
+ :ref:`Documentation/translations/zh_CN/process/management-style.rst <cn_managementstyle>`
+
æè¿°å†…æ ¸ç»´æŠ¤è€…çš„å·¥ä½œæ–¹æ³•åŠå…¶å…±æœ‰ç‰¹ç‚¹ã€‚è¿™å¯¹äºŽåˆšåˆšæŽ¥è§¦å†…æ ¸å¼€å‘（或者对
它感到好奇）的人æ¥è¯´å¾ˆé‡è¦ï¼Œå› ä¸ºå®ƒè§£é‡Šäº†å¾ˆå¤šå¯¹äºŽå†…æ ¸ç»´æŠ¤è€…ç‹¬ç‰¹è¡Œä¸ºçš„
æ™®é误解与迷惑。
- Documentation/process/stable-kernel-rules.rst
+ :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
è§£é‡Šäº†ç¨³å®šç‰ˆå†…æ ¸å‘布的规则，以åŠå¦‚何将改动放入这些版本的æ¥éª¤ã€‚
- Documentation/process/kernel-docs.rst
+ :ref:`Documentation/process/kernel-docs.rst <kernel_docs>`
æœ‰åŠ©äºŽå†…æ ¸å¼€å‘çš„å¤–éƒ¨æ–‡æ¡£åˆ—è¡¨ã€‚å¦‚æžœä½ åœ¨å†…æ ¸è‡ªå¸¦çš„æ–‡æ¡£ä¸æ²¡æœ‰æ‰¾åˆ°ä½ 想找
的内容，å¯ä»¥æŸ¥çœ‹è¿™äº›æ–‡æ¡£ã€‚
- Documentation/process/applying-patches.rst
+ :ref:`Documentation/process/applying-patches.rst <applying_patches>`
关于补ä¸æ˜¯ä»€ä¹ˆä»¥åŠå¦‚何将它打在ä¸åŒå†…æ ¸å¼€å‘分支上的好介ç»
å†…æ ¸è¿˜æ‹¥æœ‰å¤§é‡ä»Žä»£ç 自动生æˆçš„文档。它包å«å†…æ ¸å†…éƒ¨APIçš„å…¨é¢ä»‹ç»ä»¥åŠå¦‚何
妥善处ç†åŠ é”的规则。生æˆçš„文档会放在 Documentation/DocBook/目录下。在内
æ ¸æºç 的主目录ä¸ä½¿ç”¨ä»¥ä¸‹ä¸åŒå‘½ä»¤å°†ä¼šåˆ†åˆ«ç”ŸæˆPDFã€Postscriptã€HTML和手册
-页ç‰ä¸åŒæ ¼å¼çš„文档：
+页ç‰ä¸åŒæ ¼å¼çš„文档::
+
make pdfdocs
make htmldocs
@@ -155,7 +158,9 @@ Linuxå†…æ ¸ä»£ç ä¸åŒ…å«æœ‰å¤§é‡çš„文档。这些文档对于å¦ä¹ 如何与
如何æˆä¸ºå†…æ ¸å¼€å‘者
------------------
å¦‚æžœä½ å¯¹Linuxå†…æ ¸å¼€å‘ä¸€æ— æ‰€çŸ¥ï¼Œä½ åº”è¯¥è®¿é—®â€œLinuxå†…æ ¸æ–°æ‰‹â€è®¡åˆ’：
+
http://kernelnewbies.org
+
它拥有一个å¯ä»¥é—®å„ç§æœ€åŸºæœ¬çš„å†…æ ¸å¼€å‘问题的邮件列表（在æ问之å‰ä¸€å®šè¦è®°å¾—
查找已往的邮件，确认是å¦æœ‰äººå·²ç»å›žç”过相åŒçš„问题）。它还拥有一个å¯ä»¥èŽ·å¾—
实时å馈的IRCèŠå¤©é¢‘é“，以åŠå¤§é‡å¯¹äºŽå¦ä¹ Linuxå†…æ ¸å¼€å‘相当有帮助的文档。
@@ -166,23 +171,21 @@ Linuxå†…æ ¸ä»£ç ä¸åŒ…å«æœ‰å¤§é‡çš„文档。这些文档对于å¦ä¹ 如何与
å¦‚æžœä½ æƒ³åŠ å…¥å†…æ ¸å¼€å‘社区并å助完æˆä¸€äº›ä»»åŠ¡ï¼Œå´æ‰¾ä¸åˆ°ä»Žå“ªé‡Œå¼€å§‹ï¼Œå¯ä»¥è®¿é—®
“Linuxå†…æ ¸æˆ¿ç®¡å‘˜â€è®¡åˆ’：
+
http://kernelnewbies.org/KernelJanitors
+
这是æžä½³çš„起点。它æ供一个相对简å•çš„ä»»åŠ¡åˆ—è¡¨ï¼Œåˆ—å‡ºå†…æ ¸ä»£ç ä¸éœ€è¦è¢«é‡æ–°
æ•´ç†æˆ–者改æ£çš„地方。通过和负责这个计划的开å‘者们一åŒå·¥ä½œï¼Œä½ 会å¦åˆ°å°†è¡¥ä¸
集æˆè¿›å†…æ ¸çš„åŸºæœ¬åŽŸç†ã€‚如果还没有决定下一æ¥è¦åšä»€ä¹ˆçš„è¯ï¼Œä½ 还å¯èƒ½ä¼šå¾—到方
å‘性的指点。
-å¦‚æžœä½ å·²ç»æœ‰ä¸€äº›çŽ°æˆçš„代ç 想è¦æ”¾åˆ°å†…æ ¸ä¸ï¼Œä½†æ˜¯éœ€è¦ä¸€äº›å¸®åŠ©æ¥ä½¿å®ƒä»¬æ‹¥æœ‰æ£
-ç¡®çš„æ ¼å¼ã€‚è¯·è®¿é—®â€œå†…æ ¸å¯¼å¸ˆâ€è®¡åˆ’。这个计划就是用æ¥å¸®åŠ©ä½ 完æˆè¿™ä¸ªç›®æ ‡çš„。它
-是一个邮件列表，地å€å¦‚下：
- http://selenic.com/mailman/listinfo/kernel-mentors
-
在真æ£åŠ¨æ‰‹ä¿®æ”¹å†…æ ¸ä»£ç 之å‰ï¼Œç†è§£è¦ä¿®æ”¹çš„代ç 如何è¿ä½œæ˜¯å¿…需的。è¦è¾¾åˆ°è¿™ä¸ª
目的，没什么办法比直接读代ç 更有效了（大多数花招都会有相应的注释），而且
一些特制的工具还å¯ä»¥æ供帮助。例如，“Linux代ç 交å‰å¼•ç”¨â€é¡¹ç›®å°±æ˜¯ä¸€ä¸ªå€¼å¾—
特别推è的帮助工具，它将æºä»£ç 显示在有编目和索引的网页上。其ä¸ä¸€ä¸ªæ›´æ–°åŠ
æ—¶çš„å†…æ ¸æºç 库，å¯ä»¥é€šè¿‡ä»¥ä¸‹åœ°å€è®¿é—®ï¼š
- http://sosdg.org/~coywolf/lxr/
+
+ https://elixir.bootlin.com/
å¼€å‘æµç¨‹
@@ -190,22 +193,23 @@ Linuxå†…æ ¸ä»£ç ä¸åŒ…å«æœ‰å¤§é‡çš„文档。这些文档对于å¦ä¹ 如何与
ç›®å‰Linuxå†…æ ¸å¼€å‘æµç¨‹åŒ…æ‹¬å‡ ä¸ªâ€œä¸»å†…æ ¸åˆ†æ”¯â€å’Œå¾ˆå¤šåç³»ç»Ÿç›¸å…³çš„å†…æ ¸åˆ†æ”¯ã€‚è¿™
些分支包括：
- - 2.6.xä¸»å†…æ ¸æºç æ ‘
- - 2.6.x.y -stableå†…æ ¸æºç æ ‘
- - 2.6.x -mmå†…æ ¸è¡¥ä¸é›†
- - åç³»ç»Ÿç›¸å…³çš„å†…æ ¸æºç æ ‘å’Œè¡¥ä¸é›†
+ - Linus çš„å†…æ ¸æºç æ ‘
+ - 多个主è¦ç‰ˆæœ¬çš„ç¨³å®šç‰ˆå†…æ ¸æ ‘
+ - åç³»ç»Ÿç›¸å…³çš„å†…æ ¸æ ‘
+ - linux-next 集æˆæµ‹è¯•æ ‘
+
+
+ä¸»çº¿æ ‘
+------
+ä¸»çº¿æ ‘æ˜¯ç”±Linus Torvalds ç»´æŠ¤çš„ã€‚ä½ å¯ä»¥åœ¨https://kernel.org 网站或者代ç
+库ä¸ä¸‹æ‰¾åˆ°å®ƒã€‚它的开å‘éµå¾ªä»¥ä¸‹æ¥éª¤ï¼š
-2.6.xå†…æ ¸ä¸»æºç æ ‘
------------------
-2.6.xå†…æ ¸æ˜¯ç”±Linus Torvalds（Linuxçš„åˆ›é€ è€…ï¼‰äº²è‡ªç»´æŠ¤çš„ã€‚ä½ å¯ä»¥åœ¨
-kernel.org网站的pub/linux/kernel/v2.6/目录下找到它。它的开å‘éµå¾ªä»¥ä¸‹æ¥
-骤：
- æ¯å½“ä¸€ä¸ªæ–°ç‰ˆæœ¬çš„å†…æ ¸è¢«å‘布，为期两周的集æˆçª—å£å°†è¢«æ‰“开。在这段时间里
维护者å¯ä»¥å‘Linusæ交大段的修改，通常这些修改已ç»è¢«æ”¾åˆ°-mmå†…æ ¸ä¸å‡ 个
星期了。æ交大é‡ä¿®æ”¹çš„首选方å¼æ˜¯ä½¿ç”¨gitå·¥å…·ï¼ˆå†…æ ¸çš„ä»£ç 版本管ç†å·¥å…·
- ，更多的信æ¯å¯ä»¥åœ¨http://git-scm.com/获å–），ä¸è¿‡ä½¿ç”¨æ™®é€šè¡¥ä¸ä¹Ÿæ˜¯å¯ä»¥
- 的。
+ ，更多的信æ¯å¯ä»¥åœ¨ http://git-scm.com/ 获å–），ä¸è¿‡ä½¿ç”¨æ™®é€šè¡¥ä¸ä¹Ÿæ˜¯
+ å¯ä»¥çš„。
- 两个星期以åŽ-rc1ç‰ˆæœ¬å†…æ ¸å‘布。之åŽåªæœ‰ä¸åŒ…å«å¯èƒ½å½±å“æ•´ä¸ªå†…æ ¸ç¨³å®šæ€§çš„
新功能的补ä¸æ‰å¯èƒ½è¢«æŽ¥å—。请注æ„一个全新的驱动程åºï¼ˆæˆ–者文件系统）有
å¯èƒ½åœ¨-rc1åŽè¢«æŽ¥å—æ˜¯å› ä¸ºè¿™æ ·çš„ä¿®æ”¹å®Œå…¨ç‹¬ç«‹ï¼Œä¸ä¼šå½±å“其他的代ç ，所以
@@ -220,106 +224,61 @@ kernel.org网站的pub/linux/kernel/v2.6/目录下找到它。它的开å‘éµå¾ª
“没有人知é“æ–°å†…æ ¸ä½•æ—¶ä¼šè¢«å‘å¸ƒï¼Œå› ä¸ºå‘å¸ƒæ˜¯æ ¹æ®å·²çŸ¥bug的情况æ¥å†³å®š
的，而ä¸æ˜¯æ ¹æ®ä¸€ä¸ªäº‹å…ˆåˆ¶å®šå¥½çš„时间表。â€
+åç³»ç»Ÿç‰¹å®šæ ‘
+------------
-2.6.x.y -stableï¼ˆç¨³å®šç‰ˆï¼‰å†…æ ¸æºç æ ‘
------------------------------------
-ç”±4个数å—组æˆçš„å†…æ ¸ç‰ˆæœ¬å·è¯´æ˜Žæ¤å†…æ ¸æ˜¯-stable版本。它们包å«åŸºäºŽ2.6.x版本
-å†…æ ¸çš„ç›¸å¯¹è¾ƒå°ä¸”至关é‡è¦çš„修补，这些修补针对安全性问题或者严é‡çš„å†…æ ¸é€€æ¥ã€‚
-
-è¿™ç§ç‰ˆæœ¬çš„å†…æ ¸é€‚ç”¨äºŽé‚£äº›æœŸæœ›èŽ·å¾—æœ€æ–°çš„ç¨³å®šç‰ˆå†…æ ¸å¹¶ä¸”ä¸æƒ³å‚与测试开å‘版或
-者实验版的用户。
-
-如果没有2.6.x.yç‰ˆæœ¬å†…æ ¸å˜åœ¨ï¼Œé‚£ä¹ˆæœ€æ–°çš„2.6.xç‰ˆæœ¬å†…æ ¸å°±ç›¸å½“äºŽæ˜¯å½“å‰çš„稳定
-ç‰ˆå†…æ ¸ã€‚
-
-2.6.x.y版本由“稳定版â€å°ç»„（邮件地å€<stable@vger.kernel.org>）维护，一般隔周å‘
-布新版本。
-
-å†…æ ¸æºç ä¸çš„Documentation/process/stable-kernel-rules.rst文件具体æ述了å¯è¢«ç¨³å®š
-ç‰ˆå†…æ ¸æŽ¥å—的修改类型以åŠå‘布的æµç¨‹ã€‚
+å„ç§å†…æ ¸å系统的维护者——以åŠè®¸å¤šå†…æ ¸å系统开å‘人员——在æºä»£ç 库ä¸å…¬å¼€äº†ä»–们
+当å‰çš„å¼€å‘状æ€ã€‚è¿™æ ·ï¼Œå…¶ä»–äººå°±å¯ä»¥çœ‹åˆ°å†…æ ¸çš„ä¸åŒåŒºåŸŸå‘生了什么。在开å‘速度
+很快的领域，å¯èƒ½ä¼šè¦æ±‚å¼€å‘人员将æäº¤çš„å†…å®¹å»ºç«‹åœ¨è¿™æ ·çš„åç³»ç»Ÿå†…æ ¸æ ‘ä¸Šï¼Œè¿™æ ·
+å°±é¿å…了æ交与其他已ç»è¿›è¡Œçš„工作之间的冲çªã€‚
+这些å˜å‚¨åº“ä¸çš„大多数都是Gitæ ‘ï¼Œä½†æ˜¯ä¹Ÿæœ‰å…¶ä»–çš„scm在使用，或者补ä¸é˜Ÿåˆ—被å‘布
+为Quilt系列。这些å系统å˜å‚¨åº“的地å€åˆ—在MAINTAINERS文件ä¸ã€‚å…¶ä¸è®¸å¤šå¯ä»¥åœ¨
+https://git.kernel.org/上æµè§ˆã€‚
-2.6.x -mmè¡¥ä¸é›†
----------------
-这是由Andrew Mortonç»´æŠ¤çš„è¯•éªŒæ€§å†…æ ¸è¡¥ä¸é›†ã€‚Andrew将所有åç³»ç»Ÿçš„å†…æ ¸æºç
-和补ä¸æ‹¼å‡‘åˆ°ä¸€èµ·ï¼Œå¹¶ä¸”åŠ å…¥äº†å¤§é‡ä»Žlinux-kernel邮件列表ä¸é‡‡é›†çš„è¡¥ä¸ã€‚这个
-æºç æ ‘æ˜¯æ–°åŠŸèƒ½å’Œè¡¥ä¸çš„试炼场。当补ä¸åœ¨-mmè¡¥ä¸é›†é‡Œè¯æ˜Žäº†å…¶ä»·å€¼ä»¥åŽAndrew
-或者相应å系统的维护者会将补ä¸å‘ç»™Linus以便集æˆè¿›ä¸»å†…æ ¸æºç æ ‘ã€‚
+在将一个建议的补ä¸æäº¤åˆ°è¿™æ ·çš„åç³»ç»Ÿæ ‘ä¹‹å‰ï¼Œéœ€è¦å¯¹å®ƒè¿›è¡Œå®¡æŸ¥ï¼Œå®¡æŸ¥ä¸»è¦å‘生
+在邮件列表上（请å‚è§ä¸‹é¢ç›¸åº”çš„éƒ¨åˆ†ï¼‰ã€‚å¯¹äºŽå‡ ä¸ªå†…æ ¸å系统，这个审查过程是通
+过工具补ä¸è·Ÿè¸ªçš„。Patchworkæ供了一个Webç•Œé¢ï¼Œæ˜¾ç¤ºè¡¥ä¸å‘布ã€å¯¹è¡¥ä¸çš„任何评
+论或修订，维护人员å¯ä»¥å°†è¡¥ä¸æ ‡è®°ä¸ºæ£åœ¨å®¡æŸ¥ã€æŽ¥å—或拒ç»ã€‚大多数补ä¸ç½‘站都列
+在 https://patchwork.kernel.org/
-在将所有新补ä¸å‘ç»™Linus以集æˆåˆ°ä¸»å†…æ ¸æºç æ ‘ä¹‹å‰ï¼Œæˆ‘们éžå¸¸é¼“励先把这些补
-ä¸æ”¾åœ¨-mmç‰ˆå†…æ ¸æºç æ ‘ä¸è¿›è¡Œæµ‹è¯•ã€‚
-
-è¿™äº›å†…æ ¸ç‰ˆæœ¬ä¸é€‚åˆåœ¨éœ€è¦ç¨³å®šè¿è¡Œçš„系统上è¿è¡Œï¼Œå› 为è¿è¡Œå®ƒä»¬æ¯”è¿è¡Œä»»ä½•å…¶ä»–
-å†…æ ¸åˆ†æ”¯éƒ½æ›´å…·æœ‰é£Žé™©ã€‚
-
-å¦‚æžœä½ æƒ³ä¸ºå†…æ ¸å¼€å‘进程æ供帮助，请å°è¯•å¹¶ä½¿ç”¨è¿™äº›å†…æ ¸ç‰ˆæœ¬ï¼Œå¹¶åœ¨
-linux-kernel邮件列表ä¸æä¾›åé¦ˆï¼Œå‘Šè¯‰å¤§å®¶ä½ é‡åˆ°äº†é—®é¢˜è¿˜æ˜¯ä¸€åˆ‡æ£å¸¸ã€‚
-
-通常-mm版补ä¸é›†ä¸å…‰åŒ…括这些é¢å¤–的试验性补ä¸ï¼Œè¿˜åŒ…括å‘布时-git版主æºç æ ‘
-ä¸çš„改动。
-
--mmç‰ˆå†…æ ¸æ²¡æœ‰å›ºå®šçš„å‘布周期，但是通常在æ¯ä¸¤ä¸ª-rcç‰ˆå†…æ ¸å‘布之间都会有若干
-个-mmç‰ˆå†…æ ¸å‘布（一般是1至3个）。
-
-
-åç³»ç»Ÿç›¸å…³å†…æ ¸æºç æ ‘å’Œè¡¥ä¸é›†
-----------------------------
-ç›¸å½“ä¸€éƒ¨åˆ†å†…æ ¸å系统开å‘者会公开他们自己的开å‘æºç æ ‘ï¼Œä»¥ä¾¿å…¶ä»–äººèƒ½äº†è§£å†…
-æ ¸çš„ä¸åŒé¢†åŸŸæ£åœ¨å‘生的事情。如上所述，这些æºç æ ‘ä¼šè¢«é›†æˆåˆ°-mmç‰ˆæœ¬å†…æ ¸ä¸ã€‚
-
-下é¢æ˜¯ç›®å‰å¯ç”¨çš„ä¸€äº›å†…æ ¸æºç æ ‘çš„åˆ—è¡¨ï¼š
- 通过git管ç†çš„æºç æ ‘ï¼š
- - Kbuildå¼€å‘æºç æ ‘ï¼Œ Sam Ravnborg <sam@ravnborg.org>
- git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git
-
- - ACPIå¼€å‘æºç æ ‘, Len Brown <len.brown@intel.com>
- git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
-
- - å—设备开å‘æºç æ ‘, Jens Axboe <axboe@suse.de>
- git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
-
- - DRMå¼€å‘æºç æ ‘, Dave Airlie <airlied@linux.ie>
- git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
-
- - ia64å¼€å‘æºç æ ‘, Tony Luck <tony.luck@intel.com>
- git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
+Linux-next 集æˆæµ‹è¯•æ ‘
+---------------------
- - ieee1394å¼€å‘æºç æ ‘, Jody McIntyre <scjody@modernduck.com>
- git.kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394.git
+在将åç³»ç»Ÿæ ‘çš„æ›´æ–°åˆå¹¶åˆ°ä¸»çº¿æ ‘之å‰ï¼Œéœ€è¦å¯¹å®ƒä»¬è¿›è¡Œé›†æˆæµ‹è¯•ã€‚为æ¤ï¼Œå˜åœ¨ä¸€ä¸ª
+特殊的测试å˜å‚¨åº“，其ä¸å‡ 乎æ¯å¤©éƒ½ä¼šæå–所有åç³»ç»Ÿæ ‘ï¼š
- - infinibandå¼€å‘æºç æ ‘, Roland Dreier <rolandd@cisco.com>
- git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
+ https://git.kernel.org/？p=linux/kernel/git/next/linux-next.git
- - libataå¼€å‘æºç æ ‘, Jeff Garzik <jgarzik@pobox.com>
- git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
+通过这ç§æ–¹å¼ï¼ŒLinux-next 对下一个åˆå¹¶é˜¶æ®µå°†è¿›å…¥ä¸»çº¿å†…æ ¸çš„å†…å®¹ç»™å‡ºäº†ä¸€ä¸ªæ¦‚è¦
+展望。éžå¸¸æ¬¢å†’险的测试者è¿è¡Œæµ‹è¯•Linux-next。
- - 网络驱动程åºå¼€å‘æºç æ ‘, Jeff Garzik <jgarzik@pobox.com>
- git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
+多个主è¦ç‰ˆæœ¬çš„ç¨³å®šç‰ˆå†…æ ¸æ ‘
+-----------------------------------
+ç”±3个数å—组æˆçš„å†…æ ¸ç‰ˆæœ¬å·è¯´æ˜Žæ¤å†…æ ¸æ˜¯-stable版本。它们包å«å†…æ ¸çš„ç›¸å¯¹è¾ƒå°ä¸”
+至关é‡è¦çš„修补，这些修补针对安全性问题或者严é‡çš„å†…æ ¸é€€æ¥ã€‚
- - pcmciaå¼€å‘æºç æ ‘, Dominik Brodowski <linux@dominikbrodowski.net>
- git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
+è¿™ç§ç‰ˆæœ¬çš„å†…æ ¸é€‚ç”¨äºŽé‚£äº›æœŸæœ›èŽ·å¾—æœ€æ–°çš„ç¨³å®šç‰ˆå†…æ ¸å¹¶ä¸”ä¸æƒ³å‚与测试开å‘版或
+者实验版的用户。
- - SCSIå¼€å‘æºç æ ‘, James Bottomley <James.Bottomley@SteelEye.com>
- git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
+ç¨³å®šç‰ˆå†…æ ¸æ ‘ç‰ˆæœ¬ç”±â€œç¨³å®šç‰ˆâ€å°ç»„（邮件地å€<stable@vger.kernel.org>）维护，一般
+隔周å‘布新版本。
- 使用quilt管ç†çš„è¡¥ä¸é›†ï¼š
- - USB, PCI, 驱动程åºæ ¸å¿ƒå’ŒI2C, Greg Kroah-Hartman <gregkh@linuxfoundation.org>
- kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
- - x86-64, 部分i386, Andi Kleen <ak@suse.de>
- ftp.firstfloor.org:/pub/ak/x86_64/quilt/
+å†…æ ¸æºç ä¸çš„ :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
+文件具体æ述了å¯è¢«ç¨³å®šç‰ˆå†…æ ¸æŽ¥å—的修改类型以åŠå‘布的æµç¨‹ã€‚
- å…¶ä»–å†…æ ¸æºç æ ‘å¯ä»¥åœ¨http://git.kernel.org的列表ä¸å’ŒMAINTAINERS文件里
- 找到。
报告bug
-------
bugzilla.kernel.org是Linuxå†…æ ¸å¼€å‘者们用æ¥è·Ÿè¸ªå†…æ ¸Bug的网站。我们鼓励用
户在这个工具ä¸æŠ¥å‘Šæ‰¾åˆ°çš„所有bugã€‚å¦‚ä½•ä½¿ç”¨å†…æ ¸bugzilla的细节请访问：
+
http://test.kernel.org/bugzilla/faq.html
-å†…æ ¸æºç 主目录ä¸çš„admin-guide/reporting-bugs.rst文件里有一个很好的模æ¿ã€‚它指导用户如何报
-å‘Šå¯èƒ½çš„å†…æ ¸bug以åŠéœ€è¦æ供哪些信æ¯æ¥å¸®åŠ©å†…æ ¸å¼€å‘è€…ä»¬æ‰¾åˆ°é—®é¢˜çš„æ ¹æºã€‚
+å†…æ ¸æºç 主目录ä¸çš„:ref:`admin-guide/reporting-bugs.rst <reportingbugs>`
+文件里有一个很好的模æ¿ã€‚它指导用户如何报告å¯èƒ½çš„å†…æ ¸bug以åŠéœ€è¦æ供哪些信æ¯
+æ¥å¸®åŠ©å†…æ ¸å¼€å‘è€…ä»¬æ‰¾åˆ°é—®é¢˜çš„æ ¹æºã€‚
利用bug报告
@@ -330,12 +289,7 @@ bugzilla.kernel.org是Linuxå†…æ ¸å¼€å‘者们用æ¥è·Ÿè¸ªå†…æ ¸Bug的网站。
者感å—åˆ°ä½ çš„å˜åœ¨ã€‚修改bug是赢得其他开å‘è€…èµžèª‰çš„æœ€å¥½åŠžæ³•ï¼Œå› ä¸ºå¹¶ä¸æ˜¯å¾ˆå¤š
人都喜欢浪费时间去修改别人报告的bug。
-è¦å°è¯•ä¿®æ”¹å·²çŸ¥çš„bug，请访问http://bugzilla.kernel.org网å€ã€‚å¦‚æžœä½ æƒ³èŽ·å¾—
-最新bug的通知，å¯ä»¥è®¢é˜…bugme-new邮件列表（åªæœ‰æ–°çš„bug报告会被寄到这里）
-或者订阅bugme-janitor邮件列表（所有bugzillaçš„å˜åŠ¨éƒ½ä¼šè¢«å¯„到这里）。
-
- https://lists.linux-foundation.org/mailman/listinfo/bugme-new
- https://lists.linux-foundation.org/mailman/listinfo/bugme-janitors
+è¦å°è¯•ä¿®æ”¹å·²çŸ¥çš„bug，请访问 http://bugzilla.kernel.org 网å€ã€‚
邮件列表
@@ -343,10 +297,14 @@ bugzilla.kernel.org是Linuxå†…æ ¸å¼€å‘者们用æ¥è·Ÿè¸ªå†…æ ¸Bug的网站。
æ£å¦‚上é¢çš„文档所æè¿°ï¼Œå¤§å¤šæ•°çš„éª¨å¹²å†…æ ¸å¼€å‘è€…éƒ½åŠ å…¥äº†Linux Kernel邮件列
表。如何订阅和退订列表的细节å¯ä»¥åœ¨è¿™é‡Œæ‰¾åˆ°ï¼š
+
http://vger.kernel.org/vger-lists.html#linux-kernel
+
网上很多地方都有这个邮件列表的å˜æ¡£(archive)。å¯ä»¥ä½¿ç”¨æœç´¢å¼•æ“Žæ¥æ‰¾åˆ°è¿™äº›
å˜æ¡£ã€‚比如：
+
http://dir.gmane.org/gmane.linux.kernel
+
在å‘信之å‰ï¼Œæˆ‘ä»¬å¼ºçƒˆå»ºè®®ä½ å…ˆåœ¨å˜æ¡£ä¸æœç´¢ä½ 想è¦è®¨è®ºçš„问题。很多已ç»è¢«è¯¦ç»†
讨论过的问题åªåœ¨é‚®ä»¶åˆ—表的å˜æ¡£ä¸å¯ä»¥æ‰¾åˆ°ã€‚
@@ -354,10 +312,12 @@ bugzilla.kernel.org是Linuxå†…æ ¸å¼€å‘者们用æ¥è·Ÿè¸ªå†…æ ¸Bug的网站。
MAINTAINERS文件ä¸å¯ä»¥æ‰¾åˆ°ä¸åŒè¯é¢˜å¯¹åº”的邮件列表。
很多邮件列表架设在kernel.orgæœåŠ¡å™¨ä¸Šã€‚这些列表的信æ¯å¯ä»¥åœ¨è¿™é‡Œæ‰¾åˆ°ï¼š
+
http://vger.kernel.org/vger-lists.html
在使用这些邮件列表时，请记ä½ä¿æŒè‰¯å¥½çš„è¡Œä¸ºä¹ æƒ¯ã€‚ä¸‹é¢çš„链接æ供了与这些列
表（或任何其它邮件列表）交æµçš„一些简å•è§„则，虽然内容有点滥竽充数。
+
http://www.albion.com/netiquette/
当有很多人回å¤ä½ 的邮件时，邮件的抄é€åˆ—表会å˜å¾—很长。请ä¸è¦å°†ä»»ä½•äººä»ŽæŠ„é€
@@ -369,11 +329,12 @@ MAINTAINERS文件ä¸å¯ä»¥æ‰¾åˆ°ä¸åŒè¯é¢˜å¯¹åº”的邮件列表。
è¿™å‡ è¡Œã€‚å°†ä½ çš„è¯„è®ºåŠ åœ¨è¢«å¼•ç”¨çš„æ®µè½ä¹‹é—´è€Œä¸è¦æ”¾åœ¨é‚®ä»¶çš„顶部。
å¦‚æžœä½ åœ¨é‚®ä»¶ä¸é™„带补ä¸ï¼Œè¯·ç¡®è®¤å®ƒä»¬æ˜¯å¯ä»¥ç›´æŽ¥é˜…读的纯文本（如
-Documentation/process/submitting-patches.rst文档ä¸æ‰€è¿°ï¼‰ã€‚å†…æ ¸å¼€å‘者们ä¸å¸Œæœ›é‡åˆ°é™„件
-或者被压缩了的补ä¸ã€‚åªæœ‰è¿™æ ·æ‰èƒ½ä¿è¯ä»–们å¯ä»¥ç›´æŽ¥è¯„è®ºä½ çš„æ¯è¡Œä»£ç 。请确ä¿
-ä½ ä½¿ç”¨çš„é‚®ä»¶å‘é€ç¨‹åºä¸ä¼šä¿®æ”¹ç©ºæ ¼å’Œåˆ¶è¡¨ç¬¦ã€‚一个防范性的测试方法是先将邮件
-å‘é€ç»™è‡ªå·±ï¼Œç„¶åŽè‡ªå·±å°è¯•æ˜¯å¦å¯ä»¥é¡ºåˆ©åœ°æ‰“上收到的补ä¸ã€‚如果测试ä¸æˆåŠŸï¼Œè¯·
-调整或者更æ¢ä½ 的邮件å‘é€ç¨‹åºç›´åˆ°å®ƒæ£ç¡®å·¥ä½œä¸ºæ¢ã€‚
+:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
+文档ä¸æ‰€è¿°ï¼‰ã€‚å†…æ ¸å¼€å‘者们ä¸å¸Œæœ›é‡åˆ°é™„件或者被压缩了的补ä¸ã€‚åªæœ‰è¿™æ ·æ‰èƒ½
+ä¿è¯ä»–们å¯ä»¥ç›´æŽ¥è¯„è®ºä½ çš„æ¯è¡Œä»£ç 。请确ä¿ä½ 使用的邮件å‘é€ç¨‹åºä¸ä¼šä¿®æ”¹ç©ºæ ¼
+和制表符。一个防范性的测试方法是先将邮件å‘é€ç»™è‡ªå·±ï¼Œç„¶åŽè‡ªå·±å°è¯•æ˜¯å¦å¯ä»¥
+顺利地打上收到的补ä¸ã€‚如果测试ä¸æˆåŠŸï¼Œè¯·è°ƒæ•´æˆ–者更æ¢ä½ 的邮件å‘é€ç¨‹åºç›´åˆ°
+它æ£ç¡®å·¥ä½œä¸ºæ¢ã€‚
总而言之，请尊é‡å…¶ä»–的邮件列表订阅者。
@@ -383,6 +344,7 @@ Documentation/process/submitting-patches.rst文档ä¸æ‰€è¿°ï¼‰ã€‚å†…æ ¸å¼€å‘者
å†…æ ¸ç¤¾åŒºçš„ç›®æ ‡å°±æ˜¯æä¾›å°½å–„å°½ç¾Žçš„å†…æ ¸ã€‚æ‰€ä»¥å½“ä½ æ交补ä¸æœŸæœ›è¢«æŽ¥å—è¿›å†…æ ¸çš„
时候，它的技术价值以åŠå…¶ä»–æ–¹é¢éƒ½å°†è¢«è¯„å®¡ã€‚é‚£ä¹ˆä½ å¯èƒ½ä¼šå¾—到什么呢？
+
- 批评
- 评论
- è¦æ±‚修改
@@ -395,6 +357,7 @@ Documentation/process/submitting-patches.rst文档ä¸æ‰€è¿°ï¼‰ã€‚å†…æ ¸å¼€å‘者
没在茫茫信海ä¸ã€‚
ä½ ä¸åº”该åšçš„事情：
+
- 期望自己的补ä¸ä¸å—任何质疑就直接被接å—
- 翻脸
- 忽略别人的评论
@@ -414,7 +377,8 @@ Documentation/process/submitting-patches.rst文档ä¸æ‰€è¿°ï¼‰ã€‚å†…æ ¸å¼€å‘者
å†…æ ¸ç¤¾åŒºçš„å·¥ä½œæ¨¡å¼åŒå¤§å¤šæ•°ä¼ 统公å¸å¼€å‘队ä¼çš„工作模å¼å¹¶ä¸ç›¸åŒã€‚下é¢è¿™äº›ä¾‹
å，å¯ä»¥å¸®åŠ©ä½ é¿å…æŸäº›å¯èƒ½å‘生问题：
- 用这些è¯ä»‹ç»ä½ 的修改æ案会有好处：
+用这些è¯ä»‹ç»ä½ 的修改æ案会有好处：
+
- 它åŒæ—¶è§£å†³äº†å¤šä¸ªé—®é¢˜
- å®ƒåˆ é™¤äº†2000行代ç
- 这是补ä¸ï¼Œå®ƒå·²ç»è§£é‡Šäº†æˆ‘想è¦è¯´æ˜Žçš„
@@ -422,7 +386,8 @@ Documentation/process/submitting-patches.rst文档ä¸æ‰€è¿°ï¼‰ã€‚å†…æ ¸å¼€å‘者
- 这是一系列å°è¡¥ä¸ç”¨æ¥â€¦â€¦
- 这个修改æ高了普通机器的性能……
- 应该é¿å…如下的说法：
+应该é¿å…如下的说法：
+
- 我们在AIX/ptx/Solaris就是这么åšçš„，所以这么åšè‚¯å®šæ˜¯å¥½çš„……
- 我åšè¿™è¡Œå·²ç»20年了，所以……
- 为了我们公å¸èµšé’±è€ƒè™‘必须这么åš
@@ -495,6 +460,7 @@ Linuxå†…æ ¸ç¤¾åŒºå¹¶ä¸å–œæ¬¢ä¸€ä¸‹æŽ¥æ”¶å¤§æ®µçš„代ç 。修改需è¦è¢«æ°å½“
å½“ä½ å‘é€è¡¥ä¸çš„时候，需è¦ç‰¹åˆ«ç•™æ„邮件æ£æ–‡çš„å†…å®¹ã€‚å› ä¸ºè¿™é‡Œçš„ä¿¡æ¯å°†ä¼šåšä¸ºè¡¥
ä¸çš„修改记录(ChangeLog)，会被一直ä¿ç•™ä»¥å¤‡å¤§å®¶æŸ¥é˜…。它需è¦å®Œå…¨åœ°æè¿°è¡¥ä¸ï¼Œ
包括：
+
- 为什么需è¦è¿™ä¸ªä¿®æ”¹
- è¡¥ä¸çš„总体设计
- 实现细节
@@ -510,7 +476,8 @@ Linuxå†…æ ¸ç¤¾åŒºå¹¶ä¸å–œæ¬¢ä¸€ä¸‹æŽ¥æ”¶å¤§æ®µçš„代ç 。修改需è¦è¢«æ°å½“
很多人已ç»åšåˆ°äº†ï¼Œè€Œä»–们都曾ç»å’ŒçŽ°åœ¨çš„ä½ ç«™åœ¨åŒæ ·çš„起点上。
----------------
+æ„Ÿè°¢
+----
æ„Ÿè°¢Paolo Ciarrocchiå…许“开å‘æµç¨‹â€éƒ¨åˆ†åŸºäºŽä»–所写的文ç«
(http://www.kerneltravel.net/newbie/2.6-development_process)，感谢Randy
Dunlapå’ŒGerrit Huizenga完善了应该说和ä¸è¯¥è¯´çš„列表。感谢Pat Mochel, Hanna
diff --git a/Documentation/translations/zh_CN/process/index.rst b/Documentation/translations/zh_CN/process/index.rst
new file mode 100644
index 0000000000000000000000000000000000000000..be1e764a80d267c07280cb8c4945209a18eec3b9
--- /dev/null
+++ b/Documentation/translations/zh_CN/process/index.rst
@@ -0,0 +1,60 @@
+.. raw:: latex
+
+ \renewcommand\thesection*
+ \renewcommand\thesubsection*
+
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: :ref:`Documentation/process/index.rst <process_index>`
+:Translator: Alex Shi <alex.shi@linux.alibaba.com>
+
+.. _cn_process_index:
+
+与Linux å†…æ ¸ç¤¾åŒºä¸€èµ·å·¥ä½œ
+========================
+
+é‚£ä¹ˆä½ æƒ³æˆä¸ºLinuxå†…æ ¸å¼€å‘人员？ æ¬¢è¿Žï¼ ä¸ä½†ä»ŽæŠ€æœ¯æ„ä¹‰ä¸Šè®²æœ‰å¾ˆå¤šå…³äºŽå†…æ ¸çš„çŸ¥è¯†
+需è¦å¦ï¼Œè€Œä¸”了解我们社区的工作方å¼ä¹Ÿå¾ˆé‡è¦ã€‚ é˜…è¯»è¿™äº›æ–‡ç« å¯ä»¥è®©æ‚¨ä»¥æ›´è½»æ¾åœ°,
+麻烦最少的方å¼å°†æ›´æ”¹åˆå¹¶åˆ°å†…æ ¸ã€‚
+
+以下是æ¯ä½å¼€å‘人员应阅读的基本指å—。
+
+.. toctree::
+ :maxdepth: 1
+
+ howto
+ code-of-conduct
+ code-of-conduct-interpretation
+ submitting-patches
+ programming-language
+ coding-style
+ development-process
+ email-clients
+ license-rules
+
+其它大多数开å‘人员感兴趣的社区指å—：
+
+
+.. toctree::
+ :maxdepth: 1
+
+ submitting-drivers
+ submit-checklist
+ stable-api-nonsense
+ stable-kernel-rules
+ management-style
+
+这些是一些总体技术指å—，由于缺ä¹æ›´å¥½çš„地方，现在已ç»æ”¾åœ¨è¿™é‡Œ
+
+.. toctree::
+ :maxdepth: 1
+
+ magic-number
+ volatile-considered-harmful
+
+.. only:: subproject and html
+
+ 目录
+ ====
+
+ * :ref:`genindex`
diff --git a/Documentation/translations/zh_CN/process/license-rules.rst b/Documentation/translations/zh_CN/process/license-rules.rst
new file mode 100644
index 0000000000000000000000000000000000000000..30c272b2a292cdb71433f42a331078f0529a1e25
--- /dev/null
+++ b/Documentation/translations/zh_CN/process/license-rules.rst
@@ -0,0 +1,370 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: :ref:`Documentation/process/license-rules.rst <kernel_licensing>`
+:Translator: Alex Shi <alex.shi@linux.alibaba.com>
+
+.. _cn_kernel_licensing:
+
+Linuxå†…æ ¸è®¸å¯è§„则
+=================
+
+Linuxå†…æ ¸æ ¹æ®LICENSES/preferred/GPL-2.0ä¸æ供的GNU通用公共许å¯è¯ç‰ˆæœ¬2
+（GPL-2.0）的æ¡æ¬¾æ供，并在LICENSES/exceptions/Linux-syscall-noteä¸æ˜¾å¼
+æ述了例外的系统调用，如COPYING文件ä¸æ‰€è¿°ã€‚
+
+æ¤æ–‡æ¡£æ–‡ä»¶æ供了如何对æ¯ä¸ªæºæ–‡ä»¶è¿›è¡Œæ³¨é‡Šä»¥ä½¿å…¶è®¸å¯è¯æ¸…晰明确的说明。
+它ä¸ä¼šå–ä»£å†…æ ¸çš„è®¸å¯è¯ã€‚
+
+å†…æ ¸æºä»£ç 作为一个整体适用于COPYING文件ä¸æ述的许å¯è¯ï¼Œä½†æ˜¯å•ä¸ªæºæ–‡ä»¶å¯ä»¥
+具有ä¸åŒçš„与GPL-20兼容的许å¯è¯::
+
+ GPL-1.0+ : GNU通用公共许å¯è¯v1.0或更高版本
+ GPL-2.0+ : GNU通用公共许å¯è¯v2.0或更高版本
+ LGPL-2.0 : ä»…é™GNU库通用公共许å¯è¯v2
+ LGPL-2.0+: GNU 库通用公共许å¯è¯v2或更高版本
+ LGPL-2.1 : ä»…é™GNU宽通用公共许å¯è¯v2.1
+ LGPL-2.1+: GNU宽通用公共许å¯è¯v2.1或更高版本
+
+除æ¤ä¹‹å¤–，个人文件å¯ä»¥åœ¨åŒé‡è®¸å¯ä¸‹æ供，例如一个兼容的GPLå˜ä½“，或者BSD，
+MITç‰è®¸å¯ã€‚
+
+用户空间API（UAPI）头文件æ述了用户空间程åºä¸Žå†…æ ¸çš„æŽ¥å£ï¼Œè¿™æ˜¯ä¸€ç§ç‰¹æ®Šæƒ…况。
+æ ¹æ®å†…æ ¸COPYING文件ä¸çš„注释，syscall接å£æ˜¯ä¸€ä¸ªæ˜Žç¡®çš„边界，它ä¸ä¼šå°†GPLè¦æ±‚
+æ‰©å±•åˆ°ä»»ä½•ä½¿ç”¨å®ƒä¸Žå†…æ ¸é€šä¿¡çš„è½¯ä»¶ã€‚ç”±äºŽUAPI头文件必须包å«åœ¨åˆ›å»ºåœ¨Linuxå†…æ ¸
+上è¿è¡Œçš„å¯æ‰§è¡Œæ–‡ä»¶çš„任何æºæ–‡ä»¶ä¸ï¼Œå› æ¤æ¤ä¾‹å¤–必须记录在特别的许å¯è¯è¡¨è¿°ä¸ã€‚
+
+表达æºæ–‡ä»¶è®¸å¯è¯çš„常用方法是将匹é…çš„æ ·æ¿æ–‡æœ¬æ·»åŠ 到文件的顶部注释ä¸ã€‚由于
+æ ¼å¼ï¼Œæ‹¼å†™é”™è¯¯ç‰ï¼Œè¿™äº›â€œæ ·æ¿â€å¾ˆéš¾é€šè¿‡é‚£äº›åœ¨ä¸Šä¸‹æ–‡ä¸ä½¿ç”¨çš„验è¯è®¸å¯è¯åˆè§„性
+的工具。
+
+æ ·æ¿æ–‡æœ¬çš„替代方法是在æ¯ä¸ªæºæ–‡ä»¶ä¸ä½¿ç”¨è½¯ä»¶åŒ…æ•°æ®äº¤æ¢ï¼ˆSPDX）许å¯è¯æ ‡è¯†ç¬¦ã€‚
+SPDX许å¯è¯æ ‡è¯†ç¬¦æ˜¯æœºå™¨å¯è§£æžçš„，并且是用于æ供文件内容的许å¯è¯çš„精确缩写。
+SPDX许å¯è¯æ ‡è¯†ç¬¦ç”±Linux 基金会的SPDX 工作组管ç†ï¼Œå¹¶å¾—到了整个行业，工具
+供应商和法律团队的åˆä½œä¼™ä¼´çš„一致åŒæ„。有关详细信æ¯ï¼Œè¯·å‚阅
+https://spdx.org/
+
+Linuxå†…æ ¸éœ€è¦æ‰€æœ‰æºæ–‡ä»¶ä¸çš„精确SPDXæ ‡è¯†ç¬¦ã€‚å†…æ ¸ä¸ä½¿ç”¨çš„æœ‰æ•ˆæ ‡è¯†ç¬¦åœ¨
+`许å¯æ ‡è¯†ç¬¦`_ 一节ä¸è¿›è¡Œäº†è§£é‡Šï¼Œå¹¶ä¸”å·²å¯ä»¥åœ¨
+https://spdx.org/licenses/ 上的官方SPDX许å¯è¯åˆ—表ä¸æ£€ç´¢ï¼Œå¹¶é™„带许å¯è¯
+文本。
+
+许å¯æ ‡è¯†ç¬¦è¯æ³•
+--------------
+
+1.安置:
+
+Â Â Â å†…æ ¸æ–‡ä»¶ä¸çš„SPDX许å¯è¯æ ‡è¯†ç¬¦åº”æ·»åŠ åˆ°å¯åŒ…å«æ³¨é‡Šçš„文件ä¸çš„第一行。对于大多
+ 数文件，这是第一行，除了那些在第一行ä¸éœ€è¦'#!PATH_TO_INTERPRETER'的脚本。
+ 对于这些脚本，SPDXæ ‡è¯†ç¬¦è¿›å…¥ç¬¬äºŒè¡Œã€‚
+
+|
+
+2. é£Žæ ¼:
+
+ SPDX许å¯è¯æ ‡è¯†ç¬¦ä»¥æ³¨é‡Šçš„å½¢å¼æ·»åŠ ã€‚æ³¨é‡Šæ ·å¼å–决于文件类型::
+
+ C source: // SPDX-License-Identifier: <SPDX License Expression>
+ C header: /* SPDX-License-Identifier: <SPDX License Expression> */
+ ASM: /* SPDX-License-Identifier: <SPDX License Expression> */
+ scripts: # SPDX-License-Identifier: <SPDX License Expression>
+ .rst: .. SPDX-License-Identifier: <SPDX License Expression>
+ .dts{i}: // SPDX-License-Identifier: <SPDX License Expression>
+
+ å¦‚æžœç‰¹å®šå·¥å…·æ— æ³•å¤„ç†æ ‡å‡†æ³¨é‡Šæ ·å¼ï¼Œåˆ™åº”使用工具接å—的相应注释机制。这是在
+ C 头文件ä¸ä½¿ç”¨â€œ/\*\*/â€æ ·å¼æ³¨é‡Šçš„åŽŸå› ã€‚è¿‡åŽ»åœ¨ä½¿ç”¨ç”Ÿæˆçš„.lds文件ä¸è§‚察到
+ æž„å»ºè¢«ç ´å，其ä¸'ld'æ— æ³•è§£æžC++注释。现在已ç»è§£å†³äº†è¿™ä¸ªé—®é¢˜ï¼Œä½†ä»ç„¶æœ‰è¾ƒ
+ 旧的汇编程åºå·¥å…·æ— 法处ç†C++æ ·å¼çš„注释。
+
+|
+
+3. å¥æ³•:
+
+ <SPDX许å¯è¯è¡¨è¾¾å¼>是SPDX许å¯è¯åˆ—表ä¸çš„SPDXçŸæ ¼å¼è®¸å¯è¯æ ‡è¯†ç¬¦ï¼Œæˆ–者在许å¯
+ è¯ä¾‹å¤–适用时由“WITHâ€åˆ†éš”的两个SPDXçŸæ ¼å¼è®¸å¯è¯æ ‡è¯†ç¬¦çš„组åˆã€‚当应用多个许
+ å¯è¯æ—¶ï¼Œè¡¨è¾¾å¼ç”±åˆ†éš”å表达å¼çš„关键å—“ANDâ€ï¼Œâ€œORâ€ç»„æˆï¼Œå¹¶ç”±â€œï¼ˆâ€ï¼Œâ€œï¼‰â€åŒ…围。
+
+ 带有“或更高â€é€‰é¡¹çš„[L]GPLç‰è®¸å¯è¯çš„许å¯è¯æ ‡è¯†ç¬¦é€šè¿‡ä½¿ç”¨â€œ+â€æ¥è¡¨ç¤ºâ€œæˆ–更高â€
+ 选项æ¥æž„建。::
+
+ // SPDX-License-Identifier: GPL-2.0+
+ // SPDX-License-Identifier: LGPL-2.1+
+
+ 当需è¦ä¿®æ£çš„许å¯è¯æ—¶ï¼Œåº”使用WITH。 例如，linuxå†…æ ¸UAPI文件使用表达å¼::
+
+ // SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
+ // SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note
+
+ å…¶å®ƒåœ¨å†…æ ¸ä¸ä½¿ç”¨WITH例外的事例如下::
+
+ // SPDX-License-Identifier: GPL-2.0 WITH mif-exception
+ // SPDX-License-Identifier: GPL-2.0+ WITH GCC-exception-2.0
+
+ 例外åªèƒ½ä¸Žç‰¹å®šçš„许å¯è¯æ ‡è¯†ç¬¦ä¸€èµ·ä½¿ç”¨ã€‚有效的许å¯è¯æ ‡è¯†ç¬¦åˆ—在异常文本文件
+ çš„æ ‡è®°ä¸ã€‚有关详细信æ¯ï¼Œè¯·å‚阅 `许å¯æ ‡è¯†ç¬¦`_ ä¸€ç« ä¸çš„ `例外`_ 。
+
+ 如果文件是åŒé‡è®¸å¯ä¸”åªé€‰æ‹©ä¸€ä¸ªè®¸å¯è¯ï¼Œåˆ™åº”使用OR。例如，一些dtsi文件在åŒ
+ 许å¯ä¸‹å¯ç”¨::
+
+ // SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
+
+ å†…æ ¸ä¸åŒè®¸å¯æ–‡ä»¶ä¸è®¸å¯è¡¨è¾¾å¼çš„示例::
+
+ // SPDX-License-Identifier: GPL-2.0 OR MIT
+ // SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+ // SPDX-License-Identifier: GPL-2.0 OR Apache-2.0
+ // SPDX-License-Identifier: GPL-2.0 OR MPL-1.1
+ // SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) OR MIT
+ // SPDX-License-Identifier: GPL-1.0+ OR BSD-3-Clause OR OpenSSL
+
+ 如果文件具有多个许å¯è¯ï¼Œå…¶æ¡æ¬¾å…¨éƒ¨é€‚用于使用该文件，则应使用AND。例如，
+ 如果代ç 是从å¦ä¸€ä¸ªé¡¹ç›®ç»§æ‰¿çš„，并且已ç»æŽˆäºˆäº†å°†å…¶æ”¾å…¥å†…æ ¸çš„æƒé™ï¼Œä½†åŽŸå§‹
+ 许å¯æ¡æ¬¾éœ€è¦ä¿æŒæœ‰æ•ˆ::
+
+ // SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) AND MIT
+
+ å¦ä¸€ä¸ªéœ€è¦éµå®ˆä¸¤å¥—许å¯æ¡æ¬¾çš„例å是::
+
+ // SPDX-License-Identifier: GPL-1.0+ AND LGPL-2.1+
+
+许å¯æ ‡è¯†ç¬¦
+----------
+
+当å‰ä½¿ç”¨çš„许å¯è¯ä»¥åŠæ·»åŠ åˆ°å†…æ ¸çš„ä»£ç 许å¯è¯å¯ä»¥åˆ†è§£ä¸ºï¼š
+
+1. _`优先许å¯`:
+
+ 应尽å¯èƒ½ä½¿ç”¨è¿™äº›è®¸å¯è¯ï¼Œå› 为它们已知完全兼容并广泛使用。这些许å¯è¯åœ¨å†…æ ¸
+ 目录::
+
+ LICENSES/preferred/
+
+ æ¤ç›®å½•ä¸çš„文件包å«å®Œæ•´çš„许å¯è¯æ–‡æœ¬å’Œ `å…ƒæ ‡è®°`_ 。文件å与SPDX许å¯è¯æ ‡è¯†
+ 符相åŒï¼ŒåŽè€…应用于æºæ–‡ä»¶ä¸çš„许å¯è¯ã€‚
+
+ 例如::
+
+ LICENSES/preferred/GPL-2.0
+
+ 包å«GPLv2许å¯è¯æ–‡æœ¬å’Œæ‰€éœ€çš„å…ƒæ ‡ç¾::
+
+ LICENSES/preferred/MIT
+
+ 包å«MIT许å¯è¯æ–‡æœ¬å’Œæ‰€éœ€çš„å…ƒæ ‡è®°
+
+ _`å…ƒæ ‡è®°`:
+
+ 许å¯è¯æ–‡ä»¶ä¸å¿…须包å«ä»¥ä¸‹å…ƒæ ‡è®°ï¼š
+
+ - Valid-License-Identifier:
+
+   一行或多行, 声明那些许å¯æ ‡è¯†ç¬¦åœ¨é¡¹ç›®å†…有效, 以引用æ¤ç‰¹å®šè®¸å¯çš„文本。通
+ å¸¸è¿™æ˜¯ä¸€ä¸ªæœ‰æ•ˆçš„æ ‡è¯†ç¬¦ï¼Œä½†æ˜¯ä¾‹å¦‚å¯¹äºŽå¸¦æœ‰'或更高'选项的许å¯è¯ï¼Œä¸¤ä¸ªæ ‡è¯†
+ 符都有效。
+
+ - SPDX-URL:
+
+ SPDX页é¢çš„URL，其ä¸åŒ…å«ä¸Žè®¸å¯è¯ç›¸å…³çš„其他信æ¯.
+
+ - Usage-Guidance:
+
+ ä½¿ç”¨å»ºè®®çš„è‡ªç”±æ ¼å¼æ–‡æœ¬ã€‚该文本必须包å«SPDX许å¯è¯æ ‡è¯†ç¬¦çš„æ£ç¡®ç¤ºä¾‹ï¼Œå› 为
+ å®ƒä»¬åº”æ ¹æ® `许å¯æ ‡è¯†ç¬¦è¯æ³•`_ 指å—放入æºæ–‡ä»¶ä¸ã€‚
+
+ - License-Text:
+
+ æ¤æ ‡è®°ä¹‹åŽçš„所有文本都被视为原始许å¯æ–‡æœ¬
+
+ æ–‡ä»¶æ ¼å¼ç¤ºä¾‹::
+
+ Valid-License-Identifier: GPL-2.0
+ Valid-License-Identifier: GPL-2.0+
+ SPDX-URL: https://spdx.org/licenses/GPL-2.0.html
+ Usage-Guide:
+ To use this license in source code, put one of the following SPDX
+ tag/value pairs into a comment according to the placement
+ guidelines in the licensing rules documentation.
+ For 'GNU General Public License (GPL) version 2 only' use:
+ SPDX-License-Identifier: GPL-2.0
+ For 'GNU General Public License (GPL) version 2 or any later version' use:
+ SPDX-License-Identifier: GPL-2.0+
+ License-Text:
+ Full license text
+
+ ::
+
+ SPDX-License-Identifier: MIT
+ SPDX-URL: https://spdx.org/licenses/MIT.html
+ Usage-Guide:
+ To use this license in source code, put the following SPDX
+ tag/value pair into a comment according to the placement
+ guidelines in the licensing rules documentation.
+ SPDX-License-Identifier: MIT
+ License-Text:
+ Full license text
+
+|
+
+2. ä¸æŽ¨è的许å¯è¯:
+
+ 这些许å¯è¯åªåº”用于现有代ç 或从其他项目导入代ç 。这些许å¯è¯åœ¨å†…æ ¸ç›®å½•::
+
+ LICENSES/other/
+
+ æ¤ç›®å½•ä¸çš„文件包å«å®Œæ•´çš„许å¯è¯æ–‡æœ¬å’Œ `å…ƒæ ‡è®°`_ 。文件å与SPDX许å¯è¯æ ‡è¯†
+ 符相åŒï¼ŒåŽè€…应用于æºæ–‡ä»¶ä¸çš„许å¯è¯ã€‚
+
+ 例如::
+
+ LICENSES/other/ISC
+
+ 包å«å›½é™…系统è”åˆè®¸å¯æ–‡æœ¬å’Œæ‰€éœ€çš„å…ƒæ ‡ç¾::
+
+ LICENSES/other/ZLib
+
+ 包å«ZLIB许å¯æ–‡æœ¬å’Œæ‰€éœ€çš„å…ƒæ ‡ç¾.
+
+ å…ƒæ ‡ç¾:
+
+ “其他â€è®¸å¯è¯çš„å…ƒæ ‡ç¾è¦æ±‚与 `优先许å¯`_ çš„è¦æ±‚相åŒã€‚
+
+ æ–‡ä»¶æ ¼å¼ç¤ºä¾‹::
+
+ Valid-License-Identifier: ISC
+ SPDX-URL: https://spdx.org/licenses/ISC.html
+ Usage-Guide:
+ Usage of this license in the kernel for new code is discouraged
+ and it should solely be used for importing code from an already
+ existing project.
+ To use this license in source code, put the following SPDX
+ tag/value pair into a comment according to the placement
+ guidelines in the licensing rules documentation.
+ SPDX-License-Identifier: ISC
+ License-Text:
+ Full license text
+
+|
+
+3. _`例外`:
+
+ æŸäº›è®¸å¯è¯å¯ä»¥ä¿®æ”¹ï¼Œå¹¶å…许原始许å¯è¯ä¸å…·æœ‰çš„æŸäº›ä¾‹å¤–æƒåˆ©ã€‚这些例外在
+ å†…æ ¸ç›®å½•::
+
+ LICENSES/exceptions/
+
+ æ¤ç›®å½•ä¸çš„文件包å«å®Œæ•´çš„例外文本和所需的 `ä¾‹å¤–å…ƒæ ‡è®°`_ 。
+
+ 例如::
+
+ LICENSES/exceptions/Linux-syscall-note
+
+ 包å«Linuxå†…æ ¸çš„COPYING文件ä¸è®°å½•çš„Linux系统调用例外，该文件用于UAPI
+ 头文件。例如::
+
+ LICENSES/exceptions/GCC-exception-2.0
+
+ 包å«GCC'链接例外'，它å…许独立于其许å¯è¯çš„ä»»ä½•äºŒè¿›åˆ¶æ–‡ä»¶ä¸Žæ ‡è®°æœ‰æ¤ä¾‹å¤–çš„
+ 文件的编译版本链接。这是从GPLä¸å…¼å®¹æºä»£ç 创建å¯è¿è¡Œçš„å¯æ‰§è¡Œæ–‡ä»¶æ‰€å¿…需的。
+
+ _`ä¾‹å¤–å…ƒæ ‡è®°`:
+
+ ä»¥ä¸‹å…ƒæ ‡è®°å¿…é¡»åœ¨ä¾‹å¤–æ–‡ä»¶ä¸å¯ç”¨ï¼š
+
+ - SPDX-Exception-Identifier:
+
+   一个å¯ä¸ŽSPDX许å¯è¯æ ‡è¯†ç¬¦ä¸€èµ·ä½¿ç”¨çš„ä¾‹å¤–æ ‡è¯†ç¬¦ã€‚
+
+ - SPDX-URL:
+
+ SPDX页é¢çš„URL，其ä¸åŒ…å«ä¸Žä¾‹å¤–相关的其他信æ¯ã€‚
+
+ - SPDX-Licenses:
+
+   以逗å·åˆ†éš”的例外å¯ç”¨çš„SPDX许å¯è¯æ ‡è¯†ç¬¦åˆ—表。
+
+ - Usage-Guidance:
+
+ ä½¿ç”¨å»ºè®®çš„è‡ªç”±æ ¼å¼æ–‡æœ¬ã€‚必须在文本åŽé¢åŠ 上SPDX许å¯è¯æ ‡è¯†ç¬¦çš„æ£ç¡®ç¤ºä¾‹ï¼Œ
+ å› ä¸ºå®ƒä»¬åº”æ ¹æ® `许å¯æ ‡è¯†ç¬¦è¯æ³•`_ 指å—放入æºæ–‡ä»¶ä¸ã€‚
+
+ - Exception-Text:
+
+ æ¤æ ‡è®°ä¹‹åŽçš„所有文本都被视为原始异常文本
+
+ æ–‡ä»¶æ ¼å¼ç¤ºä¾‹::
+
+ SPDX-Exception-Identifier: Linux-syscall-note
+ SPDX-URL: https://spdx.org/licenses/Linux-syscall-note.html
+ SPDX-Licenses: GPL-2.0, GPL-2.0+, GPL-1.0+, LGPL-2.0, LGPL-2.0+, LGPL-2.1, LGPL-2.1+
+ Usage-Guidance:
+ This exception is used together with one of the above SPDX-Licenses
+ to mark user-space API (uapi) header files so they can be included
+ into non GPL compliant user-space application code.
+ To use this exception add it with the keyword WITH to one of the
+ identifiers in the SPDX-Licenses tag:
+ SPDX-License-Identifier: <SPDX-License> WITH Linux-syscall-note
+ Exception-Text:
+ Full exception text
+
+ ::
+
+ SPDX-Exception-Identifier: GCC-exception-2.0
+ SPDX-URL: https://spdx.org/licenses/GCC-exception-2.0.html
+ SPDX-Licenses: GPL-2.0, GPL-2.0+
+ Usage-Guidance:
+ The "GCC Runtime Library exception 2.0" is used together with one
+ of the above SPDX-Licenses for code imported from the GCC runtime
+ library.
+ To use this exception add it with the keyword WITH to one of the
+ identifiers in the SPDX-Licenses tag:
+ SPDX-License-Identifier: <SPDX-License> WITH GCC-exception-2.0
+ Exception-Text:
+ Full exception text
+
+
+所有SPDX许å¯è¯æ ‡è¯†ç¬¦å’Œä¾‹å¤–都必须在LICENSESå目录ä¸å…·æœ‰ç›¸åº”的文件。这是å…许
+工具验è¯ï¼ˆä¾‹å¦‚checkpatch.pl）以åŠå‡†å¤‡å¥½ä»Žæºè¯»å–å’Œæå–许å¯è¯æ‰€å¿…需的, 这是
+å„ç§FOSS组织推è的，例如 `FSFE REUSE initiative <https://reuse.software/>`_.
+
+_`模å—许å¯`
+-----------------
+
+ å¯åŠ è½½å†…æ ¸æ¨¡å—还需è¦MODULE_LICENSEï¼ˆï¼‰æ ‡è®°ã€‚æ¤æ ‡è®°æ—¢ä¸æ›¿ä»£æ£ç¡®çš„æºä»£ç
+ 许å¯è¯ä¿¡æ¯ï¼ˆSPDX-License-Identifier），也ä¸ä»¥ä»»ä½•æ–¹å¼è¡¨ç¤ºæˆ–确定æ供模å—
+ æºä»£ç 的确切许å¯è¯ã€‚
+
+ æ¤æ ‡è®°çš„唯一目的是æ供足够的信æ¯ï¼Œè¯¥æ¨¡å—是å¦æ˜¯è‡ªç”±è½¯ä»¶æˆ–è€…æ˜¯å†…æ ¸æ¨¡å—åŠ
+ 载器和用户空间工具的专有模å—。
+
+ MODULE_LICENSE（）的有效许å¯è¯å—符串是:
+
+ ============================= =============================================
+ "GPL" 模å—æ˜¯æ ¹æ®GPL版本2许å¯çš„。这并ä¸è¡¨ç¤ºä»…é™äºŽ
+ GPL-2.0或GPL-2.0或更高版本之间的任何区别。
+ 最æ£ç¡®è®¸å¯è¯ä¿¡æ¯åªèƒ½é€šè¿‡ç›¸åº”æºæ–‡ä»¶ä¸çš„许å¯è¯
+ ä¿¡æ¯æ¥ç¡®å®š
+
+ "GPL v2" å’Œ"GPL"相åŒï¼Œå®ƒçš„å˜åœ¨æ˜¯å› 为历å²åŽŸå› 。
+
+ "GPL and additional rights" 表示模å—æºåœ¨GPL v2å˜ä½“å’ŒMIT许å¯ä¸‹åŒé‡è®¸å¯çš„
+ 历å²å˜ä½“。请ä¸è¦åœ¨æ–°ä»£ç ä¸ä½¿ç”¨ã€‚
+
+ "Dual MIT/GPL" 表达该模å—在GPL v2å˜ä½“或MIT许å¯è¯é€‰æ‹©ä¸‹åŒé‡
+ 许å¯çš„æ£ç¡®æ–¹å¼ã€‚
+
+ "Dual BSD/GPL" 该模å—æ ¹æ®GPL v2å˜ä½“或BSD许å¯è¯é€‰æ‹©è¿›è¡ŒåŒé‡
+ 许å¯ã€‚ BSD许å¯è¯çš„确切å˜ä½“åªèƒ½é€šè¿‡ç›¸åº”æºæ–‡ä»¶
+ ä¸çš„许å¯è¯ä¿¡æ¯æ¥ç¡®å®šã€‚
+
+ "Dual MPL/GPL" 该模å—æ ¹æ®GPL v2å˜ä½“或Mozilla Public License
+ （MPL）选项进行åŒé‡è®¸å¯ã€‚ MPL许å¯è¯çš„确切å˜ä½“
+ åªèƒ½é€šè¿‡ç›¸åº”çš„æºæ–‡ä»¶ä¸çš„许å¯è¯ä¿¡æ¯æ¥ç¡®å®šã€‚
+
+ "Proprietary" 该模å—属于专有许å¯ã€‚æ¤å—符串仅用于专有的第三
+ 方模å—，ä¸èƒ½ç”¨äºŽåœ¨å†…æ ¸æ ‘ä¸å…·æœ‰æºä»£ç 的模å—。
+ 以这ç§æ–¹å¼æ ‡è®°çš„模å—åœ¨åŠ è½½æ—¶ä¼šä½¿ç”¨'P'æ ‡è®°æ±¡
+ æŸ“å†…æ ¸ï¼Œå¹¶ä¸”å†…æ ¸æ¨¡å—åŠ è½½å™¨æ‹’ç»å°†è¿™äº›æ¨¡å—链接
+ 到使用EXPORT_SYMBOL_GPL（）导出的符å·ã€‚
+ ============================= =============================================
+
diff --git a/Documentation/translations/zh_CN/process/magic-number.rst b/Documentation/translations/zh_CN/process/magic-number.rst
new file mode 100644
index 0000000000000000000000000000000000000000..15c5925181942569cfda71902f93f81b1591a2a2
--- /dev/null
+++ b/Documentation/translations/zh_CN/process/magic-number.rst
@@ -0,0 +1,151 @@
+.. _cn_magicnumbers:
+
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: :ref:`Documentation/process/magic-number.rst <magicnumbers>`
+
+如果想评论或更新本文的内容，请直接å‘信到LKMLã€‚å¦‚æžœä½ ä½¿ç”¨è‹±æ–‡äº¤æµæœ‰å›°éš¾çš„è¯ï¼Œä¹Ÿå¯
+以å‘ä¸æ–‡ç‰ˆç»´æŠ¤è€…求助。如果本翻译更新ä¸åŠæ—¶æˆ–者翻译å˜åœ¨é—®é¢˜ï¼Œè¯·è”ç³»ä¸æ–‡ç‰ˆç»´æŠ¤è€…::
+
+ ä¸æ–‡ç‰ˆç»´æŠ¤è€…： è´¾å¨å¨ Jia Wei Wei <harryxiyou@gmail.com>
+ ä¸æ–‡ç‰ˆç¿»è¯‘者： è´¾å¨å¨ Jia Wei Wei <harryxiyou@gmail.com>
+ ä¸æ–‡ç‰ˆæ ¡è¯‘者： è´¾å¨å¨ Jia Wei Wei <harryxiyou@gmail.com>
+
+Linux é”术数
+============
+
+这个文件是有关当å‰ä½¿ç”¨çš„é”æœ¯å€¼æ³¨å†Œè¡¨ã€‚å½“ä½ ç»™ä¸€ä¸ªç»“æž„æ·»åŠ äº†ä¸€ä¸ªé”æœ¯å€¼ï¼Œä½ ä¹Ÿåº”è¯¥æŠŠè¿™ä¸ªé”æœ¯å€¼æ·»åŠ åˆ°è¿™ä¸ªæ–‡ä»¶ï¼Œå› ä¸ºæˆ‘ä»¬æœ€å¥½æŠŠç”¨äºŽå„ç§ç»“æž„çš„é”术值统一起æ¥ã€‚
+
+使用é”术值æ¥ä¿æŠ¤å†…æ ¸æ•°æ®ç»“构是一个éžå¸¸å¥½çš„主æ„。这就å…è®¸ä½ åœ¨è¿è¡ŒæœŸæ£€æŸ¥(a)一个结构是å¦å·²ç»è¢«æ”»å‡»ï¼Œæˆ–者(b)ä½ å·²ç»ç»™ä¸€ä¸ªä¾‹è¡Œç¨‹åºé€šè¿‡äº†ä¸€ä¸ªé”™è¯¯çš„结构。åŽä¸€ç§æƒ…况特别地有用---ç‰¹åˆ«æ˜¯å½“ä½ é€šè¿‡ä¸€ä¸ªç©ºæŒ‡é’ˆæŒ‡å‘结构体的时候。ttyæºç ，例如，ç»å¸¸é€šè¿‡ç‰¹å®šé©±åŠ¨ä½¿ç”¨è¿™ç§æ–¹æ³•å¹¶ä¸”åå¤åœ°æŽ’列特定方é¢çš„结构。
+
+使用é”术值的方法是在结构的开始处声明的，如下::
+
+ struct tty_ldisc {
+ int magic;
+ ...
+ };
+
+å½“ä½ ä»¥åŽç»™å†…æ ¸æ·»åŠ å¢žå¼ºåŠŸèƒ½çš„æ—¶å€™ï¼Œè¯·éµå®ˆè¿™æ¡è§„则ï¼è¿™æ ·å°±ä¼šèŠ‚çœæ•°ä¸æ¸…的调试时间，特别是一些å¤æ€ªçš„情况，例如，数组超出范围并且é‡æ–°å†™äº†è¶…出部分。éµå®ˆè¿™ä¸ªè§„则，‪这些情况å¯ä»¥è¢«å¿«é€Ÿåœ°ï¼Œå®‰å…¨åœ°é¿å…。
+
+ Theodore Ts'o
+ 31 Mar 94
+
+给当å‰çš„Linux 2.1.55æ·»åŠ é”术表。
+
+ Michael Chastain
+ <mailto:mec@shout.net>
+ 22 Sep 1997
+
+现在应该最新的Linux 2.1.112.å› ä¸ºåœ¨ç‰¹æ€§å†»ç»“æœŸé—´ï¼Œä¸èƒ½åœ¨2.2.xå‰æ”¹å˜ä»»ä½•ä¸œè¥¿ã€‚这些æ¡ç›®è¢«æ•°åŸŸæ‰€æŽ’åºã€‚
+
+ Krzysztof G.Baranowski
+ <mailto: kgb@knm.org.pl>
+ 29 Jul 1998
+
+æ›´æ–°é”术表到Linux 2.5.45。刚好越过特性冻结，但是有å¯èƒ½è¿˜ä¼šæœ‰ä¸€äº›æ–°çš„é”术值在2.6.x之å‰èžå…¥åˆ°å†…æ ¸ä¸ã€‚
+
+ Petr Baudis
+ <pasky@ucw.cz>
+ 03 Nov 2002
+
+æ›´æ–°é”术表到Linux 2.5.74。
+
+ Fabian Frederick
+ <ffrederick@users.sourceforge.net>
+ 09 Jul 2003
+
+===================== ================ ======================== ==========================================
+é”术数å æ•°å— ç»“æž„ 文件
+===================== ================ ======================== ==========================================
+PG_MAGIC 'P' pg_{read,write}_hdr ``include/linux/pg.h``
+CMAGIC 0x0111 user ``include/linux/a.out.h``
+MKISS_DRIVER_MAGIC 0x04bf mkiss_channel ``drivers/net/mkiss.h``
+HDLC_MAGIC 0x239e n_hdlc ``drivers/char/n_hdlc.c``
+APM_BIOS_MAGIC 0x4101 apm_user ``arch/x86/kernel/apm_32.c``
+CYCLADES_MAGIC 0x4359 cyclades_port ``include/linux/cyclades.h``
+DB_MAGIC 0x4442 fc_info ``drivers/net/iph5526_novram.c``
+DL_MAGIC 0x444d fc_info ``drivers/net/iph5526_novram.c``
+FASYNC_MAGIC 0x4601 fasync_struct ``include/linux/fs.h``
+FF_MAGIC 0x4646 fc_info ``drivers/net/iph5526_novram.c``
+ISICOM_MAGIC 0x4d54 isi_port ``include/linux/isicom.h``
+PTY_MAGIC 0x5001 ``drivers/char/pty.c``
+PPP_MAGIC 0x5002 ppp ``include/linux/if_pppvar.h``
+SERIAL_MAGIC 0x5301 async_struct ``include/linux/serial.h``
+SSTATE_MAGIC 0x5302 serial_state ``include/linux/serial.h``
+SLIP_MAGIC 0x5302 slip ``drivers/net/slip.h``
+STRIP_MAGIC 0x5303 strip ``drivers/net/strip.c``
+X25_ASY_MAGIC 0x5303 x25_asy ``drivers/net/x25_asy.h``
+SIXPACK_MAGIC 0x5304 sixpack ``drivers/net/hamradio/6pack.h``
+AX25_MAGIC 0x5316 ax_disp ``drivers/net/mkiss.h``
+TTY_MAGIC 0x5401 tty_struct ``include/linux/tty.h``
+MGSL_MAGIC 0x5401 mgsl_info ``drivers/char/synclink.c``
+TTY_DRIVER_MAGIC 0x5402 tty_driver ``include/linux/tty_driver.h``
+MGSLPC_MAGIC 0x5402 mgslpc_info ``drivers/char/pcmcia/synclink_cs.c``
+TTY_LDISC_MAGIC 0x5403 tty_ldisc ``include/linux/tty_ldisc.h``
+USB_SERIAL_MAGIC 0x6702 usb_serial ``drivers/usb/serial/usb-serial.h``
+FULL_DUPLEX_MAGIC 0x6969 ``drivers/net/ethernet/dec/tulip/de2104x.c``
+USB_BLUETOOTH_MAGIC 0x6d02 usb_bluetooth ``drivers/usb/class/bluetty.c``
+RFCOMM_TTY_MAGIC 0x6d02 ``net/bluetooth/rfcomm/tty.c``
+USB_SERIAL_PORT_MAGIC 0x7301 usb_serial_port ``drivers/usb/serial/usb-serial.h``
+CG_MAGIC 0x00090255 ufs_cylinder_group ``include/linux/ufs_fs.h``
+RPORT_MAGIC 0x00525001 r_port ``drivers/char/rocket_int.h``
+LSEMAGIC 0x05091998 lse ``drivers/fc4/fc.c``
+GDTIOCTL_MAGIC 0x06030f07 gdth_iowr_str ``drivers/scsi/gdth_ioctl.h``
+RIEBL_MAGIC 0x09051990 ``drivers/net/atarilance.c``
+NBD_REQUEST_MAGIC 0x12560953 nbd_request ``include/linux/nbd.h``
+RED_MAGIC2 0x170fc2a5 (any) ``mm/slab.c``
+BAYCOM_MAGIC 0x19730510 baycom_state ``drivers/net/baycom_epp.c``
+ISDN_X25IFACE_MAGIC 0x1e75a2b9 isdn_x25iface_proto_data ``drivers/isdn/isdn_x25iface.h``
+ECP_MAGIC 0x21504345 cdkecpsig ``include/linux/cdk.h``
+LSOMAGIC 0x27091997 lso ``drivers/fc4/fc.c``
+LSMAGIC 0x2a3b4d2a ls ``drivers/fc4/fc.c``
+WANPIPE_MAGIC 0x414C4453 sdla_{dump,exec} ``include/linux/wanpipe.h``
+CS_CARD_MAGIC 0x43525553 cs_card ``sound/oss/cs46xx.c``
+LABELCL_MAGIC 0x4857434c labelcl_info_s ``include/asm/ia64/sn/labelcl.h``
+ISDN_ASYNC_MAGIC 0x49344C01 modem_info ``include/linux/isdn.h``
+CTC_ASYNC_MAGIC 0x49344C01 ctc_tty_info ``drivers/s390/net/ctctty.c``
+ISDN_NET_MAGIC 0x49344C02 isdn_net_local_s ``drivers/isdn/i4l/isdn_net_lib.h``
+SAVEKMSG_MAGIC2 0x4B4D5347 savekmsg ``arch/*/amiga/config.c``
+CS_STATE_MAGIC 0x4c4f4749 cs_state ``sound/oss/cs46xx.c``
+SLAB_C_MAGIC 0x4f17a36d kmem_cache ``mm/slab.c``
+COW_MAGIC 0x4f4f4f4d cow_header_v1 ``arch/um/drivers/ubd_user.c``
+I810_CARD_MAGIC 0x5072696E i810_card ``sound/oss/i810_audio.c``
+TRIDENT_CARD_MAGIC 0x5072696E trident_card ``sound/oss/trident.c``
+ROUTER_MAGIC 0x524d4157 wan_device [in ``wanrouter.h`` pre 3.9]
+SAVEKMSG_MAGIC1 0x53415645 savekmsg ``arch/*/amiga/config.c``
+GDA_MAGIC 0x58464552 gda ``arch/mips/include/asm/sn/gda.h``
+RED_MAGIC1 0x5a2cf071 (any) ``mm/slab.c``
+EEPROM_MAGIC_VALUE 0x5ab478d2 lanai_dev ``drivers/atm/lanai.c``
+HDLCDRV_MAGIC 0x5ac6e778 hdlcdrv_state ``include/linux/hdlcdrv.h``
+PCXX_MAGIC 0x5c6df104 channel ``drivers/char/pcxx.h``
+KV_MAGIC 0x5f4b565f kernel_vars_s ``arch/mips/include/asm/sn/klkernvars.h``
+I810_STATE_MAGIC 0x63657373 i810_state ``sound/oss/i810_audio.c``
+TRIDENT_STATE_MAGIC 0x63657373 trient_state ``sound/oss/trident.c``
+M3_CARD_MAGIC 0x646e6f50 m3_card ``sound/oss/maestro3.c``
+FW_HEADER_MAGIC 0x65726F66 fw_header ``drivers/atm/fore200e.h``
+SLOT_MAGIC 0x67267321 slot ``drivers/hotplug/cpqphp.h``
+SLOT_MAGIC 0x67267322 slot ``drivers/hotplug/acpiphp.h``
+LO_MAGIC 0x68797548 nbd_device ``include/linux/nbd.h``
+OPROFILE_MAGIC 0x6f70726f super_block ``drivers/oprofile/oprofilefs.h``
+M3_STATE_MAGIC 0x734d724d m3_state ``sound/oss/maestro3.c``
+VMALLOC_MAGIC 0x87654320 snd_alloc_track ``sound/core/memory.c``
+KMALLOC_MAGIC 0x87654321 snd_alloc_track ``sound/core/memory.c``
+PWC_MAGIC 0x89DC10AB pwc_device ``drivers/usb/media/pwc.h``
+NBD_REPLY_MAGIC 0x96744668 nbd_reply ``include/linux/nbd.h``
+ENI155_MAGIC 0xa54b872d midway_eprom ``drivers/atm/eni.h``
+CODA_MAGIC 0xC0DAC0DA coda_file_info ``fs/coda/coda_fs_i.h``
+DPMEM_MAGIC 0xc0ffee11 gdt_pci_sram ``drivers/scsi/gdth.h``
+YAM_MAGIC 0xF10A7654 yam_port ``drivers/net/hamradio/yam.c``
+CCB_MAGIC 0xf2691ad2 ccb ``drivers/scsi/ncr53c8xx.c``
+QUEUE_MAGIC_FREE 0xf7e1c9a3 queue_entry ``drivers/scsi/arm/queue.c``
+QUEUE_MAGIC_USED 0xf7e1cc33 queue_entry ``drivers/scsi/arm/queue.c``
+HTB_CMAGIC 0xFEFAFEF1 htb_class ``net/sched/sch_htb.c``
+NMI_MAGIC 0x48414d4d455201 nmi_s ``arch/mips/include/asm/sn/nmi.h``
+===================== ================ ======================== ==========================================
+
+
+请注æ„，在声音记忆管ç†ä¸ä»ç„¶æœ‰ä¸€äº›ç‰¹æ®Šçš„为æ¯ä¸ªé©±åŠ¨å®šä¹‰çš„é”术值。查看include/sound/sndmagic.hæ¥èŽ·å–他们完整的列表信æ¯ã€‚很多OSS声音驱动拥有自己从声å¡PCI ID构建的é”术值-他们也没有被列在这里。
+
+IrDAå系统也使用了大é‡çš„自己的é”术值，查看include/net/irda/irda.hæ¥èŽ·å–他们完整的信æ¯ã€‚
+
+HFS是å¦å¤–一个比较大的使用é”术值的文件系统-ä½ å¯ä»¥åœ¨fs/hfs/hfs.hä¸æ‰¾åˆ°ä»–们。
diff --git a/Documentation/translations/zh_CN/process/management-style.rst b/Documentation/translations/zh_CN/process/management-style.rst
new file mode 100644
index 0000000000000000000000000000000000000000..a181fa56d19e333e9d1b451e6fa179f0d5cbce60
--- /dev/null
+++ b/Documentation/translations/zh_CN/process/management-style.rst
@@ -0,0 +1,207 @@
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: :ref:`Documentation/process/management-style.rst <managementstyle>`
+:Translator: Alex Shi <alex.shi@linux.alibaba.com>
+
+.. _cn_managementstyle:
+
+Linuxå†…æ ¸ç®¡ç†é£Žæ ¼
+=================
+
+这是一个简çŸçš„文档，æ述了Linuxå†…æ ¸é¦–é€‰çš„ï¼ˆæˆ–èƒ¡ç¼–çš„ï¼Œå–决于您问è°ï¼‰ç®¡ç†é£Žæ ¼ã€‚
+它的目的是在æŸç§ç¨‹åº¦ä¸Šå‚ç…§ :ref:`process/coding-style.rst <codingstyle>`
+主è¦æ˜¯ä¸ºäº†é¿å…åå¤å›žç” [#cnf1]_ 相åŒï¼ˆæˆ–类似）的问题。
+
+管ç†é£Žæ ¼æ˜¯éžå¸¸ä¸ªäººåŒ–的，比简å•çš„ç¼–ç é£Žæ ¼è§„åˆ™æ›´éš¾ä»¥é‡åŒ–ï¼Œå› æ¤æœ¬æ–‡æ¡£å¯èƒ½ä¸Žå®ž
+际情况有关，也å¯èƒ½ä¸Žå®žé™…æƒ…å†µæ— å…³ã€‚èµ·åˆå®ƒæ˜¯ä¸€ä¸ªçŽ©ç¬‘，但这并ä¸æ„味ç€å®ƒå¯èƒ½ä¸
+æ˜¯çœŸçš„ã€‚ä½ å¾—è‡ªå·±å†³å®šã€‚
+
+顺便说一å¥ï¼Œåœ¨è°ˆåˆ°â€œæ ¸å¿ƒç®¡ç†è€…â€æ—¶ï¼Œä¸»è¦æ˜¯æŠ€æœ¯è´Ÿè´£äººï¼Œè€Œä¸æ˜¯åœ¨å…¬å¸å†…部进行ä¼
+统管ç†çš„äººã€‚å¦‚æžœä½ ç¾ç½²äº†é‡‡è´è®¢å•æˆ–è€…å¯¹ä½ çš„å›¢é˜Ÿçš„é¢„ç®—æœ‰ä»»ä½•äº†è§£ï¼Œä½ å‡ ä¹Žè‚¯å®š
+ä¸æ˜¯ä¸€ä¸ªæ ¸å¿ƒç®¡ç†è€…。这些建议å¯èƒ½é€‚用于您，也å¯èƒ½ä¸é€‚用于您。
+
+é¦–å…ˆï¼Œæˆ‘å»ºè®®ä½ è´ä¹°â€œé«˜æ•ˆäººçš„ä¸ƒä¸ªä¹ æƒ¯â€ï¼Œè€Œä¸æ˜¯é˜…读它。烧了它，这是一个伟大的
+象å¾æ€§å§¿æ€ã€‚
+
+.. [#cnf1] 本文件并ä¸æ˜¯é€šè¿‡å›žç”问题，而是通过让æ问者痛苦地明白，我们ä¸çŸ¥é“
+ ç”案是什么。
+
+ä¸ç®¡æ€Žæ ·ï¼Œè¿™é‡Œæ˜¯ï¼š
+
+.. _decisions:
+
+1）决ç–
+-------
+
+æ¯ä¸ªäººéƒ½è®¤ä¸ºç®¡ç†è€…åšå†³å®šï¼Œè€Œä¸”决ç–很é‡è¦ã€‚决定越大越痛苦，管ç†è€…就必须越高级。
+这很明显，但事实并éžå¦‚æ¤ã€‚
+
+游æˆçš„åå—是 **é¿å…** åšå‡ºå†³å®šã€‚å°¤å…¶æ˜¯ï¼Œå¦‚æžœæœ‰äººå‘Šè¯‰ä½ â€œé€‰æ‹©ï¼ˆa）或（b），
+我们真的需è¦ä½ æ¥åšå†³å®šâ€ï¼Œä½ 就是陷入麻烦的管ç†è€…ã€‚ä½ ç®¡ç†çš„äººæ¯”ä½ æ›´äº†è§£ç»†èŠ‚ï¼Œ
+所以如果他们æ¥æ‰¾ä½ åšæŠ€æœ¯å†³ç–ï¼Œä½ å®Œè›‹äº†ã€‚ä½ æ˜¾ç„¶æ²¡æœ‰èƒ½åŠ›ä¸ºä»–ä»¬åšè¿™ä¸ªå†³å®šã€‚
+
+ï¼ˆæŽ¨è®ºï¼šå¦‚æžœä½ ç®¡ç†çš„人ä¸æ¯”ä½ æ›´äº†è§£ç»†èŠ‚ï¼Œä½ ä¹Ÿä¼šè¢«æžç ¸ï¼Œå°½ç®¡åŽŸå› 完全ä¸åŒã€‚
+ä¹Ÿå°±æ˜¯è¯´ï¼Œä½ çš„å·¥ä½œæ˜¯é”™çš„ï¼Œä»–ä»¬åº”è¯¥ç®¡ç†ä½ çš„æ‰æ™ºï¼‰
+
+所以游æˆçš„åå—是 **é¿å…** åšå‡ºå†³å®šï¼Œè‡³å°‘是那些大而痛苦的决定。åšä¸€äº›å°çš„
+å’Œéžç»“果性的决定是很好的，并且使您看起æ¥å¥½åƒçŸ¥é“自己在åšä»€ä¹ˆï¼Œæ‰€ä»¥å†…æ ¸ç®¡ç†è€…
+需è¦åšçš„是将那些大的和痛苦的决定å˜æˆé‚£äº›æ²¡æœ‰äººçœŸæ£å…³å¿ƒçš„å°äº‹æƒ…。
+
+这有助于认识到一个大的决定和一个å°çš„å†³å®šä¹‹é—´çš„å…³é”®åŒºåˆ«æ˜¯ä½ æ˜¯å¦å¯ä»¥åœ¨äº‹åŽä¿®æ£
+ä½ çš„å†³å®šã€‚ä»»ä½•å†³å®šéƒ½å¯ä»¥é€šè¿‡å§‹ç»ˆç¡®ä¿å¦‚æžœä½ é”™äº†ï¼ˆè€Œä¸”ä½ ä¸€å®šä¼šé”™ï¼‰ï¼Œä½ ä»¥åŽæ€»æ˜¯
+å¯ä»¥é€šè¿‡å›žæº¯æ¥å¼¥è¡¥æŸå¤±ã€‚çªç„¶é—´ï¼Œä½ å°±è¦åšä¸¤ä¸ªæ— 关紧è¦çš„决定，一个是错误的，å¦
+一个是æ£ç¡®çš„。
+
+人们甚至会认为这是真æ£çš„领导能力（咳，胡说，咳）。
+
+å› æ¤ï¼Œé¿å…é‡å¤§å†³ç–的关键在于é¿å…åšé‚£äº›æ— 法挽回的事情。ä¸è¦è¢«å¼•å¯¼åˆ°ä¸€ä¸ªä½ æ— æ³•
+逃离的角è½ã€‚èµ°æŠ•æ— è·¯çš„è€é¼ å¯èƒ½å¾ˆå±é™©â€”â€”èµ°æŠ•æ— è·¯çš„ç®¡ç†è€…真å¯æ€œã€‚
+
+事实è¯æ˜Žï¼Œç”±äºŽæ²¡æœ‰äººä¼šæ„šè ¢åˆ°è®©å†…æ ¸ç®¡ç†è€…承担巨大的财政责任，所以通常很容易
+å›žæº¯ã€‚æ—¢ç„¶ä½ ä¸å¯èƒ½æµªè´¹æŽ‰ä½ æ— æ³•å¿è¿˜çš„å·¨é¢èµ„é‡‘ï¼Œä½ å”¯ä¸€å¯ä»¥å›žæº¯çš„就是技术决ç–，
+而回溯很容易：åªè¦å‘Šè¯‰å¤§å®¶ä½ 是个ä¸ç§°èŒçš„傻瓜，说对ä¸èµ·ï¼Œç„¶åŽæ’¤é”€ä½ 去年让别
+人所åšçš„æ¯«æ— ä»·å€¼çš„å·¥ä½œã€‚çªç„¶é—´ï¼Œä½ 一年å‰åšçš„决定ä¸åœ¨æ˜¯ä¸€ä¸ªé‡å¤§çš„å†³å®šï¼Œå› ä¸º
+它很容易被推翻。
+
+事实è¯æ˜Žï¼Œæœ‰äº›äººå¯¹æŽ¥å—è¿™ç§æ–¹æ³•æœ‰å›°éš¾ï¼ŒåŽŸå› 有两个：
+
+ - æ‰¿è®¤ä½ æ˜¯ä¸ªç™½ç—´æ¯”çœ‹èµ·æ¥æ›´éš¾ã€‚我们都喜欢ä¿æŒå½¢è±¡ï¼Œåœ¨å…¬å…±åœºåˆè¯´ä½ 错了有时
+ 确实很难。
+ - å¦‚æžœæœ‰äººå‘Šè¯‰ä½ ï¼Œä½ åŽ»å¹´æ‰€åšçš„工作终究是ä¸å€¼å¾—的，那么对那些å¯æ€œçš„低级工
+ 程师æ¥è¯´ä¹Ÿæ˜¯å¾ˆå›°éš¾çš„，虽然实际的 **工作** å¾ˆå®¹æ˜“åˆ é™¤ï¼Œä½†ä½ å¯èƒ½å·²ç»ä¸å¯
+ 挽回地失去了工程师的信任。记ä½ï¼šâ€œä¸å¯æ’¤é”€â€æ˜¯æˆ‘们一开始就试图é¿å…的，
+ è€Œä½ çš„å†³å®šç»ˆç©¶æ˜¯ä¸€ä¸ªé‡å¤§çš„决定。
+
+ä»¤äººæ¬£æ…°çš„æ˜¯ï¼Œè¿™ä¸¤ä¸ªåŽŸå› éƒ½å¯ä»¥é€šè¿‡é¢„å…ˆæ‰¿è®¤ä½ æ²¡æœ‰ä»»ä½•çº¿ç´¢ï¼Œæå‰å‘Šè¯‰äººä»¬ä½ çš„
+决定完全是åˆæ¥çš„，而且å¯èƒ½æ˜¯é”™è¯¯çš„事情æ¥æœ‰æ•ˆåœ°ç¼“è§£ã€‚ä½ åº”è¯¥å§‹ç»ˆä¿ç•™æ”¹å˜ä¸»æ„
+çš„æƒåˆ©ï¼Œå¹¶è®©äººä»¬ **æ„识** åˆ°è¿™ä¸€ç‚¹ã€‚å½“ä½ **还没有** åšè¿‡çœŸæ£æ„šè ¢çš„事情的时
+å€™ï¼Œæ‰¿è®¤è‡ªå·±æ˜¯æ„šè ¢çš„è¦å®¹æ˜“得多。
+
+然åŽï¼Œå½“它真的被è¯æ˜Žæ˜¯æ„šè ¢çš„时候，人们就转动他们的眼ç 说“哎呀，下次ä¸è¦äº†â€ã€‚
+
+è¿™ç§å¯¹ä¸ç§°èŒçš„å…ˆå‘制人的承认，也å¯èƒ½ä½¿çœŸæ£åšè¿™é¡¹å·¥ä½œçš„人也会三æ€æ˜¯å¦å€¼å¾—åšã€‚
+毕竟，如果他们ä¸ç¡®å®šè¿™æ˜¯å¦æ˜¯ä¸€ä¸ªå¥½ä¸»æ„ï¼Œä½ è‚¯å®šä¸åº”该通过å‘他们ä¿è¯ä»–们所åš
+çš„å·¥ä½œå°†ä¼šè¿›å…¥ï¼ˆå†…æ ¸ï¼‰é¼“åŠ±ä»–ä»¬ã€‚åœ¨ä»–ä»¬å¼€å§‹ä¸€é¡¹å·¨å¤§çš„åŠªåŠ›ä¹‹å‰ï¼Œè‡³å°‘让他们三
+æ€è€ŒåŽè¡Œã€‚
+
+è®°ä½ï¼šä»–ä»¬æœ€å¥½æ¯”ä½ æ›´äº†è§£ç»†èŠ‚ï¼Œè€Œä¸”ä»–ä»¬é€šå¸¸è®¤ä¸ºä»–ä»¬å¯¹æ¯ä»¶äº‹éƒ½æœ‰ç”案。作为一
+个管ç†è€…ï¼Œä½ èƒ½åšçš„最好的事情ä¸æ˜¯çŒè¾“自信，而是对他们所åšçš„事情进行å¥åº·çš„批
+判性æ€è€ƒã€‚
+
+顺便说一å¥ï¼Œå¦ä¸€ç§é¿å…åšå‡ºå†³å®šçš„方法是看起æ¥å¾ˆå¯æ€œçš„抱怨 “我们ä¸èƒ½ä¸¤è€…å…¼
+å¾—å—？†相信我，它是有效的。如果ä¸æ¸…楚哪ç§æ–¹æ³•æ›´å¥½ï¼Œä»–们最终会弄清楚的。
+最终的ç”案å¯èƒ½æ˜¯ä¸¤ä¸ªå›¢é˜Ÿéƒ½ä¼šå› 为这ç§æƒ…况而感到沮丧，以至于他们放弃了。
+
+è¿™å¬èµ·æ¥åƒæ˜¯ä¸€ä¸ªå¤±è´¥ï¼Œä½†è¿™é€šå¸¸æ˜¯ä¸€ä¸ªè¿¹è±¡ï¼Œè¡¨æ˜Žä¸¤ä¸ªé¡¹ç›®éƒ½æœ‰é—®é¢˜ï¼Œè€Œå‚与其ä¸
+的人ä¸èƒ½åšå†³å®šçš„åŽŸå› æ˜¯ä»–ä»¬éƒ½æ˜¯é”™è¯¯çš„ã€‚ä½ æœ€ç»ˆä¼šé—»åˆ°çŽ«ç‘°çš„å‘³é“ï¼Œä½ é¿å…了å¦ä¸€
+ä¸ªä½ æœ¬å¯ä»¥æžç ¸çš„决定。
+
+2）人
+-----
+
+大多数人都是白痴，åšä¸€å管ç†è€…æ„味ç€ä½ 必须处ç†å¥½è¿™ä»¶äº‹ï¼Œä¹Ÿè®¸æ›´é‡è¦çš„是,
+**他们** 必须处ç†å¥½ä½ 。
+
+事实è¯æ˜Žï¼Œè™½ç„¶å¾ˆå®¹æ˜“çº æ£æŠ€æœ¯é”™è¯¯ï¼Œä½†ä¸å®¹æ˜“çº æ£äººæ ¼éšœç¢ã€‚ä½ åªèƒ½å’Œä»–们的和
+ä½ çš„ï¼ˆäººæ ¼éšœç¢ï¼‰å…±å¤„。
+
+但是，为了åšå¥½ä½œä¸ºå†…æ ¸ç®¡ç†è€…的准备，最好记ä½ä¸è¦çƒ§æŽ‰ä»»ä½•æ¡¥æ¢ï¼Œä¸è¦è½°ç‚¸ä»»ä½•
+æ— è¾œçš„æ‘民，也ä¸è¦ç–è¿œå¤ªå¤šçš„å†…æ ¸å¼€å‘人员。事实è¯æ˜Žï¼Œç–远人是相当容易的，而
+亲近一个ç–è¿œçš„äººæ˜¯å¾ˆéš¾çš„ã€‚å› æ¤ï¼Œâ€œç–è¿œâ€ç«‹å³å±žäºŽâ€œä¸å¯é€†â€çš„èŒƒç•´ï¼Œå¹¶æ ¹æ®
+:ref:`decisions` æˆä¸ºç»ä¸å¯ä»¥åšçš„事情。
+
+这里åªæœ‰å‡ 个简å•çš„规则：
+
+ (1) ä¸è¦å«äººç¬¨è›‹ï¼ˆè‡³å°‘ä¸è¦åœ¨å…¬å…±åœºåˆï¼‰
+ (2) å¦ä¹ 如何在忘记规则(1)æ—¶é“æ‰
+
+问题在于 #1 很容易去åšï¼Œå› ä¸ºä½ å¯ä»¥ç”¨æ•°ç™¾ä¸‡ç§ä¸åŒçš„æ–¹å¼è¯´â€œä½ 是一个笨蛋†[#cnf2]_
+有时甚至没有æ„è¯†åˆ°ï¼Œè€Œä¸”å‡ ä¹Žæ€»æ˜¯å¸¦ç€ä¸€ç§ç™½çƒåŒ–çš„ä¿¡å¿µï¼Œè®¤ä¸ºä½ æ˜¯å¯¹çš„ã€‚
+
+ä½ è¶Šç¡®ä¿¡è‡ªå·±æ˜¯å¯¹çš„ï¼ˆè®©æˆ‘ä»¬é¢å¯¹çŽ°å®žå§ï¼Œä½ å¯ä»¥æŠŠå‡ 乎所有人都称为å人，而且ä½
+ç»å¸¸æ˜¯å¯¹çš„），事åŽé“æ‰å°±è¶Šéš¾ã€‚
+
+è¦è§£å†³æ¤é—®é¢˜ï¼Œæ‚¨å®žé™…上åªæœ‰ä¸¤ä¸ªé€‰é¡¹ï¼š
+
+ - éžå¸¸æ“…é•¿é“æ‰
+ - 把“爱â€å‡åŒ€åœ°æ•£å¼€ï¼Œæ²¡æœ‰äººä¼šçœŸæ£æ„Ÿè§‰åˆ°è‡ªå·±è¢«ä¸å…¬å¹³åœ°çž„准了。让它有足够的
+ åˆ›é€ æ€§ï¼Œä»–ä»¬ç”šè‡³å¯èƒ½ä¼šè§‰å¾—好笑。
+
+选择永远ä¿æŒç¤¼è²Œæ˜¯ä¸å˜åœ¨çš„。没有人会相信一个如æ¤æ˜Žæ˜¾åœ°éšè—äº†ä»–ä»¬çœŸå®žæ€§æ ¼çš„äººã€‚
+
+.. [#cnf2] ä¿ç½—·西蒙演唱了“离开爱人的50ç§æ–¹æ³•â€ï¼Œå› 为å¦çŽ‡åœ°è¯´ï¼Œâ€œå‘Šè¯‰å¼€å‘者
+ 他们是D*CKHEAD" çš„100万ç§æ–¹æ³•éƒ½æ— 法确认。但我确信他已ç»è¿™ä¹ˆæƒ³äº†ã€‚
+
+3）人2 - 好人
+-------------
+
+虽然大多数人都是白痴，但ä¸å¹¸çš„是，æ®æ¤æŽ¨è®ºä½ 也是白痴，尽管我们都自我感觉良
+好，我们比普通人更好（让我们é¢å¯¹çŽ°å®žå§ï¼Œæ²¡æœ‰äººç›¸ä¿¡ä»–们是普通人或低于普通人），
+我们也应该承认我们ä¸æ˜¯æœ€é”‹åˆ©çš„åˆ€ï¼Œè€Œä¸”ä¼šæœ‰å…¶ä»–äººæ¯”ä½ æ›´ä¸åƒç™½ç—´ã€‚
+
+有些人对èªæ˜Žäººå应ä¸å¥½ã€‚其他人利用它们。
+
+ä½œä¸ºå†…æ ¸ç»´æŠ¤äººå‘˜ï¼Œç¡®ä¿æ‚¨åœ¨ç¬¬äºŒç»„ä¸ã€‚接å—ä»–ä»¬ï¼Œå› ä¸ºä»–ä»¬ä¼šè®©ä½ çš„å·¥ä½œæ›´å®¹æ˜“ã€‚
+ç‰¹åˆ«æ˜¯ï¼Œä»–ä»¬èƒ½å¤Ÿä¸ºä½ åšå†³å®šï¼Œè¿™å°±æ˜¯æ¸¸æˆçš„全部内容。
+
+æ‰€ä»¥å½“ä½ å‘çŽ°ä¸€ä¸ªæ¯”ä½ èªæ˜Žçš„人时，就顺其自然å§ã€‚ä½ çš„ç®¡ç†èŒè´£åœ¨å¾ˆå¤§ç¨‹åº¦ä¸Šå˜æˆ
+了“å¬èµ·æ¥åƒæ˜¯ä¸ªå¥½ä¸»æ„——去å°è¯•å§â€ï¼Œæˆ–者“å¬èµ·æ¥ä¸é”™ï¼Œä½†æ˜¯XXX呢？â€â€œã€‚第二个版
+本尤其是一个很好的方法，è¦ä¹ˆå¦ä¹ 一些关于“XXXâ€çš„新东西，è¦ä¹ˆé€šè¿‡æŒ‡å‡ºä¸€äº›èªæ˜Ž
+人没有想到的东西æ¥æ˜¾å¾—更具管ç†æ€§ã€‚æ— è®ºå“ªç§æƒ…å†µï¼Œä½ éƒ½ä¼šèµ¢ã€‚
+
+è¦æ³¨æ„的一件事是认识到一个领域的伟大ä¸ä¸€å®šä¼šè½¬åŒ–ä¸ºå…¶ä»–é¢†åŸŸã€‚æ‰€ä»¥ä½ å¯èƒ½ä¼šå‘
+特定的方å‘刺激人们，但让我们é¢å¯¹çŽ°å®žå§ï¼Œä»–们å¯èƒ½æ“…长他们所åšçš„事情，而且对
+其他事情都很差劲。好消æ¯æ˜¯ï¼Œäººä»¬å¾€å¾€ä¼šè‡ªç„¶è€Œç„¶åœ°é‡æ‹¾ä»–们擅长的东西，所以当
+ä½ å‘æŸä¸ªæ–¹å‘åˆºæ¿€ä»–ä»¬æ—¶ï¼Œä½ å¹¶ä¸æ˜¯åœ¨åšä¸å¯é€†è½¬çš„事情，åªæ˜¯ä¸è¦ç”¨åŠ›æŽ¨ã€‚
+
+4）责备
+-------
+
+äº‹æƒ…ä¼šå‡ºé—®é¢˜çš„ï¼Œäººä»¬å¸Œæœ›åŽ»è´£å¤‡äººã€‚è´´æ ‡ç¾ï¼Œä½ 就是å—责备的人。
+
+事实上，接å—责备并ä¸éš¾ï¼Œå°¤å…¶æ˜¯å½“人们æ„è¯†åˆ°è¿™ä¸ **全是** ä½ çš„è¿‡é”™æ—¶ã€‚è¿™è®©æˆ‘
+们找到了承担责任的最佳方å¼ï¼šä¸ºåˆ«äººæ‰¿æ‹…è¿™ä»¶äº‹ã€‚ä½ ä¼šæ„Ÿè§‰å¾ˆå¥½ï¼Œä»–ä»¬ä¼šæ„Ÿè§‰å¾ˆå¥½ï¼Œ
+没有å—到指责. é‚£è°ï¼Œå¤±åŽ»äº†ä»–们的全部36GB色情收è—çš„äººï¼Œå› ä¸ºä½ çš„æ— èƒ½å°†å‹‰å¼ºæ‰¿
+è®¤ï¼Œä½ è‡³å°‘æ²¡æœ‰è¯•å›¾é€ƒé¿è´£ä»»ã€‚
+
+然åŽè®©çœŸæ£æžç ¸äº†çš„å¼€å‘äººå‘˜ï¼ˆå¦‚æžœä½ èƒ½æ‰¾åˆ°ä»–ä»¬ï¼‰ç§ä¸‹çŸ¥é“他们æžç ¸äº†ã€‚ä¸ä»…是为
+了将æ¥å¯ä»¥é¿å…，而且为了让他们知é“ä»–ä»¬æ¬ ä½ ä¸€ä¸ªäººæƒ…ã€‚è€Œä¸”ï¼Œä¹Ÿè®¸æ›´é‡è¦çš„是，
+他们也å¯èƒ½æ˜¯èƒ½å¤Ÿè§£å†³é—®é¢˜çš„äººã€‚å› ä¸ºï¼Œè®©æˆ‘ä»¬é¢å¯¹çŽ°å®žå§ï¼Œè‚¯å®šä¸æ˜¯ä½ 。
+
+æ‰¿æ‹…è´£ä»»ä¹Ÿæ˜¯ä½ é¦–å…ˆæˆä¸ºç®¡ç†è€…çš„åŽŸå› ã€‚è¿™æ˜¯è®©äººä»¬ä¿¡ä»»ä½ ï¼Œè®©ä½ èŽ·å¾—æ½œåœ¨çš„è£è€€çš„
+ä¸€éƒ¨åˆ†ï¼Œå› ä¸ºä½ å°±æ˜¯é‚£ä¸ªä¼šè¯´â€œæˆ‘æžç ¸äº†â€çš„äººã€‚å¦‚æžœä½ å·²ç»éµå¾ªäº†ä»¥å‰çš„è§„åˆ™ï¼Œä½ çŽ°
+在已ç»å¾ˆæ“…长说了。
+
+5）应é¿å…的事情
+---------------
+
+有一件事人们甚至比被称为“笨蛋â€æ›´è®¨åŽŒï¼Œé‚£å°±æ˜¯åœ¨ä¸€ä¸ªç¥žåœ£çš„声音ä¸è¢«ç§°ä¸ºâ€œç¬¨è›‹â€ã€‚
+ç¬¬ä¸€ä¸ªä½ å¯ä»¥é“æ‰ï¼Œç¬¬äºŒä¸ªä½ ä¸ä¼šçœŸæ£å¾—到机会。å³ä½¿ä½ åšå¾—很好，他们也å¯èƒ½ä¸å†
+倾å¬ã€‚
+
+我们都认为自己比别人强，这æ„味ç€å½“别人装腔作势时，这会让我们很æ¼ç«ã€‚ä½ ä¹Ÿè®¸
+在é“å¾·å’Œæ™ºåŠ›ä¸Šæ¯”ä½ å‘¨å›´çš„æ¯ä¸ªäººéƒ½ä¼˜è¶Šï¼Œä½†ä¸è¦è¯•å›¾å¤ªæ˜Žæ˜¾ï¼Œé™¤éžä½ 真的打算激怒
+æŸäºº [#cnf3]_
+
+åŒæ ·ï¼Œä¸è¦å¯¹äº‹æƒ…太客气或太微妙。礼貌很容易è½å¾—è½èŠ±æµæ°´ï¼ŒæŠŠé—®é¢˜éšè—èµ·æ¥ï¼Œ
+æ£å¦‚他们所说，“在互è”网上，没人能å¬åˆ°ä½ çš„å«è“„。â€ç”¨ä¸€ä¸ªé’器把这一点锤进去，
+å› ä¸ºä½ ä¸èƒ½çœŸçš„ä¾é 别人æ¥èŽ·å¾—ä½ çš„è§‚ç‚¹ã€‚
+
+一些幽默å¯ä»¥å¸®åŠ©ç¼“和直率和é“德化。过度到è’谬的地æ¥ï¼Œå¯ä»¥çŒè¾“一个观点，而ä¸
+会让接å—者感到痛苦，他们åªæ˜¯è®¤ä¸ºä½ æ˜¯æ„šè ¢çš„ã€‚å› æ¤ï¼Œå®ƒå¯ä»¥å¸®åŠ©æˆ‘们摆脱对批评
+的个人心ç†éšœç¢ã€‚
+
+.. [#cnf3] æç¤ºï¼šä¸Žä½ çš„å·¥ä½œæ²¡æœ‰ç›´æŽ¥å…³ç³»çš„ç½‘ç»œæ–°é—»ç»„æ˜¯æ¶ˆé™¤ä½ å¯¹ä»–äººä¸æ»¡çš„好
+ 方法。å¶å°”写些侮辱性的帖å，打个喷åšï¼Œè®©ä½ 的情绪得到净化。别把牢骚带回家
+
+6）为什么是我？
+---------------
+
+æ—¢ç„¶ä½ çš„ä¸»è¦è´£ä»»ä¼¼ä¹Žæ˜¯ä¸ºåˆ«äººçš„é”™è¯¯æ‰¿æ‹…è´£ä»»ï¼Œå¹¶ä¸”è®©åˆ«äººç—›è‹¦åœ°æ˜Žç™½ä½ æ˜¯ä¸ç§°èŒ
+的，那么显而易è§çš„问题之一就å˜æˆäº†ä¸ºä»€ä¹ˆé¦–å…ˆè¦è¿™æ ·åšã€‚
+
+é¦–å…ˆï¼Œè™½ç„¶ä½ å¯èƒ½ä¼šæˆ–å¯èƒ½ä¸ä¼šå¬åˆ°åå‡ å²å¥³å©ï¼ˆæˆ–ç”·å©ï¼Œè®©æˆ‘们ä¸è¦åœ¨è¿™é‡Œè¯„判或
+性别æ§è§†ï¼‰æ•²ä½ çš„æ›´è¡£å®¤é—¨ï¼Œä½ ä¼šå¾—åˆ°ä¸€ä¸ªå·¨å¤§çš„ä¸ªäººæˆå°±æ„Ÿä¸ºâ€œè´Ÿè´£â€ã€‚别介æ„ä½ çœŸ
+çš„åœ¨é¢†å¯¼åˆ«äººï¼Œä½ è¦è·Ÿä¸Šåˆ«äººï¼Œå°½å¯èƒ½å¿«åœ°è¿½èµ¶ä»–们。æ¯ä¸ªäººéƒ½ä¼šè®¤ä¸ºä½ 是负责人。
+
+å¦‚æžœä½ å¯ä»¥åšåˆ°è¿™ä¸ªï¼Œ 这是个伟大的工作ï¼
diff --git a/Documentation/translations/zh_CN/process/programming-language.rst b/Documentation/translations/zh_CN/process/programming-language.rst
new file mode 100644
index 0000000000000000000000000000000000000000..51fd4ef48ea134953a82fe864ba619edaee2ca2a
--- /dev/null
+++ b/Documentation/translations/zh_CN/process/programming-language.rst
@@ -0,0 +1,41 @@
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: :ref:`Documentation/process/programming-language.rst <programming_language>`
+:Translator: Alex Shi <alex.shi@linux.alibaba.com>
+
+.. _cn_programming_language:
+
+程åºè®¾è®¡è¯è¨€
+============
+
+å†…æ ¸æ˜¯ç”¨Cè¯è¨€ [c-language]_ ç¼–å†™çš„ã€‚æ›´å‡†ç¡®åœ°è¯´ï¼Œå†…æ ¸é€šå¸¸æ˜¯ç”¨ ``gcc`` [gcc]_
+在 ``-std=gnu89`` [gcc-c-dialect-options]_ 下编译的：ISO C90的 GNU 方言（
+包括一些C99特性）
+
+è¿™ç§æ–¹è¨€åŒ…å«å¯¹è¯è¨€ [gnu-extensions]_ çš„è®¸å¤šæ‰©å±•ï¼Œå½“ç„¶ï¼Œå®ƒä»¬è®¸å¤šéƒ½åœ¨å†…æ ¸ä¸ä½¿ç”¨ã€‚
+
+对于一些体系结构，有一些使用 ``clang`` [clang]_ å’Œ ``icc`` [icc]_ ç¼–è¯‘å†…æ ¸
+的支æŒï¼Œå°½ç®¡åœ¨ç¼–写æ¤æ–‡æ¡£æ—¶è¿˜æ²¡æœ‰å®Œæˆï¼Œä»éœ€è¦ç¬¬ä¸‰æ–¹è¡¥ä¸ã€‚
+
+属性
+----
+
+åœ¨æ•´ä¸ªå†…æ ¸ä¸ä½¿ç”¨çš„一个常è§æ‰©å±•æ˜¯å±žæ€§ï¼ˆattributes） [gcc-attribute-syntax]_
+属性å…许将实现定义的è¯ä¹‰å¼•å…¥è¯è¨€å®žä½“（如å˜é‡ã€å‡½æ•°æˆ–ç±»åž‹ï¼‰ï¼Œè€Œæ— éœ€å¯¹è¯è¨€è¿›è¡Œ
+é‡å¤§çš„è¯æ³•æ›´æ”¹ï¼ˆä¾‹å¦‚æ·»åŠ æ–°å…³é”®å—） [n2049]_
+
+在æŸäº›æƒ…况下，属性是å¯é€‰çš„（å³ä¸æ”¯æŒè¿™äº›å±žæ€§çš„编译器ä»ç„¶åº”该生æˆæ£ç¡®çš„代ç ，
+å³ä½¿å…¶é€Ÿåº¦è¾ƒæ…¢æˆ–执行的编译时检查/诊æ–次数ä¸å¤Ÿï¼‰
+
+å†…æ ¸å®šä¹‰äº†ä¼ªå…³é”®å—（例如， ``pure`` ），而ä¸æ˜¯ç›´æŽ¥ä½¿ç”¨GNU属性è¯æ³•ï¼ˆä¾‹å¦‚,
+``__attribute__((__pure__))`` ），以检测å¯ä»¥ä½¿ç”¨å“ªäº›å…³é”®å—å’Œ/或缩çŸä»£ç , 具体
+请å‚阅 ``include/linux/compiler_attributes.h``
+
+.. [c-language] http://www.open-std.org/jtc1/sc22/wg14/www/standards
+.. [gcc] https://gcc.gnu.org
+.. [clang] https://clang.llvm.org
+.. [icc] https://software.intel.com/en-us/c-compilers
+.. [gcc-c-dialect-options] https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html
+.. [gnu-extensions] https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html
+.. [gcc-attribute-syntax] https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html
+.. [n2049] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2049.pdf
diff --git a/Documentation/translations/zh_CN/stable_api_nonsense.txt b/Documentation/translations/zh_CN/process/stable-api-nonsense.rst
similarity index 78%
rename from Documentation/translations/zh_CN/stable_api_nonsense.txt
rename to Documentation/translations/zh_CN/process/stable-api-nonsense.rst
index a2b27fab382c90df2adef0ab57b00fe14e5a53f9..b4ddb6e88d9db0c4bf3301f36dbcb84882fb9052 100644
--- a/Documentation/translations/zh_CN/stable_api_nonsense.txt
+++ b/Documentation/translations/zh_CN/process/stable-api-nonsense.rst
@@ -1,26 +1,18 @@
-Chinese translated version of Documentation/process/stable-api-nonsense.rst
+.. _cn_stable_api_nonsense:
-If you have any comment or update to the content, please contact the
-original document maintainer directly. However, if you have problem
-communicating in English you can also ask the Chinese maintainer for help.
-Contact the Chinese maintainer, if this translation is outdated or there
-is problem with translation.
+.. include:: ../disclaimer-zh_CN.rst
-Maintainer: Greg Kroah-Hartman <greg@kroah.com>
-Chinese maintainer: TripleX Chung <zhongyu@18mail.cn>
----------------------------------------------------------------------
-Documentation/process/stable-api-nonsense.rst çš„ä¸æ–‡ç¿»è¯‘
+:Original: :ref:`Documentation/process/stable-api-nonsense.rst
+ <stable_api_nonsense>`
-如果想评论或更新本文的内容，请直接è”ç³»åŽŸæ–‡æ¡£çš„ç»´æŠ¤è€…ã€‚å¦‚æžœä½ ä½¿ç”¨è‹±æ–‡
-交æµæœ‰å›°éš¾çš„è¯ï¼Œä¹Ÿå¯ä»¥å‘ä¸æ–‡ç‰ˆç»´æŠ¤è€…求助。如果本翻译更新ä¸åŠæ—¶æˆ–者翻
-译å˜åœ¨é—®é¢˜ï¼Œè¯·è”ç³»ä¸æ–‡ç‰ˆç»´æŠ¤è€…。
+译者::
-英文版维护者： Greg Kroah-Hartman <greg@kroah.com>
-ä¸æ–‡ç‰ˆç»´æŠ¤è€…： 钟宇 TripleX Chung <zhongyu@18mail.cn>
-ä¸æ–‡ç‰ˆç¿»è¯‘者： 钟宇 TripleX Chung <zhongyu@18mail.cn>
-ä¸æ–‡ç‰ˆæ ¡è¯‘者： æŽé˜³ Li Yang <leoli@freescale.com>
-以下为æ£æ–‡
----------------------------------------------------------------------
+ ä¸æ–‡ç‰ˆç»´æŠ¤è€…： 钟宇 TripleX Chung <xxx.phy@gmail.com>
+ ä¸æ–‡ç‰ˆç¿»è¯‘者： 钟宇 TripleX Chung <xxx.phy@gmail.com>
+ ä¸æ–‡ç‰ˆæ ¡è¯‘者： æŽé˜³ Li Yang <leoyang.li@nxp.com>
+
+Linux å†…æ ¸é©±åŠ¨æŽ¥å£
+==================
写作本文档的目的，是为了解释为什么Linuxæ—¢æ²¡æœ‰äºŒè¿›åˆ¶å†…æ ¸æŽ¥å£ï¼Œä¹Ÿæ²¡æœ‰ç¨³å®š
çš„å†…æ ¸æŽ¥å£ã€‚è¿™é‡Œæ‰€è¯´çš„å†…æ ¸æŽ¥å£ï¼Œæ˜¯æŒ‡å†…æ ¸é‡Œçš„æŽ¥å£ï¼Œè€Œä¸æ˜¯å†…æ ¸å’Œç”¨æˆ·ç©ºé—´
@@ -59,18 +51,22 @@ Linux能æˆä¸ºå¼ºå£®ï¼Œç¨³å®šï¼Œæˆç†Ÿçš„æ“ä½œç³»ç»Ÿï¼Œè¿™ä¹Ÿæ˜¯ä½ æœ€å¼€å§‹é€‰
--------------
å‡å¦‚æˆ‘ä»¬æœ‰ä¸€ä¸ªç¨³å®šçš„å†…æ ¸æºä»£ç 接å£ï¼Œé‚£ä¹ˆè‡ªç„¶è€Œç„¶çš„，我们就拥有了稳定的
二进制接å£ï¼Œæ˜¯è¿™æ ·çš„å—？错。让我们看看关于Linuxå†…æ ¸çš„å‡ ç‚¹äº‹å®žï¼š
+
- å–决于所用的C编译器的版本，ä¸åŒçš„å†…æ ¸æ•°æ®ç»“构里的结构体的对é½æ–¹
-å¼ä¼šæœ‰å·®åˆ«ï¼Œä»£ç ä¸ä¸åŒå‡½æ•°çš„表现形å¼ä¹Ÿä¸ä¸€æ ·ï¼ˆå‡½æ•°æ˜¯ä¸æ˜¯è¢«inline编译å–
-决于编译器行为）。ä¸åŒçš„函数的表现形å¼å¹¶ä¸é‡è¦ï¼Œä½†æ˜¯æ•°æ®ç»“构内部的对é½
-æ–¹å¼å¾ˆå…³é”®ã€‚
+ å¼ä¼šæœ‰å·®åˆ«ï¼Œä»£ç ä¸ä¸åŒå‡½æ•°çš„表现形å¼ä¹Ÿä¸ä¸€æ ·ï¼ˆå‡½æ•°æ˜¯ä¸æ˜¯è¢«inline
+ 编译å–决于编译器行为）。ä¸åŒçš„函数的表现形å¼å¹¶ä¸é‡è¦ï¼Œä½†æ˜¯æ•°æ®
+ 结构内部的对é½æ–¹å¼å¾ˆå…³é”®ã€‚
+
- å–å†³äºŽå†…æ ¸çš„é…置选项，ä¸åŒçš„é€‰é¡¹ä¼šè®©å†…æ ¸çš„å¾ˆå¤šä¸œè¥¿å‘生改å˜ï¼š
+
- åŒä¸€ä¸ªç»“构体å¯èƒ½åŒ…å«ä¸åŒçš„æˆå‘˜å˜é‡
- 有的函数å¯èƒ½æ ¹æœ¬ä¸ä¼šè¢«å®žçŽ°ï¼ˆæ¯”如编译的时候没有选择SMP支æŒ
-，一些é”函数就会被定义æˆç©ºå‡½æ•°ï¼‰ã€‚
+ 一些é”函数就会被定义æˆç©ºå‡½æ•°ï¼‰ã€‚
- å†…æ ¸ä½¿ç”¨çš„å†…å˜ä¼šä»¥ä¸åŒçš„æ–¹å¼å¯¹é½ï¼Œè¿™å–决于ä¸åŒçš„å†…æ ¸é…置选
-项。
+ 项。
+
- Linuxå¯ä»¥åœ¨å¾ˆå¤šçš„ä¸åŒä½“系结构的处ç†å™¨ä¸Šè¿è¡Œã€‚在æŸä¸ªä½“系结构上编
-译好的二进制驱动程åºï¼Œä¸å¯èƒ½åœ¨å¦å¤–一个体系结构上æ£ç¡®çš„è¿è¡Œã€‚
+ 译好的二进制驱动程åºï¼Œä¸å¯èƒ½åœ¨å¦å¤–一个体系结构上æ£ç¡®çš„è¿è¡Œã€‚
å¯¹äºŽä¸€ä¸ªç‰¹å®šçš„å†…æ ¸ï¼Œæ»¡è¶³è¿™äº›æ¡ä»¶å¹¶ä¸éš¾ï¼Œä½¿ç”¨åŒä¸€ä¸ªC编译器和åŒæ ·çš„å†…æ ¸é…
置选项æ¥ç¼–译驱动程åºæ¨¡å—å°±å¯ä»¥äº†ã€‚这对于给一个特定Linuxå‘布的特定版本æ
@@ -90,7 +86,7 @@ Linux能æˆä¸ºå¼ºå£®ï¼Œç¨³å®šï¼Œæˆç†Ÿçš„æ“ä½œç³»ç»Ÿï¼Œè¿™ä¹Ÿæ˜¯ä½ æœ€å¼€å§‹é€‰
如果有人ä¸å°†ä»–çš„å†…æ ¸é©±åŠ¨ç¨‹åºï¼Œæ”¾å…¥å…¬ç‰ˆå†…æ ¸çš„æºä»£ç æ ‘ï¼Œè€Œåˆæƒ³è®©é©±åŠ¨ç¨‹åº
一直ä¿æŒåœ¨æœ€æ–°çš„å†…æ ¸ä¸å¯ç”¨ï¼Œé‚£ä¹ˆè¿™ä¸ªè¯é¢˜å°†ä¼šå˜å¾—没完没了。
- å†…æ ¸å¼€å‘是æŒç»è€Œä¸”快节å¥çš„，从æ¥éƒ½ä¸ä¼šæ…¢ä¸‹æ¥ã€‚å†…æ ¸å¼€å‘人员在当å‰æŽ¥å£ä¸
+å†…æ ¸å¼€å‘是æŒç»è€Œä¸”快节å¥çš„，从æ¥éƒ½ä¸ä¼šæ…¢ä¸‹æ¥ã€‚å†…æ ¸å¼€å‘人员在当å‰æŽ¥å£ä¸
找到bug，或者找到更好的实现方å¼ã€‚一旦å‘现这些，他们就很快会去修改当å‰çš„
接å£ã€‚修改接å£æ„味ç€ï¼Œå‡½æ•°åå¯èƒ½ä¼šæ”¹å˜ï¼Œç»“构体å¯èƒ½è¢«æ‰©å……æˆ–è€…åˆ å‡ï¼Œå‡½æ•°
çš„å‚数也å¯èƒ½å‘生改å˜ã€‚一旦接å£è¢«ä¿®æ”¹ï¼Œå†…æ ¸ä¸ä½¿ç”¨è¿™äº›æŽ¥å£çš„地方需è¦åŒæ—¶
@@ -98,21 +94,22 @@ Linux能æˆä¸ºå¼ºå£®ï¼Œç¨³å®šï¼Œæˆç†Ÿçš„æ“ä½œç³»ç»Ÿï¼Œè¿™ä¹Ÿæ˜¯ä½ æœ€å¼€å§‹é€‰
举一个例åï¼Œå†…æ ¸çš„USB驱动程åºæŽ¥å£åœ¨USBå系统的整个生命周期ä¸ï¼Œè‡³å°‘ç»åŽ†
了三次é‡å†™ã€‚这些é‡å†™è§£å†³ä»¥ä¸‹é—®é¢˜ï¼š
+
- 把数æ®æµä»ŽåŒæ¥æ¨¡å¼æ”¹æˆéžåŒæ¥æ¨¡å¼ï¼Œè¿™ä¸ªæ”¹åŠ¨å‡å°‘了一些驱动程åºçš„
-å¤æ‚度，æ高了所有USB驱动程åºçš„åžåçŽ‡ï¼Œè¿™æ ·å‡ ä¹Žæ‰€æœ‰çš„USB设备都能以最大
-速率工作了。
+ å¤æ‚度，æ高了所有USB驱动程åºçš„åžåçŽ‡ï¼Œè¿™æ ·å‡ ä¹Žæ‰€æœ‰çš„USB设备都
+ 能以最大速率工作了。
- 修改了USBæ ¸å¿ƒä»£ç ä¸ä¸ºUSB驱动分é…æ•°æ®åŒ…内å˜çš„æ–¹å¼ï¼Œæ‰€æœ‰çš„驱动都
-需è¦æ供更多的å‚æ•°ç»™USBæ ¸å¿ƒï¼Œä»¥ä¿®æ£äº†å¾ˆå¤šå·²ç»è¢«è®°å½•åœ¨æ¡ˆçš„æ»é”。
+ 需è¦æ供更多的å‚æ•°ç»™USBæ ¸å¿ƒï¼Œä»¥ä¿®æ£äº†å¾ˆå¤šå·²ç»è¢«è®°å½•åœ¨æ¡ˆçš„æ»é”。
这和一些å°é—æºä»£ç çš„æ“作系统形æˆé²œæ˜Žçš„对比，在那些æ“作系统上，ä¸å¾—ä¸é¢
外的维护旧的USB接å£ã€‚这导致了一个å¯èƒ½æ€§ï¼Œæ–°çš„å¼€å‘者ä¾ç„¶ä¼šä¸å°å¿ƒä½¿ç”¨æ—§çš„
接å£ï¼Œä»¥ä¸æ°å½“çš„æ–¹å¼ç¼–写代ç ，进而影å“到æ“作系统的稳定性。
- 在上é¢çš„例åä¸ï¼Œæ‰€æœ‰çš„å¼€å‘者都åŒæ„这些é‡è¦çš„æ”¹åŠ¨ï¼Œåœ¨è¿™æ ·çš„æƒ…å†µä¸‹ä¿®æ”¹ä»£
+在上é¢çš„例åä¸ï¼Œæ‰€æœ‰çš„å¼€å‘者都åŒæ„这些é‡è¦çš„æ”¹åŠ¨ï¼Œåœ¨è¿™æ ·çš„æƒ…å†µä¸‹ä¿®æ”¹ä»£
价很低。如果Linuxä¿æŒä¸€ä¸ªç¨³å®šçš„å†…æ ¸æºä»£ç 接å£ï¼Œé‚£ä¹ˆå°±å¾—创建一个新的接å£
；旧的，有问题的接å£å¿…须一直维护，给Linux USBå¼€å‘者带æ¥é¢å¤–的工作。既然
所有的Linux USB驱动的作者都是利用自己的时间工作，那么è¦æ±‚他们去åšæ¯«æ— æ„
义的å…è´¹é¢å¤–工作，是ä¸å¯èƒ½çš„。
- 安全问题对Linuxæ¥è¯´å分é‡è¦ã€‚一个安全问题被å‘现，就会在çŸæ—¶é—´å†…得到修
+安全问题对Linuxæ¥è¯´å分é‡è¦ã€‚一个安全问题被å‘现，就会在çŸæ—¶é—´å†…得到修
æ£ã€‚在很多情况下，这将导致Linuxå†…æ ¸ä¸çš„一些接å£è¢«é‡å†™ï¼Œä»¥ä»Žæ ¹æœ¬ä¸Šé¿å…安
全问题。一旦接å£è¢«é‡å†™ï¼Œæ‰€æœ‰ä½¿ç”¨è¿™äº›æŽ¥å£çš„驱动程åºï¼Œå¿…é¡»åŒæ—¶å¾—到修æ£ï¼Œ
以确定安全问题已ç»å¾—到修å¤å¹¶ä¸”ä¸å¯èƒ½åœ¨æœªæ¥è¿˜æœ‰åŒæ ·çš„å®‰å…¨é—®é¢˜ã€‚å¦‚æžœå†…æ ¸
@@ -124,7 +121,7 @@ Linux能æˆä¸ºå¼ºå£®ï¼Œç¨³å®šï¼Œæˆç†Ÿçš„æ“ä½œç³»ç»Ÿï¼Œè¿™ä¹Ÿæ˜¯ä½ æœ€å¼€å§‹é€‰
è¦åšä»€ä¹ˆ
--------
+--------
å¦‚æžœä½ å†™äº†ä¸€ä¸ªLinuxå†…æ ¸é©±åŠ¨ï¼Œä½†æ˜¯å®ƒè¿˜ä¸åœ¨Linuxæºä»£ç æ ‘é‡Œï¼Œä½œä¸ºä¸€ä¸ªå¼€å‘
è€…ï¼Œä½ åº”è¯¥æ€Žä¹ˆåšï¼Ÿä¸ºæ¯ä¸ªå‘布的æ¯ä¸ªç‰ˆæœ¬æ供一个二进制驱动，那简直是一个
@@ -137,20 +134,21 @@ Linux能æˆä¸ºå¼ºå£®ï¼Œç¨³å®šï¼Œæˆç†Ÿçš„æ“ä½œç³»ç»Ÿï¼Œè¿™ä¹Ÿæ˜¯ä½ æœ€å¼€å§‹é€‰
åšä»€ä¹ˆäº‹æƒ…。
æŠŠé©±åŠ¨æ”¾åˆ°å†…æ ¸æºä»£ç æ ‘é‡Œä¼šæœ‰å¾ˆå¤šçš„å¥½å¤„ï¼š
+
- 驱动的质é‡ä¼šæå‡ï¼Œè€Œç»´æŠ¤æˆæœ¬ï¼ˆå¯¹åŽŸå§‹ä½œè€…æ¥è¯´ï¼‰ä¼šä¸‹é™ã€‚
- å…¶ä»–äººä¼šç»™é©±åŠ¨æ·»åŠ æ–°ç‰¹æ€§ã€‚
- 其他人会找到驱动ä¸çš„bug并修å¤ã€‚
- 其他人会在驱动ä¸æ‰¾åˆ°æ€§èƒ½ä¼˜åŒ–的机会。
- 当外部的接å£çš„改å˜éœ€è¦ä¿®æ”¹é©±åŠ¨ç¨‹åºçš„时候，其他人会修改驱动程åº
-。
- ä¸éœ€è¦è”系任何å‘行商，这个驱动会自动的éšç€æ‰€æœ‰çš„Linuxå‘布一起å‘
-布。
+ 布。
和别的æ“作系统相比，Linux为更多ä¸åŒçš„设备æ供现æˆçš„驱动，而且能在更多ä¸
åŒä½“系结构的处ç†å™¨ä¸Šæ”¯æŒè¿™äº›è®¾å¤‡ã€‚这个ç»è¿‡è€ƒéªŒçš„å¼€å‘模å¼ï¼Œå¿…然是错ä¸äº†
çš„ :)
--------------
+æ„Ÿè°¢
+----
æ„Ÿè°¢ Randy Dunlap, Andrew Morton, David Brownell, Hanna Linder,
Robert Love, and Nishanth Aravamudan 对于本文档早期版本的评审和建议。
diff --git a/Documentation/translations/zh_CN/stable_kernel_rules.txt b/Documentation/translations/zh_CN/process/stable-kernel-rules.rst
similarity index 74%
rename from Documentation/translations/zh_CN/stable_kernel_rules.txt
rename to Documentation/translations/zh_CN/process/stable-kernel-rules.rst
index db4ba5a0c39aa881caf0f9409ea2bd31eb71f0ff..fba361f2ddfdcfa5c4a375cc1eff8be13a74fcd0 100644
--- a/Documentation/translations/zh_CN/stable_kernel_rules.txt
+++ b/Documentation/translations/zh_CN/process/stable-kernel-rules.rst
@@ -1,31 +1,26 @@
-Chinese translated version of Documentation/process/stable-kernel-rules.rst
+.. _cn_stable_kernel_rules:
-If you have any comment or update to the content, please contact the
-original document maintainer directly. However, if you have a problem
-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.
+.. include:: ../disclaimer-zh_CN.rst
-Chinese maintainer: TripleX Chung <triplex@zh-kernel.org>
----------------------------------------------------------------------
-Documentation/process/stable-kernel-rules.rst çš„ä¸æ–‡ç¿»è¯‘
+:Original: :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
如果想评论或更新本文的内容，请直接è”ç³»åŽŸæ–‡æ¡£çš„ç»´æŠ¤è€…ã€‚å¦‚æžœä½ ä½¿ç”¨è‹±æ–‡
交æµæœ‰å›°éš¾çš„è¯ï¼Œä¹Ÿå¯ä»¥å‘ä¸æ–‡ç‰ˆç»´æŠ¤è€…求助。如果本翻译更新ä¸åŠæ—¶æˆ–者翻
-译å˜åœ¨é—®é¢˜ï¼Œè¯·è”ç³»ä¸æ–‡ç‰ˆç»´æŠ¤è€…。
+译å˜åœ¨é—®é¢˜ï¼Œè¯·è”ç³»ä¸æ–‡ç‰ˆç»´æŠ¤è€…::
+ ä¸æ–‡ç‰ˆç»´æŠ¤è€…： 钟宇 TripleX Chung <xxx.phy@gmail.com>
+ ä¸æ–‡ç‰ˆç¿»è¯‘者： 钟宇 TripleX Chung <xxx.phy@gmail.com>
+ ä¸æ–‡ç‰ˆæ ¡è¯‘者：
+ - æŽé˜³ Li Yang <leoyang.li@nxp.com>
+ - Kangkai Yin <e12051@motorola.com>
-ä¸æ–‡ç‰ˆç»´æŠ¤è€…： 钟宇 TripleX Chung <triplex@zh-kernel.org>
-ä¸æ–‡ç‰ˆç¿»è¯‘者： 钟宇 TripleX Chung <triplex@zh-kernel.org>
-ä¸æ–‡ç‰ˆæ ¡è¯‘者： æŽé˜³ Li Yang <leo@zh-kernel.org>
- Kangkai Yin <e12051@motorola.com>
-
-以下为æ£æ–‡
----------------------------------------------------------------------
+æ‰€æœ‰ä½ æƒ³çŸ¥é“的事情 - 关于linux稳定版å‘布
+========================================
关于Linux 2.6稳定版å‘å¸ƒï¼Œæ‰€æœ‰ä½ æƒ³çŸ¥é“的事情。
关于哪些类型的补ä¸å¯ä»¥è¢«æŽ¥æ”¶è¿›å…¥ç¨³å®šç‰ˆä»£ç æ ‘ï¼Œå“ªäº›ä¸å¯ä»¥çš„规则：
+----------------------------------------------------------------
- 必须是显而易è§çš„æ£ç¡®ï¼Œå¹¶ä¸”ç»è¿‡æµ‹è¯•çš„。
- è¿žåŒä¸Šä¸‹æ–‡ï¼Œä¸èƒ½å¤§äºŽ100行。
@@ -38,9 +33,10 @@ Documentation/process/stable-kernel-rules.rst çš„ä¸æ–‡ç¿»è¯‘
- 没有“ç†è®ºä¸Šçš„竞争æ¡ä»¶â€ï¼Œé™¤éžèƒ½ç»™å‡ºç«žäº‰æ¡ä»¶å¦‚何被利用的解释。
- ä¸èƒ½å˜åœ¨ä»»ä½•çš„“ç碎的â€ä¿®æ£ï¼ˆæ‹¼å†™ä¿®æ£ï¼ŒåŽ»æŽ‰å¤šä½™ç©ºæ ¼ä¹‹ç±»çš„）。
- 必须被相关å系统的维护者接å—。
- - å¿…é¡»éµå¾ªDocumentation/process/submitting-patches.rst里的规则。
+ - å¿…é¡»éµå¾ªDocumentation/translations/zh_CN/process/submitting-patches.rst里的规则。
å‘稳定版代ç æ ‘æ交补ä¸çš„过程：
+------------------------------
- 在确认了补ä¸ç¬¦åˆä»¥ä¸Šçš„规则åŽï¼Œå°†è¡¥ä¸å‘é€åˆ°stable@vger.kernel.org。
- 如果补ä¸è¢«æŽ¥å—到队列里，å‘é€è€…会收到一个ACK回å¤ï¼Œå¦‚果没有被接å—，收
@@ -49,6 +45,7 @@ Documentation/process/stable-kernel-rules.rst çš„ä¸æ–‡ç¿»è¯‘
- 安全方é¢çš„è¡¥ä¸ä¸è¦å‘到这个列表，应该å‘é€åˆ°security@kernel.org。
审查周期：
+----------
- 当稳定版的维护者决定开始一个审查周期，补ä¸å°†è¢«å‘é€åˆ°å®¡æŸ¥å§”员会，以
åŠè¢«è¡¥ä¸å½±å“的领域的维护者（除éžæ交者就是该领域的维护者）并且抄é€
@@ -63,4 +60,5 @@ Documentation/process/stable-kernel-rules.rst çš„ä¸æ–‡ç¿»è¯‘
通常的审查周期。请è”ç³»å†…æ ¸å®‰å…¨å°ç»„以获得关于这个过程的更多细节。
审查委员会：
+------------
- ç”±ä¸€äº›è‡ªæ„¿æ‰¿æ‹…è¿™é¡¹ä»»åŠ¡çš„å†…æ ¸å¼€å‘è€…ï¼Œå’Œå‡ ä¸ªéžå¿—愿的组æˆã€‚
diff --git a/Documentation/translations/zh_CN/process/submit-checklist.rst b/Documentation/translations/zh_CN/process/submit-checklist.rst
new file mode 100644
index 0000000000000000000000000000000000000000..89061aa8fdbef67731e1db8b22ef3af62154d584
--- /dev/null
+++ b/Documentation/translations/zh_CN/process/submit-checklist.rst
@@ -0,0 +1,107 @@
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: :ref:`Documentation/process/submit-checklist.rst <submitchecklist>`
+:Translator: Alex Shi <alex.shi@linux.alibaba.com>
+
+.. _cn_submitchecklist:
+
+Linuxå†…æ ¸è¡¥ä¸æ交清å•
+~~~~~~~~~~~~~~~~~~~~~
+
+如果开å‘äººå‘˜å¸Œæœ›çœ‹åˆ°ä»–ä»¬çš„å†…æ ¸è¡¥ä¸æ交更快地被接å—，那么他们应该åšä¸€äº›åŸºæœ¬
+的事情。
+
+这些都是在
+:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
+和其他有关æ交Linuxå†…æ ¸è¡¥ä¸çš„文档ä¸æ供的。
+
+1) 如果使用工具，则包括定义/声明该工具的文件。ä¸è¦ä¾èµ–于其他头文件拉入您使用
+ 的头文件。
+
+2) 干净的编译：
+
+ a) 使用适用或修改的 ``CONFIG`` 选项 ``=y``ã€``=m`` å’Œ ``=n`` 。没有GCC
+ è¦å‘Š/错误，没有链接器è¦å‘Š/错误。
+
+ b) 通过allnoconfigã€allmodconfig
+
+ c) 使用 ``O=builddir`` æ—¶å¯ä»¥æˆåŠŸç¼–译
+
+3) 通过使用本地交å‰ç¼–译工具或其他一些构建场在多个CPU体系结构上构建。
+
+4) PPC64是一ç§å¾ˆå¥½çš„交å‰ç¼–è¯‘æ£€æŸ¥ä½“ç³»ç»“æž„ï¼Œå› ä¸ºå®ƒå€¾å‘于对64ä½çš„æ•°ä½¿ç”¨æ— ç¬¦å·
+ 长整型。
+
+5) 如下所述 :ref:`Documentation/translations/zh_CN/process/coding-style.rst <cn_codingstyle>`.
+ 检查您的补ä¸æ˜¯å¦ä¸ºå¸¸è§„æ ·å¼ã€‚在æ交（ ``scripts/check patch.pl`` ）之å‰ï¼Œ
+ 使用补ä¸æ ·å¼æ£€æŸ¥å™¨æ£€æŸ¥æ˜¯å¦æœ‰è½»å¾®çš„冲çªã€‚您应该能够处ç†æ‚¨çš„è¡¥ä¸ä¸å˜åœ¨çš„所有
+ è¿è§„行为。
+
+6) 任何新的或修改过的 ``CONFIG`` 选项都ä¸ä¼šå¼„è„é…ç½®èœå•ï¼Œå¹¶é»˜è®¤ä¸ºå…³é—，除éž
+ å®ƒä»¬ç¬¦åˆ ``Documentation/kbuild/kconfig-language.txt`` ä¸è®°å½•çš„异常æ¡ä»¶,
+ èœå•å±žæ€§ï¼šé»˜è®¤å€¼.
+
+7) 所有新的 ``kconfig`` 选项都有帮助文本。
+
+8) 已仔细审查了相关的 ``Kconfig`` 组åˆã€‚这很难用测试æ¥çº æ£â€”—脑力在这里是有
+ 回报的。
+
+9) 用 sparse 检查干净。
+
+10) 使用 ``make checkstack`` å’Œ ``make namespacecheck`` 并修å¤ä»–们å‘现的任何
+ 问题。
+
+ .. note::
+
+ ``checkstack`` å¹¶æ²¡æœ‰æ˜Žç¡®æŒ‡å‡ºé—®é¢˜ï¼Œä½†æ˜¯ä»»ä½•ä¸€ä¸ªåœ¨å †æ ˆä¸Šä½¿ç”¨è¶…è¿‡512
+ å—节的函数都å¯ä»¥è¿›è¡Œæ›´æ”¹ã€‚
+
+11) 包括 :ref:`kernel-doc <kernel_doc>` å†…æ ¸æ–‡æ¡£ä»¥è®°å½•å…¨å±€å†…æ ¸API。（é™æ€å‡½æ•°
+ ä¸éœ€è¦ï¼Œä½†ä¹Ÿå¯ä»¥ã€‚）使用 ``make htmldocs`` 或 ``make pdfdocs`` 检查
+ :ref:`kernel-doc <kernel_doc>` 并修å¤ä»»ä½•é—®é¢˜ã€‚
+
+12) 通过以下选项åŒæ—¶å¯ç”¨çš„测试 ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``,
+ ``CONFIG_DEBUG_SLAB``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``,
+ ``CONFIG_DEBUG_SPINLOCK``, ``CONFIG_DEBUG_ATOMIC_SLEEP``,
+ ``CONFIG_PROVE_RCU`` and ``CONFIG_DEBUG_OBJECTS_RCU_HEAD``
+
+13) å·²ç»è¿‡æž„建和è¿è¡Œæ—¶æµ‹è¯•ï¼ŒåŒ…括有或没有 ``CONFIG_SMP``, ``CONFIG_PREEMPT``.
+
+14) 如果补ä¸ç¨‹åºå½±å“IO/ç£ç›˜ç‰ï¼šä½¿ç”¨æˆ–ä¸ä½¿ç”¨ ``CONFIG_LBDAF`` 进行测试。
+
+15) 所有代ç 路径都已在å¯ç”¨æ‰€æœ‰lockdep功能的情况下è¿è¡Œã€‚
+
+16) 所有新的/procæ¡ç›®éƒ½è®°å½•åœ¨ ``Documentation/``
+
+17) æ‰€æœ‰æ–°çš„å†…æ ¸å¼•å¯¼å‚数都记录在
+ Documentation/admin-guide/kernel-parameters.rst ä¸ã€‚
+
+18) 所有新的模å—å‚数都记录在 ``MODULE_PARM_DESC()``
+
+19) 所有新的用户空间接å£éƒ½è®°å½•åœ¨ ``Documentation/ABI/`` ä¸ã€‚有关详细信æ¯ï¼Œ
+ 请å‚阅 ``Documentation/ABI/README`` 。更改用户空间接å£çš„è¡¥ä¸åº”该抄é€
+ linux-api@vger.kernel.org。
+
+20) 检查是å¦å…¨éƒ¨é€šè¿‡ ``make headers_check`` 。
+
+21) 已通过至少注入slabå’Œpage分é…失败进行检查。请å‚阅 ``Documentation/fault-injection/``
+ 如果新代ç æ˜¯å®žè´¨æ€§çš„ï¼Œé‚£ä¹ˆæ·»åŠ å系统特定的故障注入å¯èƒ½æ˜¯åˆé€‚的。
+
+22) æ–°æ·»åŠ çš„ä»£ç å·²ç»ç”¨ ``gcc -W`` 编译（使用 ``make EXTRA-CFLAGS=-W`` ）。这
+ 将产生大é‡å™ªå£°ï¼Œä½†å¯¹äºŽæŸ¥æ‰¾è¯¸å¦‚“è¦å‘Šï¼šæœ‰ç¬¦å·å’Œæ— 符å·ä¹‹é—´çš„比较â€ä¹‹ç±»çš„错误
+ 很有用。
+
+23) 在它被åˆå¹¶åˆ°-mmè¡¥ä¸é›†ä¸ä¹‹åŽè¿›è¡Œæµ‹è¯•ï¼Œä»¥ç¡®ä¿å®ƒä»ç„¶ä¸Žæ‰€æœ‰å…¶ä»–排队的补ä¸ä»¥
+ åŠVMã€VFS和其他å系统ä¸çš„å„ç§æ›´æ”¹ä¸€èµ·å·¥ä½œã€‚
+
+24) 所有内å˜å±éšœä¾‹å¦‚ ``barrier()``, ``rmb()``, ``wmb()`` 都需è¦æºä»£ç ä¸çš„注
+ 释æ¥è§£é‡Šå®ƒä»¬æ£åœ¨æ‰§è¡Œçš„æ“作åŠå…¶åŽŸå› 的逻辑。
+
+25) 如果补ä¸æ·»åŠ 了任何ioctl，那么也è¦æ›´æ–° ``Documentation/ioctl/ioctl-number.txt``
+
+26) 如果修改åŽçš„æºä»£ç ä¾èµ–或使用与以下 ``Kconfig`` 符å·ç›¸å…³çš„ä»»ä½•å†…æ ¸API或
+ 功能，则在ç¦ç”¨ç›¸å…³ ``Kconfig`` 符å·å’Œ/或 ``=m`` （如果该选项å¯ç”¨ï¼‰çš„情况
+ 下测试以下多个构建[并éžæ‰€æœ‰è¿™äº›éƒ½åŒæ—¶å˜åœ¨ï¼Œåªæ˜¯å®ƒä»¬çš„å„ç§/éšæœºç»„åˆ]：
+
+ ``CONFIG_SMP``, ``CONFIG_SYSFS``, ``CONFIG_PROC_FS``, ``CONFIG_INPUT``, ``CONFIG_PCI``, ``CONFIG_BLOCK``, ``CONFIG_PM``, ``CONFIG_MAGIC_SYSRQ``,
+ ``CONFIG_NET``, ``CONFIG_INET=n`` (但是åŽè€…ä¼´éš ``CONFIG_NET=y``).
diff --git a/Documentation/translations/zh_CN/SubmittingDrivers b/Documentation/translations/zh_CN/process/submitting-drivers.rst
similarity index 85%
rename from Documentation/translations/zh_CN/SubmittingDrivers
rename to Documentation/translations/zh_CN/process/submitting-drivers.rst
index 15e73562f710c9002a154b4d6864ceb8d41b8b96..72c6cd935821d9ed6941f465f8530763507391cc 100644
--- a/Documentation/translations/zh_CN/SubmittingDrivers
+++ b/Documentation/translations/zh_CN/process/submitting-drivers.rst
@@ -1,36 +1,28 @@
-Chinese translated version of Documentation/process/submitting-drivers.rst
+.. _cn_submittingdrivers:
-If you have any comment or update to the content, please contact the
-original document maintainer directly. However, if you have a problem
-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.
+.. include:: ../disclaimer-zh_CN.rst
-Chinese maintainer: Li Yang <leo@zh-kernel.org>
----------------------------------------------------------------------
-Documentation/process/submitting-drivers.rst çš„ä¸æ–‡ç¿»è¯‘
+:Original: :ref:`Documentation/process/submitting-drivers.rst
+ <submittingdrivers>`
如果想评论或更新本文的内容，请直接è”ç³»åŽŸæ–‡æ¡£çš„ç»´æŠ¤è€…ã€‚å¦‚æžœä½ ä½¿ç”¨è‹±æ–‡
交æµæœ‰å›°éš¾çš„è¯ï¼Œä¹Ÿå¯ä»¥å‘ä¸æ–‡ç‰ˆç»´æŠ¤è€…求助。如果本翻译更新ä¸åŠæ—¶æˆ–者翻
-译å˜åœ¨é—®é¢˜ï¼Œè¯·è”ç³»ä¸æ–‡ç‰ˆç»´æŠ¤è€…。
+译å˜åœ¨é—®é¢˜ï¼Œè¯·è”ç³»ä¸æ–‡ç‰ˆç»´æŠ¤è€…::
-ä¸æ–‡ç‰ˆç»´æŠ¤è€…： æŽé˜³ Li Yang <leo@zh-kernel.org>
-ä¸æ–‡ç‰ˆç¿»è¯‘者： æŽé˜³ Li Yang <leo@zh-kernel.org>
-ä¸æ–‡ç‰ˆæ ¡è¯‘者： é™ˆç¦ Maggie Chen <chenqi@beyondsoft.com>
- çŽ‹èª Wang Cong <xiyou.wangcong@gmail.com>
- å¼ å· Zhang Wei <Wei.Zhang@freescale.com>
-
-以下为æ£æ–‡
----------------------------------------------------------------------
+ ä¸æ–‡ç‰ˆç»´æŠ¤è€…： æŽé˜³ Li Yang <leoyang.li@nxp.com>
+ ä¸æ–‡ç‰ˆç¿»è¯‘者： æŽé˜³ Li Yang <leoyang.li@nxp.com>
+ ä¸æ–‡ç‰ˆæ ¡è¯‘者： é™ˆç¦ Maggie Chen <chenqi@beyondsoft.com>
+ çŽ‹èª Wang Cong <xiyou.wangcong@gmail.com>
+ å¼ å· Zhang Wei <wezhang@outlook.com>
å¦‚ä½•å‘ Linux å†…æ ¸æ交驱动程åº
------------------------------
+=============================
这篇文档将会解释如何å‘ä¸åŒçš„å†…æ ¸æºç æ ‘æ交设备驱动程åºã€‚请注æ„ï¼Œå¦‚æžœä½ æ„Ÿ
兴趣的是显å¡é©±åŠ¨ç¨‹åºï¼Œä½ 也许应该访问 XFree86 项目(http://www.xfree86.org/)
å’Œï¼æˆ– X.org 项目 (http://x.org)。
-å¦è¯·å‚阅 Documentation/process/submitting-patches.rst 文档。
+å¦è¯·å‚阅 Documentation/Documentation/translations/zh_CN/process/submitting-patches.rst 文档。
分é…设备å·
@@ -145,9 +137,13 @@ Linux 设备驱动程åºï¼Œç¬¬ä¸‰ç‰ˆï¼ˆæŽ¢è®¨ 2.6.10 ç‰ˆå†…æ ¸ï¼‰ï¼š
LWN.net:
æ¯å‘¨å†…æ ¸å¼€å‘æ´»åŠ¨æ‘˜è¦ - http://lwn.net/
+
2.6 ç‰ˆä¸ API çš„å˜æ›´ï¼š
+
http://lwn.net/Articles/2.6-kernel-api/
+
å°†æ—§ç‰ˆå†…æ ¸çš„é©±åŠ¨ç¨‹åºç§»æ¤åˆ° 2.6 版：
+
http://lwn.net/Articles/driver-porting/
å†…æ ¸æ–°æ‰‹(KernelNewbies):
diff --git a/Documentation/translations/zh_CN/process/submitting-patches.rst b/Documentation/translations/zh_CN/process/submitting-patches.rst
new file mode 100644
index 0000000000000000000000000000000000000000..437c23b367bb36a1cc9801aa47b7accab6fcb888
--- /dev/null
+++ b/Documentation/translations/zh_CN/process/submitting-patches.rst
@@ -0,0 +1,682 @@
+.. _cn_submittingpatches:
+
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
+
+译者::
+
+ ä¸æ–‡ç‰ˆç»´æŠ¤è€…： 钟宇 TripleX Chung <xxx.phy@gmail.com>
+ ä¸æ–‡ç‰ˆç¿»è¯‘者： 钟宇 TripleX Chung <xxx.phy@gmail.com>
+ 时奎亮 Alex Shi <alex.shi@linux.alibaba.com>
+ ä¸æ–‡ç‰ˆæ ¡è¯‘者： æŽé˜³ Li Yang <leoyang.li@nxp.com>
+ çŽ‹èª Wang Cong <xiyou.wangcong@gmail.com>
+
+
+å¦‚ä½•è®©ä½ çš„æ”¹åŠ¨è¿›å…¥å†…æ ¸
+======================
+
+对于想è¦å°†æ”¹åŠ¨æ交到 Linux å†…æ ¸çš„ä¸ªäººæˆ–è€…å…¬å¸æ¥è¯´ï¼Œå¦‚æžœä¸ç†Ÿæ‚‰â€œè§„矩â€ï¼Œ
+æ交的æµç¨‹ä¼šè®©äººç•æƒ§ã€‚本文档收集了一系列建议，这些建议å¯ä»¥å¤§å¤§çš„æ高ä½
+的改动被接å—的机会.
+
+以下文档å«æœ‰å¤§é‡ç®€æ´çš„建议， 具体请è§ï¼š
+:ref:`Documentation/process <development_process_main>`
+åŒæ ·ï¼Œ:ref:`Documentation/translations/zh_CN/process/submit-checklist.rst <cn_submitchecklist>`
+给出在æ交代ç å‰éœ€è¦æ£€æŸ¥çš„é¡¹ç›®çš„åˆ—è¡¨ã€‚å¦‚æžœä½ åœ¨æ交一个驱动程åºï¼Œé‚£ä¹ˆ
+åŒæ—¶é˜…读一下:
+:ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>`
+
+å…¶ä¸è®¸å¤šæ¥éª¤æ述了Git版本控制系统的默认行为；如果您使用Gitæ¥å‡†å¤‡è¡¥ä¸ï¼Œ
+您将å‘现它为您完æˆçš„大部分机械工作，尽管您ä»ç„¶éœ€è¦å‡†å¤‡å’Œè®°å½•ä¸€ç»„åˆç†çš„
+è¡¥ä¸ã€‚一般æ¥è¯´ï¼Œä½¿ç”¨gitå°†ä½¿æ‚¨ä½œä¸ºå†…æ ¸å¼€å‘人员的生活更轻æ¾ã€‚
+
+
+0) 获å–当å‰æºç æ ‘
+-----------------
+
+如果您没有一个å¯ä»¥ä½¿ç”¨å½“å‰å†…æ ¸æºä»£ç çš„å˜å‚¨åº“，请使用git获å–一个。您将è¦
+从主线å˜å‚¨åº“开始，它å¯ä»¥é€šè¿‡ä»¥ä¸‹æ–¹å¼èŽ·å–::
+
+ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
+
+但是，请注æ„，您å¯èƒ½ä¸å¸Œæœ›ç›´æŽ¥é’ˆå¯¹ä¸»çº¿æ ‘进行开å‘。大多数å系统维护人员è¿
+è¡Œè‡ªå·±çš„æ ‘ï¼Œå¹¶å¸Œæœ›çœ‹åˆ°é’ˆå¯¹è¿™äº›æ ‘å‡†å¤‡çš„è¡¥ä¸ã€‚请å‚è§MAINTAINERS文件ä¸åç³»
+统的 **T:** é¡¹ä»¥æŸ¥æ‰¾è¯¥æ ‘ï¼Œæˆ–è€…ç®€å•åœ°è¯¢é—®ç»´æŠ¤è€…è¯¥æ ‘æ˜¯å¦æœªåœ¨å…¶ä¸åˆ—出。
+
+ä»ç„¶å¯ä»¥é€šè¿‡tarballsä¸‹è½½å†…æ ¸ç‰ˆæœ¬ï¼ˆå¦‚ä¸‹ä¸€èŠ‚æ‰€è¿°ï¼‰ï¼Œä½†è¿™æ˜¯è¿›è¡Œå†…æ ¸å¼€å‘çš„
+一ç§å›°éš¾çš„æ–¹å¼ã€‚
+
+1) "diff -up"
+-------------
+
+使用 "diff -up" 或者 "diff -uprN" æ¥åˆ›å»ºè¡¥ä¸ã€‚
+
+æ‰€æœ‰å†…æ ¸çš„æ”¹åŠ¨ï¼Œéƒ½æ˜¯ä»¥è¡¥ä¸çš„å½¢å¼å‘ˆçŽ°çš„，补ä¸ç”± diff(1) 生æˆã€‚创建补ä¸çš„
+时候，è¦ç¡®è®¤å®ƒæ˜¯ä»¥ "unified diff" æ ¼å¼åˆ›å»ºçš„，这ç§æ ¼å¼ç”± diff(1) çš„ '-u'
+å‚数生æˆã€‚而且，请使用 '-p' å‚æ•°ï¼Œé‚£æ ·ä¼šæ˜¾ç¤ºæ¯ä¸ªæ”¹åŠ¨æ‰€åœ¨çš„C函数，使得
+产生的补ä¸å®¹æ˜“读得多。补ä¸åº”è¯¥åŸºäºŽå†…æ ¸æºä»£ç æ ‘çš„æ ¹ç›®å½•ï¼Œè€Œä¸æ˜¯é‡Œè¾¹çš„ä»»
+何å目录。
+
+为一个å•ç‹¬çš„文件创建补ä¸ï¼Œä¸€èˆ¬æ¥è¯´è¿™æ ·åšå°±å¤Ÿäº†::
+
+ SRCTREE=linux
+ MYFILE=drivers/net/mydriver.c
+
+ cd $SRCTREE
+ cp $MYFILE $MYFILE.orig
+ vi $MYFILE # make your change
+ cd ..
+ diff -up $SRCTREE/$MYFILE{.orig,} > /tmp/patch
+
+为多个文件创建补ä¸ï¼Œä½ å¯ä»¥è§£å¼€ä¸€ä¸ªæ²¡æœ‰ä¿®æ”¹è¿‡çš„å†…æ ¸æºä»£ç æ ‘ï¼Œç„¶åŽå’Œä½ 自
+己的代ç æ ‘ä¹‹é—´åš diff 。例如::
+
+ MYSRC=/devel/linux
+
+ tar xvfz linux-3.19.tar.gz
+ mv linux-3.19 linux-3.19-vanilla
+ diff -uprN -X linux-3.19-vanilla/Documentation/dontdiff \
+ linux-3.19-vanilla $MYSRC > /tmp/patch
+
+"dontdiff" æ˜¯å†…æ ¸åœ¨ç¼–è¯‘çš„æ—¶å€™äº§ç”Ÿçš„æ–‡ä»¶çš„åˆ—è¡¨ï¼Œåˆ—è¡¨ä¸çš„文件在 diff(1)
+产生的补ä¸é‡Œä¼šè¢«è·³è¿‡ã€‚
+
+ç¡®å®šä½ çš„è¡¥ä¸é‡Œæ²¡æœ‰åŒ…å«ä»»ä½•ä¸å±žäºŽè¿™æ¬¡è¡¥ä¸æ交的é¢å¤–文件。记得在用diff(1)
+生æˆè¡¥ä¸ä¹‹åŽï¼Œå®¡é˜…一次补ä¸ï¼Œä»¥ç¡®ä¿å‡†ç¡®ã€‚
+
+å¦‚æžœä½ çš„æ”¹åŠ¨å¾ˆæ•£ä¹±ï¼Œä½ åº”è¯¥ç ”ç©¶ä¸€ä¸‹å¦‚ä½•å°†è¡¥ä¸åˆ†å‰²æˆç‹¬ç«‹çš„部分，将改动分
+割æˆä¸€ç³»åˆ—åˆä¹Žé€»è¾‘çš„æ¥éª¤ã€‚è¿™æ ·æ›´å®¹æ˜“è®©å…¶ä»–å†…æ ¸å¼€å‘è€…å®¡æ ¸ï¼Œå¦‚æžœä½ æƒ³ä½ çš„
+è¡¥ä¸è¢«æŽ¥å—，这是很é‡è¦çš„。请å‚阅：
+:ref:`cn_split_changes`
+
+å¦‚æžœä½ ç”¨ ``git`` , ``git rebase -i`` å¯ä»¥å¸®åŠ©ä½ è¿™ä¸€ç‚¹ã€‚å¦‚æžœä½ ä¸ç”¨ ``git``,
+``quilt`` <http://savannah.nongnu.org/projects/quilt> å¦å¤–一个æµè¡Œçš„选择。
+
+.. _cn_describe_changes:
+
+2) æè¿°ä½ çš„æ”¹åŠ¨
+---------------
+
+æè¿°ä½ çš„é—®é¢˜ã€‚æ— è®ºæ‚¨çš„è¡¥ä¸æ˜¯ä¸€è¡Œé”™è¯¯ä¿®å¤è¿˜æ˜¯5000行新功能，都必须有一个潜在
+的问题激励您完æˆè¿™é¡¹å·¥ä½œã€‚让审稿人相信有一个问题值得解决，让他们读完第一段
+是有æ„义的。
+
+æ述用户å¯è§çš„å½±å“。直接崩溃和é”定是相当有说æœåŠ›çš„，但并ä¸æ˜¯æ‰€æœ‰çš„错误都那么
+æ˜Žç›®å¼ èƒ†ã€‚å³ä½¿åœ¨ä»£ç 审查期间å‘现了这个问题，也è¦æ述一下您认为它å¯èƒ½å¯¹ç”¨æˆ·äº§
+生的影å“。请记ä½ï¼Œå¤§å¤šæ•°Linux安装è¿è¡Œçš„å†…æ ¸æ¥è‡ªäºŒçº§ç¨³å®šæ ‘或特定于供应商/产å“
+çš„æ ‘ï¼Œåªä»Žä¸Šæ¸¸ç²¾é€‰ç‰¹å®šçš„è¡¥ä¸ï¼Œå› æ¤è¯·åŒ…å«ä»»ä½•å¯ä»¥å¸®åŠ©æ‚¨å°†æ›´æ”¹å®šä½åˆ°ä¸‹æ¸¸çš„内容：
+触å‘的场景ã€DMESG的摘录ã€å´©æºƒæè¿°ã€æ€§èƒ½å›žå½’ã€å»¶è¿Ÿå°–å³°ã€é”定ç‰ã€‚
+
+é‡åŒ–优化和æƒè¡¡ã€‚如果您声称在性能ã€å†…å˜æ¶ˆè€—ã€å †æ ˆå 用空间或二进制大å°æ–¹é¢æœ‰æ‰€
+改进，请包括支æŒå®ƒä»¬çš„æ•°å—。但也è¦æè¿°ä¸æ˜Žæ˜¾çš„æˆæœ¬ã€‚优化通常ä¸æ˜¯å…费的，而是
+在CPUã€å†…å˜å’Œå¯è¯»æ€§ä¹‹é—´è¿›è¡Œæƒè¡¡ï¼›æˆ–者，探索性的工作，在ä¸åŒçš„工作负载之间进
+è¡Œæƒè¡¡ã€‚请æ述优化的预期缺点，以便审阅者å¯ä»¥æƒè¡¡æˆæœ¬å’Œæ”¶ç›Šã€‚
+
+一旦问题建立起æ¥ï¼Œå°±è¦è¯¦ç»†åœ°æ述一下您实际在åšä»€ä¹ˆã€‚对于审阅者æ¥è¯´ï¼Œç”¨ç®€å•çš„
+英è¯æ述代ç çš„å˜åŒ–是很é‡è¦çš„，以验è¯ä»£ç 的行为是å¦ç¬¦åˆæ‚¨çš„æ„愿。
+
+如果您将补ä¸æ述写在一个表å•ä¸ï¼Œè¿™ä¸ªè¡¨å•å¯ä»¥å¾ˆå®¹æ˜“地作为“æ交日志â€æ”¾å…¥Linux
+çš„æºä»£ç 管ç†ç³»ç»Ÿgitä¸ï¼Œé‚£ä¹ˆç»´æŠ¤äººå‘˜å°†éžå¸¸æ„Ÿè°¢æ‚¨ã€‚è§ :ref:`cn_explicit_in_reply_to`.
+
+æ¯ä¸ªè¡¥ä¸åªè§£å†³ä¸€ä¸ªé—®é¢˜ã€‚å¦‚æžœä½ çš„æ述开始å˜é•¿ï¼Œè¿™å°±è¡¨æ˜Žä½ å¯èƒ½éœ€è¦æ‹†åˆ†ä½ çš„è¡¥ä¸ã€‚
+è¯·è§ :ref:`cn_split_changes`
+
+æ交或é‡æ–°æ交修补程åºæˆ–修补程åºç³»åˆ—时，请包括完整的修补程åºè¯´æ˜Žå’Œç†ç”±ã€‚ä¸è¦
+åªè¯´è¿™æ˜¯è¡¥ä¸ï¼ˆç³»åˆ—ï¼‰çš„ç¬¬å‡ ç‰ˆã€‚ä¸è¦æœŸæœ›å系统维护人员引用更早的补ä¸ç‰ˆæœ¬æˆ–引用
+URLæ¥æŸ¥æ‰¾è¡¥ä¸æ述并将其放入补ä¸ä¸ã€‚也就是说，补ä¸ï¼ˆç³»åˆ—）åŠå…¶æ述应该是独立的。
+这对维护人员和审查人员都有好处。一些评审者å¯èƒ½ç”šè‡³æ²¡æœ‰æ”¶åˆ°è¡¥ä¸çš„早期版本。
+
+æè¿°ä½ åœ¨å‘½ä»¤è¯æ°”ä¸çš„å˜åŒ–，例如“make xyzzy do frotzâ€è€Œä¸æ˜¯â€œ[这个补ä¸]make
+xyzzy do frotzâ€æˆ–“[我]changed xyzzy to do frotzâ€ï¼Œå°±å¥½åƒä½ 在命令代ç 库改å˜
+å®ƒçš„è¡Œä¸ºä¸€æ ·ã€‚
+
+如果修补程åºä¿®å¤äº†ä¸€ä¸ªè®°å½•çš„bugæ¡ç›®ï¼Œè¯·æŒ‰ç¼–å·å’ŒURL引用该bugæ¡ç›®ã€‚如果补ä¸æ¥
+自邮件列表讨论，请给出邮件列表å˜æ¡£çš„URL；使用带有 ``Message-ID`` çš„
+https://lkml.kernel.org/ é‡å®šå‘，以确ä¿é“¾æŽ¥ä¸ä¼šè¿‡æ—¶ã€‚
+
+但是，在没有外部资æºçš„情况下，尽é‡è®©ä½ 的解释å¯ç†è§£ã€‚除了æ供邮件列表å˜æ¡£æˆ–
+bugçš„URL之外，还è¦æ€»ç»“需è¦æ交补ä¸çš„相关讨论è¦ç‚¹ã€‚
+
+如果您想è¦å¼•ç”¨ä¸€ä¸ªç‰¹å®šçš„æ交，ä¸è¦åªå¼•ç”¨æ交的 SHA-1 ID。还请包括æ交的一行
+摘è¦ï¼Œä»¥ä¾¿äºŽå®¡é˜…者了解它是关于什么的。例如::
+
+ Commit e21d2170f36602ae2708 ("video: remove unnecessary
+ platform_set_drvdata()") removed the unnecessary
+ platform_set_drvdata(), but left the variable "dev" unused,
+ delete it.
+
+您还应该确ä¿è‡³å°‘使用å‰12ä½ SHA-1 ID. å†…æ ¸å˜å‚¨åº“包å«*许多*对象，使与较çŸçš„ID
+å‘生冲çªçš„å¯èƒ½æ€§å¾ˆå¤§ã€‚è®°ä½ï¼Œå³ä½¿çŽ°åœ¨ä¸ä¼šä¸Žæ‚¨çš„å…个å—符IDå‘生冲çªï¼Œè¿™ç§æƒ…况
+å¯èƒ½äº”å¹´åŽæ”¹å˜ã€‚
+
+如果修补程åºä¿®å¤äº†ç‰¹å®šæ交ä¸çš„错误，例如，使用 ``git bisct`` ，请使用带有å‰
+12个å—符SHA-1 ID çš„"Fixes:"æ ‡è®°å’Œå•è¡Œæ‘˜è¦ã€‚为了简化ä¸è¦å°†æ ‡è®°æ‹†åˆ†ä¸ºå¤šä¸ªï¼Œ
+è¡Œã€æ ‡è®°ä¸å—分æžè„šæœ¬â€œ75列æ¢è¡Œâ€è§„则的é™åˆ¶ã€‚例如::
+
+ Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually freed")
+
+下列 ``git config`` 设置å¯ä»¥æ·»åŠ 让 ``git log``, ``git show`` æ¼‚äº®çš„æ˜¾ç¤ºæ ¼å¼::
+
+ [core]
+ abbrev = 12
+ [pretty]
+ fixes = Fixes: %h (\"%s\")
+
+.. _cn_split_changes:
+
+3) æ‹†åˆ†ä½ çš„æ”¹åŠ¨
+---------------
+
+å°†æ¯ä¸ªé€»è¾‘更改分隔æˆä¸€ä¸ªå•ç‹¬çš„è¡¥ä¸ã€‚
+
+ä¾‹å¦‚ï¼Œå¦‚æžœä½ çš„æ”¹åŠ¨é‡ŒåŒæ—¶æœ‰bugä¿®æ£å’Œæ€§èƒ½ä¼˜åŒ–，那么把这些改动拆分到两个或
+者更多的补ä¸æ–‡ä»¶ä¸ã€‚å¦‚æžœä½ çš„æ”¹åŠ¨åŒ…å«å¯¹API的修改，并且修改了驱动程åºæ¥é€‚
+应这些新的API，那么把这些修改分æˆä¸¤ä¸ªè¡¥ä¸ã€‚
+
+å¦ä¸€æ–¹é¢ï¼Œå¦‚æžœä½ å°†ä¸€ä¸ªå•ç‹¬çš„改动åšæˆå¤šä¸ªè¡¥ä¸æ–‡ä»¶ï¼Œé‚£ä¹ˆå°†å®ƒä»¬åˆå¹¶æˆä¸€ä¸ª
+å•ç‹¬çš„è¡¥ä¸æ–‡ä»¶ã€‚è¿™æ ·ä¸€ä¸ªé€»è¾‘ä¸Šå•ç‹¬çš„改动åªè¢«åŒ…å«åœ¨ä¸€ä¸ªè¡¥ä¸æ–‡ä»¶é‡Œã€‚
+
+如果有一个补ä¸ä¾èµ–å¦å¤–一个补ä¸æ¥å®Œæˆå®ƒçš„改动，那没问题。简å•çš„åœ¨ä½ çš„è¡¥
+ä¸æ述里指出“这个补ä¸ä¾èµ–æŸè¡¥ä¸â€å°±å¥½äº†ã€‚
+
+在将您的更改划分为一系列补ä¸æ—¶ï¼Œè¦ç‰¹åˆ«æ³¨æ„ç¡®ä¿å†…æ ¸åœ¨ç³»åˆ—ä¸çš„æ¯ä¸ªè¡¥ä¸ä¹‹åŽ
+都能æ£å¸¸æž„建和è¿è¡Œã€‚使用 ``git bisect`` æ¥è¿½è¸ªé—®é¢˜çš„å¼€å‘者å¯èƒ½ä¼šåœ¨ä»»ä½•æ—¶
+å€™åˆ†å‰²ä½ çš„è¡¥ä¸ç³»åˆ—ï¼›å¦‚æžœä½ åœ¨ä¸é—´å¼•å…¥é”™è¯¯ï¼Œä»–们ä¸ä¼šæ„Ÿè°¢ä½ 。
+
+å¦‚æžœä½ ä¸èƒ½å°†è¡¥ä¸æµ“缩æˆæ›´å°‘的文件，那么æ¯æ¬¡å¤§çº¦å‘é€å‡º15个，然åŽç‰å¾…审查
+和集æˆã€‚
+
+4) æ£€æŸ¥ä½ çš„æ›´æ”¹é£Žæ ¼
+-------------------
+
+检查您的补ä¸æ˜¯å¦å˜åœ¨åŸºæœ¬æ ·å¼å†²çªï¼Œè¯¦ç»†ä¿¡æ¯å¯åœ¨
+:ref:`Documentation/translations/zh_CN/process/coding-style.rst <cn_codingstyle>`
+ä¸æ‰¾åˆ°ã€‚如果ä¸è¿™æ ·åšï¼Œåªä¼šæµªè´¹å®¡ç¨¿äººçš„æ—¶é—´ï¼Œå¹¶ä¸”ä¼šå¯¼è‡´ä½ çš„è¡¥ä¸è¢«æ‹’ç»ï¼Œç”šè‡³
+å¯èƒ½æ²¡æœ‰è¢«é˜…读。
+
+一个é‡è¦çš„例外是在将代ç 从一个文件移动到å¦ä¸€ä¸ªæ–‡ä»¶æ—¶â€”—在这ç§æƒ…况下，您ä¸åº”
+该在移动代ç çš„åŒä¸€ä¸ªè¡¥ä¸ä¸ä¿®æ”¹ç§»åŠ¨çš„代ç 。这清楚地æ述了移动代ç 和您的更改
+的行为。这大大有助于审查实际差异，并å…许工具更好地跟踪代ç 本身的历å²ã€‚
+
+在æ交之å‰ï¼Œä½¿ç”¨è¡¥ä¸æ ·å¼æ£€æŸ¥ç¨‹åºæ£€æŸ¥è¡¥ä¸ï¼ˆscripts/check patch.pl）。ä¸è¿‡ï¼Œ
+请注æ„ï¼Œæ ·å¼æ£€æŸ¥ç¨‹åºåº”该被视为一个指å—，而ä¸æ˜¯ä½œä¸ºäººç±»åˆ¤æ–的替代å“。如果您
+的代ç 看起æ¥æ›´å¥½ï¼Œä½†æœ‰è¿è§„行为，那么最好ä¸è¦ä½¿ç”¨å®ƒã€‚
+
+检查者报告三个级别：
+
+ - ERROR：很å¯èƒ½å‡ºé”™çš„事情
+ - WARNING：需è¦ä»”细审查的事项
+ - CHECK：需è¦æ€è€ƒçš„事情
+
+您应该能够判æ–您的补ä¸ä¸å˜åœ¨çš„所有è¿è§„行为。
+
+5) 选择补ä¸æ”¶ä»¶äºº
+-----------------
+
+您应该总是在任何补ä¸ä¸Šå¤åˆ¶ç›¸åº”çš„å系统维护人员，以获得他们维护的代ç ；查看
+维护人员文件和æºä»£ç 修订历å²è®°å½•ï¼Œä»¥äº†è§£è¿™äº›ç»´æŠ¤äººå‘˜æ˜¯è°ã€‚脚本
+scripts/get_Maintainer.pl在这个æ¥éª¤ä¸éžå¸¸æœ‰ç”¨ã€‚如果您找ä¸åˆ°æ£åœ¨å·¥ä½œçš„å系统
+的维护人员，那么Andrew Morton（akpm@linux-foundation.org）将充当最åŽçš„维护
+人员。
+
+您通常还应该选择至少一个邮件列表æ¥æŽ¥æ”¶è¡¥ä¸é›†çš„。linux-kernel@vger.kernel.org
+作为最åŽä¸€ä¸ªè§£å†³åŠžæ³•çš„列表，但是这个列表上的体积已ç»å¼•èµ·äº†è®¸å¤šå¼€å‘人员的拒ç»ã€‚
+在MAINTAINERS文件ä¸æŸ¥æ‰¾å系统特定的列表；您的补ä¸å¯èƒ½ä¼šåœ¨é‚£é‡Œå¾—到更多的关注。
+ä¸è¿‡ï¼Œè¯·ä¸è¦å‘é€åžƒåœ¾é‚®ä»¶åˆ°æ— 关的列表。
+
+è®¸å¤šä¸Žå†…æ ¸ç›¸å…³çš„åˆ—è¡¨æ‰˜ç®¡åœ¨vger.kernel.org上；您å¯ä»¥åœ¨
+http://vger.kernel.org/vger-lists.html 上找到它们的列表。ä¸è¿‡ï¼Œä¹Ÿæœ‰ä¸Žå†…æ ¸ç›¸å…³
+的列表托管在其他地方。
+
+ä¸è¦ä¸€æ¬¡å‘é€è¶…过15个补ä¸åˆ°vger邮件列表ï¼ï¼ï¼ï¼
+
+Linus Torvalds 是决定改动能å¦è¿›å…¥ Linux å†…æ ¸çš„æœ€ç»ˆè£å†³è€…。他的 e-mail
+地å€æ˜¯ <torvalds@linux-foundation.org> 。他收到的 e-mail 很多，所以一般
+çš„è¯´ï¼Œæœ€å¥½åˆ«ç»™ä»–å‘ e-mail。
+
+如果您有修å¤å¯åˆ©ç”¨å®‰å…¨æ¼æ´žçš„è¡¥ä¸ï¼Œè¯·å°†è¯¥è¡¥ä¸å‘é€åˆ° security@kernel.org。对于
+严é‡çš„bug，å¯ä»¥è€ƒè™‘çŸæœŸæš‚åœä»¥å…许分销商å‘用户å‘布补ä¸ï¼›åœ¨è¿™ç§æƒ…况下，显然ä¸åº”
+将补ä¸å‘é€åˆ°ä»»ä½•å…¬å…±åˆ—表。
+
+ä¿®å¤å·²å‘å¸ƒå†…æ ¸ä¸ä¸¥é‡é”™è¯¯çš„è¡¥ä¸ç¨‹åºåº”该指å‘ç¨³å®šç‰ˆç»´æŠ¤äººå‘˜ï¼Œæ–¹æ³•æ˜¯æ”¾è¿™æ ·çš„ä¸€è¡Œ::
+
+ Cc: stable@vger.kernel.org
+
+进入补ä¸çš„ç¾å‡†åŒºï¼ˆæ³¨æ„，ä¸æ˜¯ç”µå邮件收件人）。除了这个文件之外，您还应该阅读
+:ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
+
+但是，请注æ„，一些å系统维护人员希望得出他们自己的结论，å³å“ªäº›è¡¥ä¸åº”该被放到
+ç¨³å®šçš„æ ‘ä¸Šã€‚å°¤å…¶æ˜¯ç½‘ç»œç»´æŠ¤äººå‘˜ï¼Œä¸å¸Œæœ›çœ‹åˆ°å•ä¸ªå¼€å‘人员在补ä¸ä¸æ·»åŠ åƒä¸Šé¢è¿™æ ·
+的行。
+
+如果更改影å“åˆ°ç”¨æˆ·å’Œå†…æ ¸æŽ¥å£ï¼Œè¯·å‘手册页维护人员（如维护人员文件ä¸æ‰€åˆ—）å‘é€
+手册页补ä¸ï¼Œæˆ–至少å‘é€æ›´æ”¹é€šçŸ¥ï¼Œä»¥ä¾¿ä¸€äº›ä¿¡æ¯è¿›å…¥æ‰‹å†Œé¡µã€‚还应将用户空间API
+更改å¤åˆ¶åˆ° linux-api@vger.kernel.org。
+
+对于å°çš„è¡¥ä¸ï¼Œä½ 也许会CC到æœé›†ç碎补ä¸çš„邮件列表(Trivial Patch Monkey)
+trivial@kernel.org，那里专门收集ç碎的补ä¸ã€‚下é¢è¿™æ ·çš„è¡¥ä¸ä¼šè¢«çœ‹ä½œâ€œç碎的â€
+è¡¥ä¸ï¼š
+
+ - 文档的拼写修æ£ã€‚
+ - ä¿®æ£ä¼šå½±å“到 grep(1) 的拼写。
+ - è¦å‘Šä¿¡æ¯ä¿®æ£(频ç¹çš„打å°æ— 用的è¦å‘Šæ˜¯ä¸å¥½çš„。)
+ - 编译错误修æ£ï¼ˆä»£ç 逻辑的确是对的，åªæ˜¯ç¼–译有问题。）
+ - è¿è¡Œæ—¶ä¿®æ£ï¼ˆåªè¦çœŸçš„ä¿®æ£äº†é”™è¯¯ã€‚）
+ - 移除使用了被废弃的函数/å®çš„代ç (例如 check_region。)
+ - è”系方å¼å’Œæ–‡æ¡£ä¿®æ£ã€‚
+ - 用å¯ç§»æ¤çš„代ç 替æ¢ä¸å¯ç§»æ¤çš„代ç （å³ä½¿åœ¨ä½“系结构相关的代ç ä¸ï¼Œæ—¢ç„¶æœ‰
+ - 人拷è´ï¼Œåªè¦å®ƒæ˜¯ç碎的）
+ - 任何文件的作者/维护者对该文件的改动（例如 patch monkey 在é‡ä¼ 模å¼ä¸‹ï¼‰
+
+(译注，关于“ç碎补ä¸â€çš„ä¸€äº›è¯´æ˜Žï¼šå› ä¸ºåŽŸæ–‡çš„è¿™ä¸€éƒ¨åˆ†å†™å¾—æ¯”è¾ƒç®€å•ï¼Œæ‰€ä»¥ä¸å¾—ä¸
+è¿ä¾‹å†™ä¸€ä¸‹è¯‘注。"trivial"这个英文å•è¯çš„本æ„是“ç碎的，ä¸é‡è¦çš„。â€ä½†æ˜¯åœ¨è¿™é‡Œ
+有ç¨å¾®æœ‰ä¸€äº›å˜åŒ–，例如对一些明显的NULL指针的修æ£ï¼Œå±žäºŽè¿è¡Œæ—¶ä¿®æ£ï¼Œä¼šè¢«å½’ç±»
+到ç碎补ä¸é‡Œã€‚虽然NULL指针的修æ£å¾ˆé‡è¦ï¼Œä½†æ˜¯è¿™æ ·çš„ä¿®æ£å¾€å¾€å¾ˆå°è€Œä¸”很容易得到
+检验，所以也被归入ç碎补ä¸ã€‚ç碎补ä¸æ›´ç²¾ç¡®çš„归类应该是
+“simple, localized & easy to verifyâ€ï¼Œä¹Ÿå°±æ˜¯è¯´ç®€å•çš„，局部的和易于检验的。
+trivial@kernel.orgé‚®ä»¶åˆ—è¡¨çš„ç›®çš„æ˜¯é’ˆå¯¹è¿™æ ·çš„è¡¥ä¸ï¼Œä¸ºæ交者æ供一个ä¸å¿ƒï¼Œæ¥
+é™ä½Žæ交的门槛。)
+
+6) 没有 MIME ç¼–ç ，没有链接，没有压缩，没有附件，åªæœ‰çº¯æ–‡æœ¬
+-----------------------------------------------------------
+
+Linus å’Œå…¶ä»–çš„å†…æ ¸å¼€å‘者需è¦é˜…è¯»å’Œè¯„è®ºä½ æäº¤çš„æ”¹åŠ¨ã€‚å¯¹äºŽå†…æ ¸å¼€å‘者æ¥è¯´
+，å¯ä»¥â€œå¼•ç”¨â€ä½ 的改动很é‡è¦ï¼Œä½¿ç”¨ä¸€èˆ¬çš„ e-mail 工具，他们就å¯ä»¥åœ¨ä½ çš„
+代ç 的任何ä½ç½®æ·»åŠ 评论。
+
+å› ä¸ºè¿™ä¸ªåŽŸå› ï¼Œæ‰€æœ‰çš„æ交的补ä¸éƒ½æ˜¯ e-mail ä¸â€œå†…嵌â€çš„。
+
+.. warning::
+ å¦‚æžœä½ ä½¿ç”¨å‰ªåˆ‡-ç²˜è´´ä½ çš„è¡¥ä¸ï¼Œå°å¿ƒä½ 的编辑器的自动æ¢è¡ŒåŠŸèƒ½ç ´åä½ çš„è¡¥ä¸
+
+ä¸è¦å°†è¡¥ä¸ä½œä¸º MIME ç¼–ç 的附件，ä¸ç®¡æ˜¯å¦åŽ‹ç¼©ã€‚很多æµè¡Œçš„ e-mail 软件ä¸
+是任何时候都将 MIME ç¼–ç 的附件当作纯文本å‘é€çš„ï¼Œè¿™ä¼šä½¿å¾—åˆ«äººæ— æ³•åœ¨ä½ çš„
+代ç ä¸åŠ 评论。å¦å¤–，MIME ç¼–ç 的附件会让 Linus 多花一点时间æ¥å¤„ç†ï¼Œè¿™å°±
+é™ä½Žäº†ä½ 的改动被接å—çš„å¯èƒ½æ€§ã€‚
+
+ä¾‹å¤–ï¼šå¦‚æžœä½ çš„é‚®é€’å‘˜å¼„å了补ä¸ï¼Œé‚£ä¹ˆæœ‰äººå¯èƒ½ä¼šè¦æ±‚ä½ ä½¿ç”¨mimeé‡æ–°å‘é€è¡¥ä¸
+
+请å‚阅 :ref:`Documentation/translations/zh_CN/process/email-clients.rst <cn_email_clients>`
+以获å–有关é…置电å邮件客户端以使其ä¸å—å½±å“地å‘é€ä¿®è¡¥ç¨‹åºçš„æ示。
+
+7) e-mail 的大å°
+----------------
+
+大的改动对邮件列表ä¸åˆé€‚，对æŸäº›ç»´æŠ¤è€…也ä¸åˆé€‚ã€‚å¦‚æžœä½ çš„è¡¥ä¸ï¼Œåœ¨ä¸åŽ‹ç¼©
+的情况下，超过了300kBï¼Œé‚£ä¹ˆä½ æœ€å¥½å°†è¡¥ä¸æ”¾åœ¨ä¸€ä¸ªèƒ½é€šè¿‡ internet 访问的æœ
+务器上，然åŽç”¨æŒ‡å‘ä½ çš„è¡¥ä¸çš„ URL 替代。但是请注æ„，如果您的补ä¸è¶…过了
+300kbï¼Œé‚£ä¹ˆå®ƒå‡ ä¹Žè‚¯å®šéœ€è¦è¢«ç ´å。
+
+8）回å¤è¯„审æ„è§
+---------------
+
+ä½ çš„è¡¥ä¸å‡ 乎肯定会得到评审者对补ä¸æ”¹è¿›æ–¹æ³•çš„评论。您必须对这些评论作出
+回应；让补ä¸è¢«å¿½ç•¥çš„一个好办法就是忽略审阅者的æ„è§ã€‚ä¸ä¼šå¯¼è‡´ä»£ç 更改的
+æ„è§æˆ–é—®é¢˜å‡ ä¹Žè‚¯å®šä¼šå¸¦æ¥æ³¨é‡Šæˆ–å˜æ›´æ—¥å¿—的改å˜ï¼Œä»¥ä¾¿ä¸‹ä¸€ä¸ªè¯„审者更好地了解
+æ£åœ¨å‘生的事情。
+
+一定è¦å‘Šè¯‰å®¡ç¨¿äººä½ 在åšä»€ä¹ˆæ”¹å˜ï¼Œå¹¶æ„Ÿè°¢ä»–们的时间。代ç 审查是一个累人且
+耗时的过程，审查人员有时会å˜å¾—æš´èºã€‚å³ä½¿åœ¨è¿™ç§æƒ…况下，也è¦ç¤¼è²Œåœ°å›žåº”并
+解决他们指出的问题。
+
+9）ä¸è¦æ³„气或ä¸è€çƒ¦
+-------------------
+
+æ交更改åŽï¼Œè¯·è€å¿ƒç‰å¾…。审阅者是忙碌的人，å¯èƒ½æ— 法立å³è®¿é—®æ‚¨çš„修补程åºã€‚
+
+æ›¾å‡ ä½•æ—¶ï¼Œè¡¥ä¸æ›¾åœ¨æ²¡æœ‰è¯„论的情况下消失在空白ä¸ï¼Œä½†å¼€å‘è¿‡ç¨‹æ¯”çŽ°åœ¨æ›´åŠ é¡ºåˆ©ã€‚
+您应该在一周左å³çš„时间内收到评论；如果没有收到评论，请确ä¿æ‚¨å·²å°†è¡¥ä¸å‘é€
+到æ£ç¡®çš„ä½ç½®ã€‚在é‡æ–°æ交或è”系审阅者之å‰è‡³å°‘ç‰å¾…一周-在诸如åˆå¹¶çª—å£ä¹‹ç±»çš„
+ç¹å¿™æ—¶é—´å¯èƒ½æ›´é•¿ã€‚
+
+10）主题ä¸åŒ…å« PATCH
+--------------------
+
+由于到linuså’Œlinuxå†…æ ¸çš„ç”µå邮件æµé‡å¾ˆé«˜ï¼Œé€šå¸¸ä¼šåœ¨ä¸»é¢˜è¡Œå‰é¢åŠ 上[PATCH]
+å‰ç¼€. 这使Linuså’Œå…¶ä»–å†…æ ¸å¼€å‘人员更容易将补ä¸ä¸Žå…¶ä»–电å邮件讨论区分开。
+
+11）ç¾ç½²ä½ 的作å“-å¼€å‘者原始认è¯
+-------------------------------
+
+ä¸ºäº†åŠ å¼ºå¯¹è°åšäº†ä½•äº‹çš„追踪，尤其是对那些é€è¿‡å¥½å‡ 层的维护者的补ä¸ï¼Œæˆ‘们
+建议在å‘é€å‡ºåŽ»çš„è¡¥ä¸ä¸ŠåŠ 一个 “sign-off†的过程。
+
+"sign-off" 是在补ä¸çš„注释的最åŽçš„简å•çš„一行文å—，认è¯ä½ 编写了它或者其他
+人有æƒåŠ›å°†å®ƒä½œä¸ºå¼€æ”¾æºä»£ç çš„è¡¥ä¸ä¼ 递。规则很简å•ï¼šå¦‚æžœä½ èƒ½è®¤è¯å¦‚下信æ¯:
+
+å¼€å‘者æ¥æºè¯ä¹¦ 1.1
+^^^^^^^^^^^^^^^^^^
+
+对于本项目的贡献，我认è¯å¦‚下信æ¯ï¼š
+
+ （a）这些贡献是完全或者部分的由我创建，我有æƒåˆ©ä»¥æ–‡ä»¶ä¸æŒ‡å‡º
+ 的开放æºä»£ç 许å¯è¯æ交它；或者
+ （b）这些贡献基于以å‰çš„工作，æ®æˆ‘所知，这些以å‰çš„工作å—æ°å½“的开放
+ æºä»£ç 许å¯è¯ä¿æŠ¤ï¼Œè€Œä¸”ï¼Œæ ¹æ®è®¸å¯è¯ï¼Œæˆ‘有æƒæ交修改åŽçš„贡献，
+ æ— è®ºæ˜¯å®Œå…¨è¿˜æ˜¯éƒ¨åˆ†ç”±æˆ‘åˆ›é€ ï¼Œè¿™äº›è´¡çŒ®éƒ½ä½¿ç”¨åŒä¸€ä¸ªå¼€æ”¾æºä»£ç 许å¯è¯
+ （除éžæˆ‘被å…许用其它的许å¯è¯ï¼‰ï¼Œæ£å¦‚文件ä¸æŒ‡å‡ºçš„；或者
+ （c）这些贡献由认è¯ï¼ˆa），（b）或者（c）的人直接æ供给我，而
+ 且我没有修改它。
+ （d）我ç†è§£å¹¶åŒæ„这个项目和贡献是公开的，贡献的记录（包括我
+ 一起æ交的个人记录，包括 sign-off ）被永久维护并且å¯ä»¥å’Œè¿™ä¸ªé¡¹ç›®
+ 或者开放æºä»£ç 的许å¯è¯åŒæ¥åœ°å†å‘行。
+
+é‚£ä¹ˆåŠ å…¥è¿™æ ·ä¸€è¡Œ::
+
+ Signed-off-by: Random J Developer <random@developer.example.org>
+
+ä½¿ç”¨ä½ çš„çœŸå（抱æ‰ï¼Œä¸èƒ½ä½¿ç”¨å‡å或者匿å。）
+
+有人在最åŽåŠ ä¸Šæ ‡ç¾ã€‚çŽ°åœ¨è¿™äº›ä¸œè¥¿ä¼šè¢«å¿½ç•¥ï¼Œä½†æ˜¯ä½ å¯ä»¥è¿™æ ·åšï¼Œæ¥æ ‡è®°å…¬å¸
+内部的过程，或者åªæ˜¯æŒ‡å‡ºå…³äºŽ sign-off 的一些特殊细节。
+
+如果您是å系统或分支维护人员，有时需è¦ç¨å¾®ä¿®æ”¹æ”¶åˆ°çš„è¡¥ä¸ï¼Œä»¥ä¾¿åˆå¹¶å®ƒä»¬ï¼Œ
+å› ä¸ºæ ‘å’Œæ交者ä¸çš„代ç ä¸å®Œå…¨ç›¸åŒã€‚å¦‚æžœä½ ä¸¥æ ¼éµå®ˆè§„则（cï¼‰ï¼Œä½ åº”è¯¥è¦æ±‚æ交者
+é‡æ–°å‘布，但这完全是在浪费时间和精力。规则（b）å…许您调整代ç ，但是更改一个
+æ交者的代ç 并让他认å¯æ‚¨çš„错误是éžå¸¸ä¸ç¤¼è²Œçš„。è¦è§£å†³æ¤é—®é¢˜ï¼Œå»ºè®®åœ¨æœ€åŽä¸€ä¸ª
+ç”±ç¾åè¡Œå’Œæ‚¨çš„è¡Œä¹‹é—´æ·»åŠ ä¸€è¡Œï¼ŒæŒ‡ç¤ºæ›´æ”¹çš„æ€§è´¨ã€‚è™½ç„¶è¿™å¹¶ä¸æ˜¯å¼ºåˆ¶æ€§çš„，但似乎
+在æè¿°å‰åŠ 上您的邮件和/或姓å（全部用方括å·æ‹¬èµ·æ¥ï¼‰ï¼Œè¿™è¶³ä»¥è®©äººæ³¨æ„到您对最
+åŽä¸€åˆ†é’Ÿçš„更改负有责任。例如::
+
+ Signed-off-by: Random J Developer <random@developer.example.org>
+ [lucky@maintainer.example.org: struct foo moved from foo.c to foo.h]
+ Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org>
+
+如果您维护一个稳定的分支机构，åŒæ—¶å¸Œæœ›å¯¹ä½œè€…进行致谢ã€è·Ÿè¸ªæ›´æ”¹ã€åˆå¹¶ä¿®å¤å¹¶
+ä¿æŠ¤æ交者ä¸å—投诉，那么这ç§åšæ³•å°¤å…¶æœ‰ç”¨ã€‚请注æ„，在任何情况下都ä¸èƒ½æ›´æ”¹ä½œè€…
+çš„ID（From å¤´ï¼‰ï¼Œå› ä¸ºå®ƒæ˜¯å‡ºçŽ°åœ¨æ›´æ”¹æ—¥å¿—ä¸çš„æ ‡è¯†ã€‚
+
+对回åˆï¼ˆback-porters）的特别说明：在æ交消æ¯çš„顶部（主题行之åŽï¼‰æ’入一个补ä¸
+çš„èµ·æºæŒ‡ç¤ºä¼¼ä¹Žæ˜¯ä¸€ç§å¸¸è§ä¸”有用的实践，以便于跟踪。例如，下é¢æ˜¯æˆ‘们在3.x稳定
+版本ä¸çœ‹åˆ°çš„内容::
+
+ Date: Tue Oct 7 07:26:38 2014 -0400
+
+ libata: Un-break ATA blacklist
+
+ commit 1c40279960bcd7d52dbdf1d466b20d24b99176c8 upstream.
+
+还有， è¿™é‡Œæ˜¯ä¸€ä¸ªæ—§ç‰ˆå†…æ ¸ä¸çš„一个回åˆè¡¥ä¸::
+
+ Date: Tue May 13 22:12:27 2008 +0200
+
+ wireless, airo: waitbusy() won't delay
+
+ [backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a]
+
+12）何时使用Acked-by:，CC:，和Co-Developed by:
+----------------------------------------------
+
+Singed-off-by: æ ‡è®°è¡¨ç¤ºç¾å者å‚与了补ä¸çš„å¼€å‘，或者他/她在补ä¸çš„ä¼ é€’è·¯å¾„ä¸ã€‚
+
+如果一个人没有直接å‚与补ä¸çš„准备或处ç†ï¼Œä½†å¸Œæœ›è¡¨ç¤ºå¹¶è®°å½•ä»–们对补ä¸çš„批准，
+那么他们å¯ä»¥è¦æ±‚在补ä¸çš„å˜æ›´æ—¥å¿—ä¸æ·»åŠ 一个 Acked-by:
+
+Acked-by：通常由å—å½±å“代ç 的维护者使用，当该维护者既没有贡献也没有转å‘è¡¥ä¸æ—¶ã€‚
+
+Acked-by: ä¸åƒç¾å—äººé‚£æ ·æ£å¼ã€‚这是一个记录，确认人至少审查了补ä¸ï¼Œå¹¶è¡¨ç¤ºæŽ¥å—。
+å› æ¤ï¼Œè¡¥ä¸åˆå¹¶æœ‰æ—¶ä¼šæ‰‹åŠ¨å°†Acker的“Yep，looks good to meâ€è½¬æ¢ä¸º Acked-By：（但
+请注æ„，通常最好è¦æ±‚一个明确的Ack）。
+
+Acked-by：ä¸ä¸€å®šè¡¨ç¤ºå¯¹æ•´ä¸ªè¡¥ä¸çš„确认。例如，如果一个补ä¸å½±å“多个å系统，并且
+有一个：æ¥è‡ªä¸€ä¸ªå系统维护者，那么这通常表示åªç¡®è®¤å½±å“维护者代ç 的部分。这里
+应该仔细判æ–。如有疑问，应å‚考邮件列表档案ä¸çš„原始讨论。
+
+如果æŸäººæœ‰æœºä¼šå¯¹è¡¥ä¸è¿›è¡Œè¯„论，但没有æä¾›æ¤ç±»è¯„论，您å¯ä»¥é€‰æ‹©åœ¨è¡¥ä¸ä¸æ·»åŠ ``Cc:``
+è¿™æ˜¯å”¯ä¸€ä¸€ä¸ªæ ‡ç¾ï¼Œå®ƒå¯ä»¥åœ¨æ²¡æœ‰è¢«å®ƒå‘½å的人显å¼æ“ä½œçš„æƒ…å†µä¸‹æ·»åŠ ï¼Œä½†å®ƒåº”è¯¥è¡¨æ˜Ž
+这个人是在补ä¸ä¸ŠæŠ„é€çš„。讨论ä¸åŒ…å«äº†æ½œåœ¨åˆ©ç›Šç›¸å…³æ–¹ã€‚
+
+Co-developed-by: 声明补ä¸æ˜¯ç”±å¤šä¸ªå¼€å‘人员共åŒåˆ›å»ºçš„ï¼›å½“å‡ ä¸ªäººåœ¨ä¸€ä¸ªè¡¥ä¸ä¸Šå·¥
+作时，它用于将属性赋予共åŒä½œè€…（除了 From: æ‰€èµ‹äºˆçš„ä½œè€…ä¹‹å¤–ï¼‰ã€‚å› ä¸º
+Co-developed-by: 表示作者身份，所以æ¯ä¸ªå…±åŒå¼€å‘人：必须紧跟在相关åˆä½œä½œè€…çš„
+ç¾å之åŽã€‚æ ‡å‡†çš„ç¾æ ¸ç¨‹åºè¦æ±‚ï¼šæ ‡è®°çš„ç¾æ ¸é¡ºåºåº”å°½å¯èƒ½åæ˜ è¡¥ä¸çš„时间历å²ï¼Œè€Œä¸
+管作者是通过 From ：还是由 Co-developed-by: å…±åŒå¼€å‘的。值得注æ„的是，最åŽä¸€
+个ç¾å—人：必须始终是æ交补ä¸çš„å¼€å‘人员。
+
+注æ„，当作者也是电åé‚®ä»¶æ ‡é¢˜â€œå‘件人：â€è¡Œä¸åˆ—出的人时，“From: â€ æ ‡è®°æ˜¯å¯é€‰çš„。
+
+作者æ交的补ä¸ç¨‹åºç¤ºä¾‹::
+
+ <changelog>
+
+ Co-developed-by: First Co-Author <first@coauthor.example.org>
+ Signed-off-by: First Co-Author <first@coauthor.example.org>
+ Co-developed-by: Second Co-Author <second@coauthor.example.org>
+ Signed-off-by: Second Co-Author <second@coauthor.example.org>
+ Signed-off-by: From Author <from@author.example.org>
+
+åˆä½œå¼€å‘者æ交的补ä¸ç¤ºä¾‹::
+
+ From: From Author <from@author.example.org>
+
+ <changelog>
+
+ Co-developed-by: Random Co-Author <random@coauthor.example.org>
+ Signed-off-by: Random Co-Author <random@coauthor.example.org>
+ Signed-off-by: From Author <from@author.example.org>
+ Co-developed-by: Submitting Co-Author <sub@coauthor.example.org>
+ Signed-off-by: Submitting Co-Author <sub@coauthor.example.org>
+
+
+13）使用报告人：ã€æµ‹è¯•äººï¼šã€å®¡æ ¸äººï¼šã€å»ºè®®äººï¼šã€ä¿®å¤äººï¼š
+--------------------------------------------------------
+
+Reported-by: 给那些å‘现错误并报告错误的人致谢，它希望激励他们在将æ¥å†æ¬¡å¸®åŠ©
+我们。请注æ„，如果bug是以ç§æœ‰æ–¹å¼æŠ¥å‘Šçš„，那么在使用Reported-byæ ‡è®°ä¹‹å‰ï¼Œè¯·
+先请求æƒé™ã€‚
+
+Tested-by: æ ‡è®°è¡¨ç¤ºè¡¥ä¸å·²ç”±æŒ‡å®šçš„人（在æŸäº›çŽ¯å¢ƒä¸ï¼‰æˆåŠŸæµ‹è¯•ã€‚è¿™ä¸ªæ ‡ç¾é€šçŸ¥
+维护人员已ç»æ‰§è¡Œäº†ä¸€äº›æµ‹è¯•ï¼Œä¸ºå°†æ¥çš„è¡¥ä¸æ供了一ç§å®šä½æµ‹è¯•äººå‘˜çš„方法，并确
+ä¿æµ‹è¯•äººå‘˜çš„信誉。
+
+Reviewed-by：相åï¼Œæ ¹æ®å®¡æŸ¥äººçš„声明，表明该补ä¸å·²è¢«å®¡æŸ¥å¹¶è¢«è®¤ä¸ºæ˜¯å¯æŽ¥å—的：
+
+
+审查人的监ç£å£°æ˜Ž
+^^^^^^^^^^^^^^^^
+
+通过æ供我的 Reviewed-by，我声明：
+
+ (a) 我已ç»å¯¹è¿™ä¸ªè¡¥ä¸è¿›è¡Œäº†ä¸€æ¬¡æŠ€æœ¯å®¡æŸ¥ï¼Œä»¥è¯„估它是å¦é€‚åˆè¢«åŒ…å«åˆ°
+ ä¸»çº¿å†…æ ¸ä¸ã€‚
+
+ (b) 与补ä¸ç›¸å…³çš„任何问题ã€é¡¾è™‘或问题都已å馈给æ交者。我对æ交者对
+ 我的评论的回应感到满æ„。
+
+ (c) 虽然这一æ交å¯èƒ½ä¼šæ”¹è¿›ä¸€äº›ä¸œè¥¿ï¼Œä½†æˆ‘相信，æ¤æ—¶ï¼Œï¼ˆ1ï¼‰å¯¹å†…æ ¸
+ 进行了有价值的修改，（2）没有包å«äº‰è®ºä¸æ¶‰åŠçš„已知问题。
+
+ (d) 虽然我已ç»å®¡æŸ¥äº†è¡¥ä¸å¹¶è®¤ä¸ºå®ƒæ˜¯å¥å…¨çš„，但我ä¸ä¼šï¼ˆé™¤éžå¦æœ‰æ˜Žç¡®
+ 说明）作出任何ä¿è¯æˆ–ä¿è¯å®ƒå°†åœ¨ä»»ä½•ç»™å®šæƒ…况下实现其规定的目的
+ 或æ£å¸¸è¿è¡Œã€‚
+
+Reviewed-by 是一ç§è§‚点声明，å³è¡¥ä¸æ˜¯å¯¹å†…æ ¸çš„é€‚å½“ä¿®æ”¹ï¼Œæ²¡æœ‰ä»»ä½•é—留的严é‡æŠ€æœ¯
+问题。任何感兴趣的审阅者（完æˆå·¥ä½œçš„人）都å¯ä»¥ä¸ºä¸€ä¸ªè¡¥ä¸æ供一个 Review-by
+æ ‡ç¾ã€‚æ¤æ ‡ç¾ç”¨äºŽå‘审阅者æ供致谢，并通知维护者已在修补程åºä¸Šå®Œæˆçš„审阅程度。
+Reviewed-by: 当由已知了解主题区域并执行彻底检查的审阅者æ供时，通常会增åŠ
+è¡¥ä¸è¿›å…¥å†…æ ¸çš„å¯èƒ½æ€§ã€‚
+
+Suggested-by: 表示补ä¸çš„想法是由指定的人æ出的，并确ä¿å°†æ¤æƒ³æ³•å½’功于指定的
+人。请注æ„，未ç»è®¸å¯ï¼Œä¸å¾—æ·»åŠ æ¤æ ‡ç¾ï¼Œç‰¹åˆ«æ˜¯å¦‚果该想法未在公共论å›ä¸Šå‘布。
+这就是说，如果我们勤快地致谢我们的创æ„者，他们很有希望在未æ¥å¾—到鼓舞，å†æ¬¡
+帮助我们。
+
+Fixes: 指示补ä¸åœ¨ä»¥å‰çš„æ交ä¸ä¿®å¤äº†ä¸€ä¸ªé—®é¢˜ã€‚它å¯ä»¥å¾ˆå®¹æ˜“地确定错误的æ¥æºï¼Œ
+这有助于检查错误修å¤ã€‚è¿™ä¸ªæ ‡è®°è¿˜å¸®åŠ©ç¨³å®šå†…æ ¸å›¢é˜Ÿç¡®å®šåº”è¯¥æŽ¥æ”¶ä¿®å¤çš„ç¨³å®šå†…æ ¸
+版本。这是指示补ä¸ä¿®å¤çš„错误的首选方法。请å‚阅 :ref:`cn_describe_changes`
+æ述您的更改以了解更多详细信æ¯ã€‚
+
+.. _cn_the_canonical_patch_format:
+
+12ï¼‰æ ‡å‡†è¡¥ä¸æ ¼å¼
+----------------
+
+本节æè¿°å¦‚ä½•æ ¼å¼åŒ–è¡¥ä¸æœ¬èº«ã€‚请注æ„，如果您的补ä¸å˜å‚¨åœ¨ ``Git`` å˜å‚¨åº“ä¸ï¼Œåˆ™
+å¯ä»¥ä½¿ç”¨ ``git format-patch`` 进行æ£ç¡®çš„è¡¥ä¸æ ¼å¼è®¾ç½®ã€‚ä½†æ˜¯ï¼Œè¿™äº›å·¥å…·æ— æ³•åˆ›å»º
+å¿…è¦çš„æ–‡æœ¬ï¼Œå› æ¤è¯·åŠ¡å¿…阅读下é¢çš„说明。
+
+æ ‡å‡†çš„è¡¥ä¸ï¼Œæ ‡é¢˜è¡Œæ˜¯::
+
+ Subject: [PATCH 001/123] å系统:一å¥è¯æ¦‚è¿°
+
+æ ‡å‡†è¡¥ä¸çš„信体å˜åœ¨å¦‚下部分：
+
+ - 一个 "from" 行指出补ä¸ä½œè€…。åŽè·Ÿç©ºè¡Œï¼ˆä»…当å‘é€ä¿®è¡¥ç¨‹åºçš„人ä¸æ˜¯ä½œè€…æ—¶æ‰éœ€è¦ï¼‰ã€‚
+
+ - 解释的æ£æ–‡ï¼Œè¡Œä»¥75列包装，这将被å¤åˆ¶åˆ°æ°¸ä¹…å˜æ›´æ—¥å¿—æ¥æ述这个补ä¸ã€‚
+
+ - 一个空行
+
+ - 上é¢æ述的“Signed-off-by†行，也将出现在更改日志ä¸ã€‚
+
+ - åªåŒ…å« ``---`` çš„æ ‡è®°çº¿ã€‚
+
+ - 任何其他ä¸é€‚åˆæ”¾åœ¨å˜æ›´æ—¥å¿—的注释。
+
+ - 实际补ä¸ï¼ˆ ``diff`` 输出）。
+
+æ ‡é¢˜è¡Œçš„æ ¼å¼ï¼Œä½¿å¾—å¯¹æ ‡é¢˜è¡ŒæŒ‰å—æ¯åºæŽ’åºéžå¸¸çš„容易 - 很多 e-mail 客户端都
+å¯ä»¥æ”¯æŒ - å› ä¸ºåºåˆ—å·æ˜¯ç”¨é›¶å¡«å……的，所以按数å—排åºå’ŒæŒ‰å—æ¯æŽ’åºæ˜¯ä¸€æ ·çš„。
+
+e-mail æ ‡é¢˜ä¸çš„“å系统â€æ ‡è¯†å“ªä¸ªå†…æ ¸å系统将被打补ä¸ã€‚
+
+e-mail æ ‡é¢˜ä¸çš„“一å¥è¯æ¦‚è¿°â€æ‰¼è¦çš„æè¿° e-mail ä¸çš„è¡¥ä¸ã€‚“一å¥è¯æ¦‚è¿°â€
+ä¸åº”该是一个文件å。对于一个补ä¸ç³»åˆ—（“补ä¸ç³»åˆ—â€æŒ‡ä¸€ç³»åˆ—的多个相关补
+ä¸ï¼‰ï¼Œä¸è¦å¯¹æ¯ä¸ªè¡¥ä¸éƒ½ä½¿ç”¨åŒæ ·çš„“一å¥è¯æ¦‚è¿°â€ã€‚
+
+è®°ä½ e-mail 的“一å¥è¯æ¦‚è¿°â€ä¼šæˆä¸ºè¯¥è¡¥ä¸çš„å…¨å±€å”¯ä¸€æ ‡è¯†ã€‚å®ƒä¼šè”“å»¶åˆ° git
+的改动记录里。然åŽâ€œä¸€å¥è¯æ¦‚è¿°â€ä¼šè¢«ç”¨åœ¨å¼€å‘者的讨论里，用æ¥æŒ‡ä»£è¿™ä¸ªè¡¥
+ä¸ã€‚用户将希望通过 google æ¥æœç´¢"一å¥è¯æ¦‚è¿°"æ¥æ‰¾åˆ°é‚£äº›è®¨è®ºè¿™ä¸ªè¡¥ä¸çš„æ–‡
+ç« ã€‚å½“äººä»¬åœ¨ä¸¤ä¸‰ä¸ªæœˆåŽä½¿ç”¨è¯¸å¦‚ ``gitk`` 或 ``git log --oneline`` 之类
+的工具查看数åƒä¸ªè¡¥ä¸æ—¶ï¼Œä¹Ÿä¼šå¾ˆå¿«çœ‹åˆ°å®ƒã€‚
+
+å‡ºäºŽè¿™äº›åŽŸå› ï¼Œæ¦‚è¿°å¿…é¡»ä¸è¶…过70-75个å—符，并且必须æè¿°è¡¥ä¸çš„更改以åŠä¸º
+什么需è¦è¡¥ä¸ã€‚æ—¢è¦ç®€æ´åˆè¦æè¿°æ€§å¾ˆæœ‰æŒ‘æˆ˜æ€§ï¼Œä½†å†™å¾—å¥½çš„æ¦‚è¿°åº”è¯¥è¿™æ ·åšã€‚
+
+概述的å‰ç¼€å¯ä»¥ç”¨æ–¹æ‹¬å·æ‹¬èµ·æ¥ï¼šâ€œSubject: [PATCH <tag>...] <概述>â€ã€‚æ ‡è®°
+ä¸è¢«è§†ä¸ºæ¦‚述的一部分，而是æ述应该如何处ç†è¡¥ä¸ã€‚如果补ä¸çš„多个版本已å‘
+é€å‡ºæ¥ä»¥å“应评审（å³â€œv1，v2，v3â€ï¼‰æˆ–“rfcâ€ï¼Œä»¥æŒ‡ç¤ºè¯„å®¡è¯·æ±‚ï¼Œé‚£ä¹ˆé€šç”¨æ ‡è®°
+å¯èƒ½åŒ…括版本æ述符。如果一个补ä¸ç³»åˆ—ä¸æœ‰å››ä¸ªè¡¥ä¸ï¼Œé‚£ä¹ˆå„个补ä¸å¯ä»¥è¿™æ ·
+ç¼–å·ï¼š1/4ã€2/4ã€3/4ã€4/4。这å¯ä»¥ç¡®ä¿å¼€å‘人员了解补ä¸åº”用的顺åºï¼Œå¹¶ä¸”他们
+å·²ç»æŸ¥çœ‹æˆ–应用了补ä¸ç³»åˆ—ä¸çš„所有补ä¸ã€‚
+
+ä¸€äº›æ ‡é¢˜çš„ä¾‹å::
+
+ Subject: [patch 2/5] ext2: improve scalability of bitmap searching
+ Subject: [PATCHv2 001/207] x86: fix eflags tracking
+
+"From" 行是信体里的最上é¢ä¸€è¡Œï¼Œå…·æœ‰å¦‚ä¸‹æ ¼å¼ï¼š
+ From: Patch Author <author@example.com>
+
+"From" 行指明在永久改动日志里，è°ä¼šè¢«ç¡®è®¤ä¸ºä½œè€…。如果没有 "From" 行，那
+么邮件头里的 "From: " 行会被用æ¥å†³å®šæ”¹åŠ¨æ—¥å¿—ä¸çš„作者。
+
+说明的主题将会被æ交到永久的æºä»£ç æ”¹åŠ¨æ—¥å¿—é‡Œï¼Œå› æ¤å¯¹é‚£äº›æ—©å·²ç»ä¸è®°å¾—å’Œ
+这个补ä¸ç›¸å…³çš„讨论细节的有能力的读者æ¥è¯´ï¼Œæ˜¯æœ‰æ„义的。包括补ä¸ç¨‹åºå®šä½
+é”™è¯¯çš„ï¼ˆå†…æ ¸æ—¥å¿—æ¶ˆæ¯ã€OOPS消æ¯ç‰ï¼‰ç—‡çŠ¶ï¼Œå¯¹äºŽæœç´¢æ交日志以寻找适用补ä¸çš„人
+尤其有用。如果一个补ä¸ä¿®å¤äº†ä¸€ä¸ªç¼–译失败，那么å¯èƒ½ä¸éœ€è¦åŒ…å«æ‰€æœ‰ç¼–译失败；
+åªè¦è¶³å¤Ÿè®©æœç´¢è¡¥ä¸çš„äººèƒ½å¤Ÿæ‰¾åˆ°å®ƒå°±è¡Œäº†ã€‚ä¸Žæ¦‚è¿°ä¸€æ ·ï¼Œæ—¢è¦ç®€æ´åˆè¦æ述性。
+
+"---" æ ‡è®°è¡Œå¯¹äºŽè¡¥ä¸å¤„ç†å·¥å…·è¦æ‰¾åˆ°å“ªé‡Œæ˜¯æ”¹åŠ¨æ—¥å¿—ä¿¡æ¯çš„结æŸï¼Œæ˜¯ä¸å¯ç¼ºå°‘
+的。
+
+对于 "---" æ ‡è®°ä¹‹åŽçš„é¢å¤–注解，一个好的用途就是用æ¥å†™ diffstat，用æ¥æ˜¾
+示修改了什么文件和æ¯ä¸ªæ–‡ä»¶éƒ½å¢žåŠ å’Œåˆ é™¤äº†å¤šå°‘è¡Œã€‚diffstat 对于比较大的补
+ä¸ç‰¹åˆ«æœ‰ç”¨ã€‚其余那些åªæ˜¯å’Œæ—¶åˆ»æˆ–者开å‘者相关的注解，ä¸åˆé€‚放到永久的改
+动日志里的，也应该放这里。
+使用 diffstat的选项 "-p 1 -w 70" è¿™æ ·æ–‡ä»¶åå°±ä¼šä»Žå†…æ ¸æºä»£ç æ ‘çš„ç›®å½•å¼€å§‹
+，ä¸ä¼šå 用太宽的空间（很容易适åˆ80列的宽度，也许会有一些缩进。）
+
+在åŽé¢çš„å‚考资料ä¸èƒ½çœ‹åˆ°é€‚当的补ä¸æ ¼å¼çš„更多细节。
+
+.. _cn_explicit_in_reply_to:
+
+15) 明确回å¤é‚®ä»¶å¤´(In-Reply-To)
+-------------------------------
+
+æ‰‹åŠ¨æ·»åŠ å›žå¤è¡¥ä¸çš„çš„æ ‡é¢˜å¤´(In-Reply_To:) 是有帮助的（例如，使用 ``git send-email`` ）
+将补ä¸ä¸Žä»¥å‰çš„相关讨论关è”èµ·æ¥ï¼Œä¾‹å¦‚，将bugä¿®å¤ç¨‹åºé“¾æŽ¥åˆ°ç”µå邮件和bug报告。
+但是，对于多补ä¸ç³»åˆ—，最好é¿å…在回å¤æ—¶ä½¿ç”¨é“¾æŽ¥åˆ°è¯¥ç³»åˆ—çš„æ—§ç‰ˆæœ¬ã€‚è¿™æ ·ï¼Œ
+è¡¥ä¸çš„多个版本就ä¸ä¼šæˆä¸ºç”µå邮件客户端ä¸æ— 法管ç†çš„引用åºåˆ—。如果链接有用，
+å¯ä»¥ä½¿ç”¨ https://lkml.kernel.org/ é‡å®šå‘器（例如，在å°é¢ç”µå邮件文本ä¸ï¼‰
+链接到补ä¸ç³»åˆ—的早期版本。
+
+16) å‘é€git pull请求
+--------------------
+
+如果您有一系列补ä¸ï¼Œé‚£ä¹ˆè®©ç»´æŠ¤äººå‘˜é€šè¿‡git pullæ“作将它们直接拉入å系统å˜å‚¨
+库å¯èƒ½æ˜¯æœ€æ–¹ä¾¿çš„。但是，请注æ„，从开å‘人员那里获å–è¡¥ä¸æ¯”从邮件列表ä¸èŽ·å–è¡¥
+ä¸éœ€è¦æ›´é«˜çš„ä¿¡ä»»åº¦ã€‚å› æ¤ï¼Œè®¸å¤šå系统维护人员ä¸æ„¿æ„接å—请求，特别是æ¥è‡ªæ–°çš„
+未知开å‘人员的请求。如果有疑问，您å¯ä»¥åœ¨å°é¢é‚®ä»¶ä¸ä½¿ç”¨pull 请求作为补ä¸ç³»åˆ—
+æ£å¸¸å‘布的一个选项，让维护人员å¯ä»¥é€‰æ‹©ä½¿ç”¨å…¶ä¸ä¹‹ä¸€ã€‚
+
+pull 请求的主题行ä¸åº”该有[Git Pull]。请求本身应该在一行ä¸åŒ…å«å˜å‚¨åº“å称和
+感兴趣的分支；它应该看起æ¥åƒ::
+
+ Please pull from
+
+ git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus
+
+ to get these changes:
+
+
+pull 请求还应该包å«ä¸€æ¡æ•´ä½“消æ¯ï¼Œè¯´æ˜Žè¯·æ±‚ä¸å°†åŒ…å«ä»€ä¹ˆï¼Œä¸€ä¸ªè¡¥ä¸æœ¬èº«çš„ ``Git shortlog``
+以åŠä¸€ä¸ªæ˜¾ç¤ºè¡¥ä¸ç³»åˆ—整体效果的 ``diffstat`` 。当然，将所有这些信æ¯æ”¶é›†åœ¨ä¸€èµ·
+的最简å•æ–¹æ³•æ˜¯è®© ``git`` 使用 ``git request-pull`` 命令为您完æˆè¿™äº›å·¥ä½œã€‚
+
+一些维护人员（包括Linus）希望看到æ¥è‡ªå·²ç¾åæäº¤çš„è¯·æ±‚ï¼›è¿™å¢žåŠ äº†ä»–ä»¬å¯¹ä½ çš„
+请求信心。特别是，在没有ç¾åæ ‡ç¾çš„情况下，Linus ä¸ä¼šä»Žåƒ Github è¿™æ ·çš„å…¬å…±
+托管站点拉请求。
+
+创建æ¤ç±»ç¾å的第一æ¥æ˜¯ç”Ÿæˆä¸€ä¸ª GNRPG å¯†é’¥ï¼Œå¹¶ç”±ä¸€ä¸ªæˆ–å¤šä¸ªæ ¸å¿ƒå†…æ ¸å¼€å‘人员对
+其进行ç¾å。这一æ¥å¯¹æ–°å¼€å‘人员æ¥è¯´å¯èƒ½å¾ˆå›°éš¾ï¼Œä½†æ²¡æœ‰åŠžæ³•ç»•è¿‡å®ƒã€‚å‚åŠ ä¼šè®®æ˜¯
+找到å¯ä»¥ç¾ç½²æ‚¨çš„密钥的开å‘人员的好方法。
+
+一旦您在Git ä¸å‡†å¤‡äº†ä¸€ä¸ªæ‚¨å¸Œæœ›æœ‰äººæ‹‰çš„è¡¥ä¸ç³»åˆ—，就用 ``git tag -s`` 创建一
+个ç¾åæ ‡è®°ã€‚è¿™å°†åˆ›å»ºä¸€ä¸ªæ–°æ ‡è®°ï¼Œæ ‡è¯†è¯¥ç³»åˆ—ä¸çš„最åŽä¸€æ¬¡æ交，并包å«ç”¨æ‚¨çš„ç§
+钥创建的ç¾å。您还å¯ä»¥å°†changelogæ ·å¼çš„消æ¯æ·»åŠ åˆ°æ ‡è®°ä¸ï¼›è¿™æ˜¯ä¸€ä¸ªæ述拉请求
+整体效果的ç†æƒ³ä½ç½®ã€‚
+
+如果维护人员将è¦ä»Žä¸æå–çš„æ ‘ä¸æ˜¯æ‚¨æ£åœ¨ä½¿ç”¨çš„å˜å‚¨åº“，请ä¸è¦å¿˜è®°å°†å·²ç¾åçš„æ ‡è®°
+显å¼æŽ¨é€åˆ°å…¬å…±æ ‘。
+
+生æˆæ‹‰è¯·æ±‚时，请使用已ç¾åçš„æ ‡è®°ä½œä¸ºç›®æ ‡ã€‚è¿™æ ·çš„å‘½ä»¤å¯ä»¥å®žçŽ°::
+
+ git request-pull master git://my.public.tree/linux.git my-signed-tag
+
+å‚考文献
+--------
+
+Andrew Morton, "The perfect patch" (tpp).
+ <http://www.ozlabs.org/~akpm/stuff/tpp.txt>
+
+Jeff Garzik, "Linux kernel patch submission format".
+ <http://linux.yyz.us/patch-format.html>
+
+Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
+ <http://www.kroah.com/log/linux/maintainer.html>
+
+ <http://www.kroah.com/log/linux/maintainer-02.html>
+
+ <http://www.kroah.com/log/linux/maintainer-03.html>
+
+ <http://www.kroah.com/log/linux/maintainer-04.html>
+
+ <http://www.kroah.com/log/linux/maintainer-05.html>
+
+ <http://www.kroah.com/log/linux/maintainer-06.html>
+
+NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
+ <https://lkml.org/lkml/2005/7/11/336>
+
+Kernel Documentation/process/coding-style.rst:
+ :ref:`Documentation/translations/zh_CN/process/coding-style.rst <cn_codingstyle>`
+
+Linus Torvalds's mail on the canonical patch format:
+ <http://lkml.org/lkml/2005/4/7/183>
+
+Andi Kleen, "On submitting kernel patches"
+ Some strategies to get difficult or controversial changes in.
+
+ http://halobates.de/on-submitting-patches.pdf
diff --git a/Documentation/translations/zh_CN/volatile-considered-harmful.txt b/Documentation/translations/zh_CN/process/volatile-considered-harmful.rst
similarity index 81%
rename from Documentation/translations/zh_CN/volatile-considered-harmful.txt
rename to Documentation/translations/zh_CN/process/volatile-considered-harmful.rst
index 47512596719747d1d6134e4f5020718d1515837f..48b32ce58ef11235ff8386e81d968c5dbf2d9b0c 100644
--- a/Documentation/translations/zh_CN/volatile-considered-harmful.txt
+++ b/Documentation/translations/zh_CN/process/volatile-considered-harmful.rst
@@ -1,30 +1,23 @@
-Chinese translated version of Documentation/process/volatile-considered-harmful.rst
+.. _cn_volatile_considered_harmful:
-If you have any comment or update to the content, please contact the
-original document maintainer directly. However, if you have a problem
-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.
+.. include:: ../disclaimer-zh_CN.rst
-Maintainer: Jonathan Corbet <corbet@lwn.net>
-Chinese maintainer: Bryan Wu <bryan.wu@analog.com>
----------------------------------------------------------------------
-Documentation/process/volatile-considered-harmful.rst çš„ä¸æ–‡ç¿»è¯‘
+:Original: :ref:`Documentation/process/volatile-considered-harmful.rst
+ <volatile_considered_harmful>`
如果想评论或更新本文的内容，请直接è”ç³»åŽŸæ–‡æ¡£çš„ç»´æŠ¤è€…ã€‚å¦‚æžœä½ ä½¿ç”¨è‹±æ–‡
交æµæœ‰å›°éš¾çš„è¯ï¼Œä¹Ÿå¯ä»¥å‘ä¸æ–‡ç‰ˆç»´æŠ¤è€…求助。如果本翻译更新ä¸åŠæ—¶æˆ–者翻
-译å˜åœ¨é—®é¢˜ï¼Œè¯·è”ç³»ä¸æ–‡ç‰ˆç»´æŠ¤è€…。
+译å˜åœ¨é—®é¢˜ï¼Œè¯·è”ç³»ä¸æ–‡ç‰ˆç»´æŠ¤è€…::
-英文版维护者： Jonathan Corbet <corbet@lwn.net>
-ä¸æ–‡ç‰ˆç»´æŠ¤è€…： ä¼é¹ Bryan Wu <bryan.wu@analog.com>
-ä¸æ–‡ç‰ˆç¿»è¯‘者： ä¼é¹ Bryan Wu <bryan.wu@analog.com>
-ä¸æ–‡ç‰ˆæ ¡è¯‘者： å¼ æ±‰è¾‰ Eugene Teo <eugeneteo@kernel.sg>
- æ¨ç‘ž Dave Young <hidave.darkstar@gmail.com>
-以下为æ£æ–‡
----------------------------------------------------------------------
+ 英文版维护者： Jonathan Corbet <corbet@lwn.net>
+ ä¸æ–‡ç‰ˆç»´æŠ¤è€…： ä¼é¹ Bryan Wu <bryan.wu@analog.com>
+ ä¸æ–‡ç‰ˆç¿»è¯‘者： ä¼é¹ Bryan Wu <bryan.wu@analog.com>
+ ä¸æ–‡ç‰ˆæ ¡è¯‘者： å¼ æ±‰è¾‰ Eugene Teo <eugeneteo@kernel.sg>
+ æ¨ç‘ž Dave Young <hidave.darkstar@gmail.com>
+ 时奎亮 Alex Shi <alex.shi@linux.alibaba.com>
为什么ä¸åº”该使用“volatileâ€ç±»åž‹
-------------------------------
+==============================
C程åºå‘˜é€šå¸¸è®¤ä¸ºvolatile表示æŸä¸ªå˜é‡å¯ä»¥åœ¨å½“å‰æ‰§è¡Œçš„线程之外被改å˜ï¼›å› æ¤ï¼Œåœ¨å†…æ ¸
ä¸ç”¨åˆ°å…±äº«æ•°æ®ç»“构时，常常会有C程åºå‘˜å–œæ¬¢ä½¿ç”¨volatile这类å˜é‡ã€‚æ¢å¥è¯è¯´ï¼Œä»–们ç»
@@ -41,7 +34,7 @@ C程åºå‘˜é€šå¸¸è®¤ä¸ºvolatile表示æŸä¸ªå˜é‡å¯ä»¥åœ¨å½“å‰æ‰§è¡Œçš„线程
å¿…è¦å†ä½¿ç”¨volatile。如果ä»ç„¶å¿…须使用volatileï¼Œé‚£ä¹ˆå‡ ä¹Žå¯ä»¥è‚¯å®šåœ¨ä»£ç çš„æŸå¤„有一
个bug。在æ£ç¡®è®¾è®¡çš„å†…æ ¸ä»£ç ä¸ï¼Œvolatile能带æ¥çš„仅仅是使事情å˜æ…¢ã€‚
-æ€è€ƒä¸€ä¸‹è¿™æ®µå…¸åž‹çš„å†…æ ¸ä»£ç ：
+æ€è€ƒä¸€ä¸‹è¿™æ®µå…¸åž‹çš„å†…æ ¸ä»£ç ::
spin_lock(&the_lock);
do_something_on(&shared_data);
@@ -66,7 +59,7 @@ volatileçš„å˜å‚¨ç±»åž‹æœ€åˆæ˜¯ä¸ºé‚£äº›å†…å˜æ˜ å°„çš„I/O寄å˜å™¨è€Œå®šä¹‰ã€‚
是必需的。
å¦ä¸€ç§å¼•èµ·ç”¨æˆ·å¯èƒ½ä½¿ç”¨volatile的情况是当处ç†å™¨æ£å¿™ç€ç‰å¾…一个å˜é‡çš„值。æ£ç¡®æ‰§è¡Œä¸€
-个忙ç‰å¾…的方法是：
+个忙ç‰å¾…的方法是::
while (my_variable != what_i_want)
cpu_relax();
diff --git a/Documentation/translations/zh_CN/sparse.txt b/Documentation/translations/zh_CN/sparse.txt
index 2f728962a8e2386c1b855541b9adc0a2f097ddb8..47fc4a06ebe8e9204666bec7319aa2354e971e78 100644
--- a/Documentation/translations/zh_CN/sparse.txt
+++ b/Documentation/translations/zh_CN/sparse.txt
@@ -6,7 +6,7 @@ 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.
-Chinese maintainer: Li Yang <leo@zh-kernel.org>
+Chinese maintainer: Li Yang <leoyang.li@nxp.com>
---------------------------------------------------------------------
Documentation/dev-tools/sparse.rst çš„ä¸æ–‡ç¿»è¯‘
@@ -14,8 +14,8 @@ Documentation/dev-tools/sparse.rst çš„ä¸æ–‡ç¿»è¯‘
交æµæœ‰å›°éš¾çš„è¯ï¼Œä¹Ÿå¯ä»¥å‘ä¸æ–‡ç‰ˆç»´æŠ¤è€…求助。如果本翻译更新ä¸åŠæ—¶æˆ–者翻
译å˜åœ¨é—®é¢˜ï¼Œè¯·è”ç³»ä¸æ–‡ç‰ˆç»´æŠ¤è€…。
-ä¸æ–‡ç‰ˆç»´æŠ¤è€…： æŽé˜³ Li Yang <leo@zh-kernel.org>
-ä¸æ–‡ç‰ˆç¿»è¯‘者： æŽé˜³ Li Yang <leo@zh-kernel.org>
+ä¸æ–‡ç‰ˆç»´æŠ¤è€…： æŽé˜³ Li Yang <leoyang.li@nxp.com>
+ä¸æ–‡ç‰ˆç¿»è¯‘者： æŽé˜³ Li Yang <leoyang.li@nxp.com>
以下为æ£æ–‡
diff --git a/Documentation/unaligned-memory-access.txt b/Documentation/unaligned-memory-access.txt
index 51b4ff0315865ff1723c9a12442fd8574de7d011..1ee82419d8aa66929a5a52fac89a62c7f54d0644 100644
--- a/Documentation/unaligned-memory-access.txt
+++ b/Documentation/unaligned-memory-access.txt
@@ -1,5 +1,5 @@
=========================
-UNALIGNED MEMORY ACCESSES
+Unaligned Memory Accesses
=========================
:Author: Daniel Drake <dsd@gentoo.org>,
diff --git a/Documentation/userspace-api/seccomp_filter.rst b/Documentation/userspace-api/seccomp_filter.rst
index b1b846d8a0946de5e5540e322925bbc4da30d1f5..bd9165241b6c8970754c5ab7b84087b4eb251ba5 100644
--- a/Documentation/userspace-api/seccomp_filter.rst
+++ b/Documentation/userspace-api/seccomp_filter.rst
@@ -123,9 +123,9 @@ In precedence order, they are:
to userland as the errno without executing the system call.
``SECCOMP_RET_USER_NOTIF``:
- Results in a ``struct seccomp_notif`` message sent on the userspace
- notification fd, if it is attached, or ``-ENOSYS`` if it is not. See below
- on discussion of how to handle user notifications.
+ Results in a ``struct seccomp_notif`` message sent on the userspace
+ notification fd, if it is attached, or ``-ENOSYS`` if it is not. See
+ below on discussion of how to handle user notifications.
``SECCOMP_RET_TRACE``:
When returned, this value will cause the kernel to attempt to
@@ -133,7 +133,7 @@ In precedence order, they are:
call. If there is no tracer present, ``-ENOSYS`` is returned to
userland and the system call is not executed.
- A tracer will be notified if it requests ``PTRACE_O_TRACESECCOM``P
+ A tracer will be notified if it requests ``PTRACE_O_TRACESECCOMP``
using ``ptrace(PTRACE_SETOPTIONS)``. The tracer will be notified
of a ``PTRACE_EVENT_SECCOMP`` and the ``SECCOMP_RET_DATA`` portion of
the BPF program return value will be available to the tracer
diff --git a/Documentation/video-output.txt b/Documentation/video-output.txt
index e517011be4f964db7b452e1e50420eaed83f143d..56d6fa2e23688f0a49b1e0b5bb74d76cc9b2b2e8 100644
--- a/Documentation/video-output.txt
+++ b/Documentation/video-output.txt
@@ -1,34 +1,34 @@
+Video Output Switcher Control
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Video Output Switcher Control
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- 2006 luming.yu@intel.com
+2006 luming.yu@intel.com
The output sysfs class driver provides an abstract video output layer that
can be used to hook platform specific methods to enable/disable video output
device through common sysfs interface. For example, on my IBM ThinkPad T42
laptop, The ACPI video driver registered its output devices and read/write
-method for 'state' with output sysfs class. The user interface under sysfs is:
+method for 'state' with output sysfs class. The user interface under sysfs is::
-linux:/sys/class/video_output # tree .
-.
-|-- CRT0
-| |-- device -> ../../../devices/pci0000:00/0000:00:01.0
-| |-- state
-| |-- subsystem -> ../../../class/video_output
-| `-- uevent
-|-- DVI0
-| |-- device -> ../../../devices/pci0000:00/0000:00:01.0
-| |-- state
-| |-- subsystem -> ../../../class/video_output
-| `-- uevent
-|-- LCD0
-| |-- device -> ../../../devices/pci0000:00/0000:00:01.0
-| |-- state
-| |-- subsystem -> ../../../class/video_output
-| `-- uevent
-`-- TV0
- |-- device -> ../../../devices/pci0000:00/0000:00:01.0
- |-- state
- |-- subsystem -> ../../../class/video_output
- `-- uevent
+ linux:/sys/class/video_output # tree .
+ .
+ |-- CRT0
+ | |-- device -> ../../../devices/pci0000:00/0000:00:01.0
+ | |-- state
+ | |-- subsystem -> ../../../class/video_output
+ | `-- uevent
+ |-- DVI0
+ | |-- device -> ../../../devices/pci0000:00/0000:00:01.0
+ | |-- state
+ | |-- subsystem -> ../../../class/video_output
+ | `-- uevent
+ |-- LCD0
+ | |-- device -> ../../../devices/pci0000:00/0000:00:01.0
+ | |-- state
+ | |-- subsystem -> ../../../class/video_output
+ | `-- uevent
+ `-- TV0
+ |-- device -> ../../../devices/pci0000:00/0000:00:01.0
+ |-- state
+ |-- subsystem -> ../../../class/video_output
+ `-- uevent
diff --git a/Documentation/vm/hugetlbfs_reserv.rst b/Documentation/vm/hugetlbfs_reserv.rst
index 9d200762114f67b9b062431632d7ff6fc25b6f8c..f143954e0d05682e8282b5f8bf1018f9e7f61e70 100644
--- a/Documentation/vm/hugetlbfs_reserv.rst
+++ b/Documentation/vm/hugetlbfs_reserv.rst
@@ -85,10 +85,10 @@ Reservation Map Location (Private or Shared)
A huge page mapping or segment is either private or shared. If private,
it is typically only available to a single address space (task). If shared,
it can be mapped into multiple address spaces (tasks). The location and
-semantics of the reservation map is significantly different for two types
+semantics of the reservation map is significantly different for the two types
of mappings. Location differences are:
-- For private mappings, the reservation map hangs off the the VMA structure.
+- For private mappings, the reservation map hangs off the VMA structure.
Specifically, vma->vm_private_data. This reserve map is created at the
time the mapping (mmap(MAP_PRIVATE)) is created.
- For shared mappings, the reservation map hangs off the inode. Specifically,
@@ -109,15 +109,15 @@ These operations result in a call to the routine hugetlb_reserve_pages()::
struct vm_area_struct *vma,
vm_flags_t vm_flags)
-The first thing hugetlb_reserve_pages() does is check for the NORESERVE
+The first thing hugetlb_reserve_pages() does is check if the NORESERVE
flag was specified in either the shmget() or mmap() call. If NORESERVE
-was specified, then this routine returns immediately as no reservation
+was specified, then this routine returns immediately as no reservations
are desired.
The arguments 'from' and 'to' are huge page indices into the mapping or
underlying file. For shmget(), 'from' is always 0 and 'to' corresponds to
the length of the segment/mapping. For mmap(), the offset argument could
-be used to specify the offset into the underlying file. In such a case
+be used to specify the offset into the underlying file. In such a case,
the 'from' and 'to' arguments have been adjusted by this offset.
One of the big differences between PRIVATE and SHARED mappings is the way
@@ -138,7 +138,8 @@ to indicate this VMA owns the reservations.
The reservation map is consulted to determine how many huge page reservations
are needed for the current mapping/segment. For private mappings, this is
-always the value (to - from). However, for shared mappings it is possible that some reservations may already exist within the range (to - from). See the
+always the value (to - from). However, for shared mappings it is possible that
+some reservations may already exist within the range (to - from). See the
section :ref:`Reservation Map Modifications <resv_map_modifications>`
for details on how this is accomplished.
@@ -165,7 +166,7 @@ these counters.
If there were enough free huge pages and the global count resv_huge_pages
was adjusted, then the reservation map associated with the mapping is
modified to reflect the reservations. In the case of a shared mapping, a
-file_region will exist that includes the range 'from' 'to'. For private
+file_region will exist that includes the range 'from' - 'to'. For private
mappings, no modifications are made to the reservation map as lack of an
entry indicates a reservation exists.
@@ -239,7 +240,7 @@ subpool accounting when the page is freed.
The routine vma_commit_reservation() is then called to adjust the reserve
map based on the consumption of the reservation. In general, this involves
ensuring the page is represented within a file_region structure of the region
-map. For shared mappings where the the reservation was present, an entry
+map. For shared mappings where the reservation was present, an entry
in the reserve map already existed so no change is made. However, if there
was no reservation in a shared mapping or this was a private mapping a new
entry must be created.
diff --git a/Documentation/vm/index.rst b/Documentation/vm/index.rst
index b58cc3bfe777145d450a2f08a3fb8b08114948d6..e8d943b21cf925137663f8ebdf8edc187757cba5 100644
--- a/Documentation/vm/index.rst
+++ b/Documentation/vm/index.rst
@@ -37,6 +37,7 @@ descriptions of data structures and algorithms.
hwpoison
hugetlbfs_reserv
ksm
+ memory-model
mmu_notifier
numa
overcommit-accounting
diff --git a/Documentation/vm/memory-model.rst b/Documentation/vm/memory-model.rst
new file mode 100644
index 0000000000000000000000000000000000000000..382f72ace1fcab0d1826b3cdc25f093772899d64
--- /dev/null
+++ b/Documentation/vm/memory-model.rst
@@ -0,0 +1,183 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _physical_memory_model:
+
+=====================
+Physical Memory Model
+=====================
+
+Physical memory in a system may be addressed in different ways. The
+simplest case is when the physical memory starts at address 0 and
+spans a contiguous range up to the maximal address. It could be,
+however, that this range contains small holes that are not accessible
+for the CPU. Then there could be several contiguous ranges at
+completely distinct addresses. And, don't forget about NUMA, where
+different memory banks are attached to different CPUs.
+
+Linux abstracts this diversity using one of the three memory models:
+FLATMEM, DISCONTIGMEM and SPARSEMEM. Each architecture defines what
+memory models it supports, what the default memory model is and
+whether it is possible to manually override that default.
+
+.. note::
+ At time of this writing, DISCONTIGMEM is considered deprecated,
+ although it is still in use by several architectures.
+
+All the memory models track the status of physical page frames using
+:c:type:`struct page` arranged in one or more arrays.
+
+Regardless of the selected memory model, there exists one-to-one
+mapping between the physical page frame number (PFN) and the
+corresponding `struct page`.
+
+Each memory model defines :c:func:`pfn_to_page` and :c:func:`page_to_pfn`
+helpers that allow the conversion from PFN to `struct page` and vice
+versa.
+
+FLATMEM
+=======
+
+The simplest memory model is FLATMEM. This model is suitable for
+non-NUMA systems with contiguous, or mostly contiguous, physical
+memory.
+
+In the FLATMEM memory model, there is a global `mem_map` array that
+maps the entire physical memory. For most architectures, the holes
+have entries in the `mem_map` array. The `struct page` objects
+corresponding to the holes are never fully initialized.
+
+To allocate the `mem_map` array, architecture specific setup code
+should call :c:func:`free_area_init_node` function or its convenience
+wrapper :c:func:`free_area_init`. Yet, the mappings array is not
+usable until the call to :c:func:`memblock_free_all` that hands all
+the memory to the page allocator.
+
+If an architecture enables `CONFIG_ARCH_HAS_HOLES_MEMORYMODEL` option,
+it may free parts of the `mem_map` array that do not cover the
+actual physical pages. In such case, the architecture specific
+:c:func:`pfn_valid` implementation should take the holes in the
+`mem_map` into account.
+
+With FLATMEM, the conversion between a PFN and the `struct page` is
+straightforward: `PFN - ARCH_PFN_OFFSET` is an index to the
+`mem_map` array.
+
+The `ARCH_PFN_OFFSET` defines the first page frame number for
+systems with physical memory starting at address different from 0.
+
+DISCONTIGMEM
+============
+
+The DISCONTIGMEM model treats the physical memory as a collection of
+`nodes` similarly to how Linux NUMA support does. For each node Linux
+constructs an independent memory management subsystem represented by
+`struct pglist_data` (or `pg_data_t` for short). Among other
+things, `pg_data_t` holds the `node_mem_map` array that maps
+physical pages belonging to that node. The `node_start_pfn` field of
+`pg_data_t` is the number of the first page frame belonging to that
+node.
+
+The architecture setup code should call :c:func:`free_area_init_node` for
+each node in the system to initialize the `pg_data_t` object and its
+`node_mem_map`.
+
+Every `node_mem_map` behaves exactly as FLATMEM's `mem_map` -
+every physical page frame in a node has a `struct page` entry in the
+`node_mem_map` array. When DISCONTIGMEM is enabled, a portion of the
+`flags` field of the `struct page` encodes the node number of the
+node hosting that page.
+
+The conversion between a PFN and the `struct page` in the
+DISCONTIGMEM model became slightly more complex as it has to determine
+which node hosts the physical page and which `pg_data_t` object
+holds the `struct page`.
+
+Architectures that support DISCONTIGMEM provide :c:func:`pfn_to_nid`
+to convert PFN to the node number. The opposite conversion helper
+:c:func:`page_to_nid` is generic as it uses the node number encoded in
+page->flags.
+
+Once the node number is known, the PFN can be used to index
+appropriate `node_mem_map` array to access the `struct page` and
+the offset of the `struct page` from the `node_mem_map` plus
+`node_start_pfn` is the PFN of that page.
+
+SPARSEMEM
+=========
+
+SPARSEMEM is the most versatile memory model available in Linux and it
+is the only memory model that supports several advanced features such
+as hot-plug and hot-remove of the physical memory, alternative memory
+maps for non-volatile memory devices and deferred initialization of
+the memory map for larger systems.
+
+The SPARSEMEM model presents the physical memory as a collection of
+sections. A section is represented with :c:type:`struct mem_section`
+that contains `section_mem_map` that is, logically, a pointer to an
+array of struct pages. However, it is stored with some other magic
+that aids the sections management. The section size and maximal number
+of section is specified using `SECTION_SIZE_BITS` and
+`MAX_PHYSMEM_BITS` constants defined by each architecture that
+supports SPARSEMEM. While `MAX_PHYSMEM_BITS` is an actual width of a
+physical address that an architecture supports, the
+`SECTION_SIZE_BITS` is an arbitrary value.
+
+The maximal number of sections is denoted `NR_MEM_SECTIONS` and
+defined as
+
+.. math::
+
+ NR\_MEM\_SECTIONS = 2 ^ {(MAX\_PHYSMEM\_BITS - SECTION\_SIZE\_BITS)}
+
+The `mem_section` objects are arranged in a two-dimensional array
+called `mem_sections`. The size and placement of this array depend
+on `CONFIG_SPARSEMEM_EXTREME` and the maximal possible number of
+sections:
+
+* When `CONFIG_SPARSEMEM_EXTREME` is disabled, the `mem_sections`
+ array is static and has `NR_MEM_SECTIONS` rows. Each row holds a
+ single `mem_section` object.
+* When `CONFIG_SPARSEMEM_EXTREME` is enabled, the `mem_sections`
+ array is dynamically allocated. Each row contains PAGE_SIZE worth of
+ `mem_section` objects and the number of rows is calculated to fit
+ all the memory sections.
+
+The architecture setup code should call :c:func:`memory_present` for
+each active memory range or use :c:func:`memblocks_present` or
+:c:func:`sparse_memory_present_with_active_regions` wrappers to
+initialize the memory sections. Next, the actual memory maps should be
+set up using :c:func:`sparse_init`.
+
+With SPARSEMEM there are two possible ways to convert a PFN to the
+corresponding `struct page` - a "classic sparse" and "sparse
+vmemmap". The selection is made at build time and it is determined by
+the value of `CONFIG_SPARSEMEM_VMEMMAP`.
+
+The classic sparse encodes the section number of a page in page->flags
+and uses high bits of a PFN to access the section that maps that page
+frame. Inside a section, the PFN is the index to the array of pages.
+
+The sparse vmemmap uses a virtually mapped memory map to optimize
+pfn_to_page and page_to_pfn operations. There is a global `struct
+page *vmemmap` pointer that points to a virtually contiguous array of
+`struct page` objects. A PFN is an index to that array and the the
+offset of the `struct page` from `vmemmap` is the PFN of that
+page.
+
+To use vmemmap, an architecture has to reserve a range of virtual
+addresses that will map the physical pages containing the memory
+map and make sure that `vmemmap` points to that range. In addition,
+the architecture should implement :c:func:`vmemmap_populate` method
+that will allocate the physical memory and create page tables for the
+virtual memory map. If an architecture does not have any special
+requirements for the vmemmap mappings, it can use default
+:c:func:`vmemmap_populate_basepages` provided by the generic memory
+management.
+
+The virtually mapped memory map allows storing `struct page` objects
+for persistent memory devices in pre-allocated storage on those
+devices. This storage is represented with :c:type:`struct vmem_altmap`
+that is eventually passed to vmemmap_populate() through a long chain
+of function calls. The vmemmap_populate() implementation may use the
+`vmem_altmap` along with :c:func:`altmap_alloc_block_buf` helper to
+allocate memory map on the persistent memory device.
diff --git a/Documentation/vm/numa.rst b/Documentation/vm/numa.rst
index 185d8a5681681183e1e6429c53542699d9110687..5cae13e9a08b76968e109742ac9dd71806ed9af3 100644
--- a/Documentation/vm/numa.rst
+++ b/Documentation/vm/numa.rst
@@ -109,8 +109,8 @@ System administrators and application designers can restrict a task's migration
to improve NUMA locality using various CPU affinity command line interfaces,
such as taskset(1) and numactl(1), and program interfaces such as
sched_setaffinity(2). Further, one can modify the kernel's default local
-allocation behavior using Linux NUMA memory policy.
-[see Documentation/admin-guide/mm/numa_memory_policy.rst.]
+allocation behavior using Linux NUMA memory policy. [see
+:ref:`Documentation/admin-guide/mm/numa_memory_policy.rst <numa_memory_policy>`].
System administrators can restrict the CPUs and nodes' memories that a non-
privileged user can specify in the scheduling or NUMA commands and functions
diff --git a/Documentation/vm/transhuge.rst b/Documentation/vm/transhuge.rst
index a8cf6809e36e4d37b0c61904f19d20ab23aabda1..37c57ca326297a500a507e036bde0aeeaa47c0d2 100644
--- a/Documentation/vm/transhuge.rst
+++ b/Documentation/vm/transhuge.rst
@@ -4,8 +4,9 @@
Transparent Hugepage Support
============================
-This document describes design principles Transparent Hugepage (THP)
-Support and its interaction with other parts of the memory management.
+This document describes design principles for Transparent Hugepage (THP)
+support and its interaction with other parts of the memory management
+system.
Design principles
=================
@@ -37,31 +38,25 @@ get_user_pages and follow_page
get_user_pages and follow_page if run on a hugepage, will return the
head or tail pages as usual (exactly as they would do on
-hugetlbfs). Most gup users will only care about the actual physical
+hugetlbfs). Most GUP users will only care about the actual physical
address of the page and its temporary pinning to release after the I/O
is complete, so they won't ever notice the fact the page is huge. But
if any driver is going to mangle over the page structure of the tail
page (like for checking page->mapping or other bits that are relevant
for the head page and not the tail page), it should be updated to jump
-to check head page instead. Taking reference on any head/tail page would
-prevent page from being split by anyone.
+to check head page instead. Taking a reference on any head/tail page would
+prevent the page from being split by anyone.
.. note::
these aren't new constraints to the GUP API, and they match the
- same constrains that applies to hugetlbfs too, so any driver capable
+ same constraints that apply to hugetlbfs too, so any driver capable
of handling GUP on hugetlbfs will also work fine on transparent
hugepage backed mappings.
In case you can't handle compound pages if they're returned by
-follow_page, the FOLL_SPLIT bit can be specified as parameter to
+follow_page, the FOLL_SPLIT bit can be specified as a parameter to
follow_page, so that it will split the hugepages before returning
-them. Migration for example passes FOLL_SPLIT as parameter to
-follow_page because it's not hugepage aware and in fact it can't work
-at all on hugetlbfs (but it instead works fine on transparent
-hugepages thanks to FOLL_SPLIT). migration simply can't deal with
-hugepages being returned (as it's not only checking the pfn of the
-page and pinning it during the copy but it pretends to migrate the
-memory in regular page sizes and with regular pte/pmd mappings).
+them.
Graceful fallback
=================
@@ -72,11 +67,11 @@ pmd_offset. It's trivial to make the code transparent hugepage aware
by just grepping for "pmd_offset" and adding split_huge_pmd where
missing after pmd_offset returns the pmd. Thanks to the graceful
fallback design, with a one liner change, you can avoid to write
-hundred if not thousand of lines of complex code to make your code
+hundreds if not thousands of lines of complex code to make your code
hugepage aware.
If you're not walking pagetables but you run into a physical hugepage
-but you can't handle it natively in your code, you can split it by
+that you can't handle natively in your code, you can split it by
calling split_huge_page(page). This is what the Linux VM does before
it tries to swapout the hugepage for example. split_huge_page() can fail
if the page is pinned and you must handle this correctly.
@@ -103,18 +98,18 @@ split_huge_page() or split_huge_pmd() has a cost.
To make pagetable walks huge pmd aware, all you need to do is to call
pmd_trans_huge() on the pmd returned by pmd_offset. You must hold the
-mmap_sem in read (or write) mode to be sure an huge pmd cannot be
+mmap_sem in read (or write) mode to be sure a huge pmd cannot be
created from under you by khugepaged (khugepaged collapse_huge_page
takes the mmap_sem in write mode in addition to the anon_vma lock). If
pmd_trans_huge returns false, you just fallback in the old code
paths. If instead pmd_trans_huge returns true, you have to take the
page table lock (pmd_lock()) and re-run pmd_trans_huge. Taking the
-page table lock will prevent the huge pmd to be converted into a
+page table lock will prevent the huge pmd being converted into a
regular pmd from under you (split_huge_pmd can run in parallel to the
pagetable walk). If the second pmd_trans_huge returns false, you
should just drop the page table lock and fallback to the old code as
-before. Otherwise you can proceed to process the huge pmd and the
-hugepage natively. Once finished you can drop the page table lock.
+before. Otherwise, you can proceed to process the huge pmd and the
+hugepage natively. Once finished, you can drop the page table lock.
Refcounts and transparent huge pages
====================================
@@ -122,61 +117,61 @@ Refcounts and transparent huge pages
Refcounting on THP is mostly consistent with refcounting on other compound
pages:
- - get_page()/put_page() and GUP operate in head page's ->_refcount.
+ - get_page()/put_page() and GUP operate on head page's ->_refcount.
- ->_refcount in tail pages is always zero: get_page_unless_zero() never
- succeed on tail pages.
+ succeeds on tail pages.
- map/unmap of the pages with PTE entry increment/decrement ->_mapcount
on relevant sub-page of the compound page.
- - map/unmap of the whole compound page accounted in compound_mapcount
+ - map/unmap of the whole compound page is accounted for in compound_mapcount
(stored in first tail page). For file huge pages, we also increment
->_mapcount of all sub-pages in order to have race-free detection of
last unmap of subpages.
PageDoubleMap() indicates that the page is *possibly* mapped with PTEs.
-For anonymous pages PageDoubleMap() also indicates ->_mapcount in all
+For anonymous pages, PageDoubleMap() also indicates ->_mapcount in all
subpages is offset up by one. This additional reference is required to
get race-free detection of unmap of subpages when we have them mapped with
both PMDs and PTEs.
-This is optimization required to lower overhead of per-subpage mapcount
-tracking. The alternative is alter ->_mapcount in all subpages on each
+This optimization is required to lower the overhead of per-subpage mapcount
+tracking. The alternative is to alter ->_mapcount in all subpages on each
map/unmap of the whole compound page.
-For anonymous pages, we set PG_double_map when a PMD of the page got split
-for the first time, but still have PMD mapping. The additional references
-go away with last compound_mapcount.
+For anonymous pages, we set PG_double_map when a PMD of the page is split
+for the first time, but still have a PMD mapping. The additional references
+go away with the last compound_mapcount.
-File pages get PG_double_map set on first map of the page with PTE and
-goes away when the page gets evicted from page cache.
+File pages get PG_double_map set on the first map of the page with PTE and
+goes away when the page gets evicted from the page cache.
split_huge_page internally has to distribute the refcounts in the head
page to the tail pages before clearing all PG_head/tail bits from the page
structures. It can be done easily for refcounts taken by page table
-entries. But we don't have enough information on how to distribute any
+entries, but we don't have enough information on how to distribute any
additional pins (i.e. from get_user_pages). split_huge_page() fails any
-requests to split pinned huge page: it expects page count to be equal to
-sum of mapcount of all sub-pages plus one (split_huge_page caller must
-have reference for head page).
+requests to split pinned huge pages: it expects page count to be equal to
+the sum of mapcount of all sub-pages plus one (split_huge_page caller must
+have a reference to the head page).
split_huge_page uses migration entries to stabilize page->_refcount and
-page->_mapcount of anonymous pages. File pages just got unmapped.
+page->_mapcount of anonymous pages. File pages just get unmapped.
-We safe against physical memory scanners too: the only legitimate way
-scanner can get reference to a page is get_page_unless_zero().
+We are safe against physical memory scanners too: the only legitimate way
+a scanner can get a reference to a page is get_page_unless_zero().
All tail pages have zero ->_refcount until atomic_add(). This prevents the
scanner from getting a reference to the tail page up to that point. After the
-atomic_add() we don't care about the ->_refcount value. We already known how
+atomic_add() we don't care about the ->_refcount value. We already know how
many references should be uncharged from the head page.
For head page get_page_unless_zero() will succeed and we don't mind. It's
-clear where reference should go after split: it will stay on head page.
+clear where references should go after split: it will stay on the head page.
-Note that split_huge_pmd() doesn't have any limitation on refcounting:
+Note that split_huge_pmd() doesn't have any limitations on refcounting:
pmd can be split at any point and never fails.
Partial unmap and deferred_split_huge_page()
@@ -188,10 +183,10 @@ in page_remove_rmap() and queue the THP for splitting if memory pressure
comes. Splitting will free up unused subpages.
Splitting the page right away is not an option due to locking context in
-the place where we can detect partial unmap. It's also might be
+the place where we can detect partial unmap. It also might be
counterproductive since in many cases partial unmap happens during exit(2) if
a THP crosses a VMA boundary.
-Function deferred_split_huge_page() is used to queue page for splitting.
+The function deferred_split_huge_page() is used to queue a page for splitting.
The splitting itself will happen when we get memory pressure via shrinker
interface.
diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt
index f4c2a97bfdbd0d1ed058013b7dbce161d5fb6d9a..223e484a1304961c86667c3b420cf7059009bfe2 100644
--- a/Documentation/x86/boot.txt
+++ b/Documentation/x86/boot.txt
@@ -61,6 +61,10 @@ Protocol 2.12: (Kernel 3.8) Added the xloadflags field and extension fields
to struct boot_params for loading bzImage and ramdisk
above 4G in 64bit.
+Protocol 2.13: (Kernel 3.14) Support 32- and 64-bit flags being set in
+ xloadflags to support booting a 64-bit kernel from 32-bit
+ EFI
+
**** MEMORY LAYOUT
The traditional memory map for the kernel loader, used for Image or
diff --git a/LICENSES/other/GPL-1.0 b/LICENSES/deprecated/GPL-1.0
similarity index 100%
rename from LICENSES/other/GPL-1.0
rename to LICENSES/deprecated/GPL-1.0
diff --git a/LICENSES/other/ISC b/LICENSES/deprecated/ISC
similarity index 100%
rename from LICENSES/other/ISC
rename to LICENSES/deprecated/ISC
diff --git a/LICENSES/other/Linux-OpenIB b/LICENSES/deprecated/Linux-OpenIB
similarity index 100%
rename from LICENSES/other/Linux-OpenIB
rename to LICENSES/deprecated/Linux-OpenIB
diff --git a/LICENSES/other/X11 b/LICENSES/deprecated/X11
similarity index 100%
rename from LICENSES/other/X11
rename to LICENSES/deprecated/X11
diff --git a/LICENSES/other/Apache-2.0 b/LICENSES/dual/Apache-2.0
similarity index 97%
rename from LICENSES/other/Apache-2.0
rename to LICENSES/dual/Apache-2.0
index 7cd903f573e53f2e05f2da52762bed4def6f0fbf..6e89ddeab187e08398d1b7804fc740ca0e1c427c 100644
--- a/LICENSES/other/Apache-2.0
+++ b/LICENSES/dual/Apache-2.0
@@ -1,6 +1,10 @@
Valid-License-Identifier: Apache-2.0
SPDX-URL: https://spdx.org/licenses/Apache-2.0.html
Usage-Guide:
+ Do NOT use. The Apache-2.0 is not GPL2 compatible. It may only be used
+ for dual-licensed files where the other license is GPL2 compatible.
+ If you end up using this it MUST be used together with a GPL2 compatible
+ license using "OR".
To use the Apache License version 2.0 put the following SPDX tag/value
pair into a comment according to the placement guidelines in the
licensing rules documentation:
diff --git a/LICENSES/other/CDDL-1.0 b/LICENSES/dual/CDDL-1.0
similarity index 99%
rename from LICENSES/other/CDDL-1.0
rename to LICENSES/dual/CDDL-1.0
index 25f614276ddde1aa528b7d6e3364dd653f1be6d6..b0ca1016db79a974de66c5e0ddee8b7ef6c9cad1 100644
--- a/LICENSES/other/CDDL-1.0
+++ b/LICENSES/dual/CDDL-1.0
@@ -1,8 +1,8 @@
Valid-License-Identifier: CDDL-1.0
SPDX-URL: https://spdx.org/licenses/CDDL-1.0.html
Usage-Guide:
- Do NOT use. The CDDL-1.0 is not GPL compatible. It may only be used for
- dual-licensed files where the other license is GPL compatible.
+ Do NOT use. The CDDL-1.0 is not GPL2 compatible. It may only be used for
+ dual-licensed files where the other license is GPL2 compatible.
If you end up using this it MUST be used together with a GPL2 compatible
license using "OR".
To use the Common Development and Distribution License 1.0 put the
diff --git a/LICENSES/other/MPL-1.1 b/LICENSES/dual/MPL-1.1
similarity index 99%
rename from LICENSES/other/MPL-1.1
rename to LICENSES/dual/MPL-1.1
index 568b6049efe6739fec170a4cb1266ec5f88916ba..61706859e1b2a000e0dcec5d2c0fbf6c64fbee9d 100644
--- a/LICENSES/other/MPL-1.1
+++ b/LICENSES/dual/MPL-1.1
@@ -1,6 +1,10 @@
Valid-License-Identifier: MPL-1.1
SPDX-URL: https://spdx.org/licenses/MPL-1.1.html
Usage-Guide:
+ Do NOT use. The MPL-1.1 is not GPL2 compatible. It may only be used for
+ dual-licensed files where the other license is GPL2 compatible.
+ If you end up using this it MUST be used together with a GPL2 compatible
+ license using "OR".
To use the Mozilla Public License version 1.1 put the following SPDX
tag/value pair into a comment according to the placement guidelines in
the licensing rules documentation:
diff --git a/MAINTAINERS b/MAINTAINERS
index e897d952100044976c8ca8fea2d01e92fb5b9dbe..4244dd341eb779521a745e250e1ca0fd7253a0b7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3737,8 +3737,8 @@ F: scripts/checkpatch.pl
CHINESE DOCUMENTATION
M: Harry Wei <harryxiyou@gmail.com>
+M: Alex Shi <alex.shi@linux.alibaba.com>
L: xiyoulinuxkernelgroup@googlegroups.com (subscribers-only)
-L: linux-kernel@zh-kernel.org (moderated for non-subscribers)
S: Maintained
F: Documentation/translations/zh_CN/
diff --git a/include/linux/wait.h b/include/linux/wait.h
index 5f3efabc36f4bb27af254bd7533e6c869bb68aaa..b6f77cf60dd7bbf8154aa56a3ea0bb2631221981 100644
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@ -101,7 +101,7 @@ init_waitqueue_func_entry(struct wait_queue_entry *wq_entry, wait_queue_func_t f
* lead to sporadic and non-obvious failure.
*
* Use either while holding wait_queue_head::lock or when used for wakeups
- * with an extra smp_mb() like:
+ * with an extra smp_mb() like::
*
* CPU0 - waker CPU1 - waiter
*
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index a09333fd7cef81053bf204dd03a4db07bbb833ef..bb28b178d92950ccd1435ff693d108869c0f037d 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2687,6 +2687,24 @@ sub process {
} else {
$signatures{$sig_nospace} = 1;
}
+
+# Check Co-developed-by: immediately followed by Signed-off-by: with same name and email
+ if ($sign_off =~ /^co-developed-by:$/i) {
+ if ($email eq $author) {
+ WARN("BAD_SIGN_OFF",
+ "Co-developed-by: should not be used to attribute nominal patch author '$author'\n" . "$here\n" . $rawline);
+ }
+ if (!defined $lines[$linenr]) {
+ WARN("BAD_SIGN_OFF",
+ "Co-developed-by: must be immediately followed by Signed-off-by:\n" . "$here\n" . $rawline);
+ } elsif ($rawlines[$linenr] !~ /^\s*signed-off-by:\s*(.*)/i) {
+ WARN("BAD_SIGN_OFF",
+ "Co-developed-by: must be immediately followed by Signed-off-by:\n" . "$here\n" . $rawline . "\n" .$rawlines[$linenr]);
+ } elsif ($1 ne $email) {
+ WARN("BAD_SIGN_OFF",
+ "Co-developed-by and Signed-off-by: name/email do not match \n" . "$here\n" . $rawline . "\n" .$rawlines[$linenr]);
+ }
+ }
}
# Check email subject for common tools that don't need to be mentioned
diff --git a/scripts/documentation-file-ref-check b/scripts/documentation-file-ref-check
index ad9db6821824392d293716107b843573c85145d6..63e9542656f1d93d8e01a74656ca9ff06efdda1e 100755
--- a/scripts/documentation-file-ref-check
+++ b/scripts/documentation-file-ref-check
@@ -30,6 +30,34 @@ print "Finding broken references. This may take a while... " if ($fix);
my %broken_ref;
+my $doc_fix = 0;
+
+open IN, "git grep ':doc:\`' Documentation/|"
+ or die "Failed to run git grep";
+while (<IN>) {
+ next if (!m,^([^:]+):.*\:doc\:\`([^\`]+)\`,);
+
+ my $d = $1;
+ my $doc_ref = $2;
+
+ my $f = $doc_ref;
+
+ $d =~ s,(.*/).*,$1,;
+ $f =~ s,.*\<([^\>]+)\>,$1,;
+
+ $f ="$d$f.rst";
+
+ next if (grep -e, glob("$f"));
+
+ if ($fix && !$doc_fix) {
+ print STDERR "\nWARNING: Currently, can't fix broken :doc:`` fields\n";
+ }
+ $doc_fix++;
+
+ print STDERR "$f: :doc:`$doc_ref`\n";
+}
+close IN;
+
open IN, "git grep 'Documentation/'|"
or die "Failed to run git grep";
while (<IN>) {
@@ -38,6 +66,9 @@ while (<IN>) {
my $f = $1;
my $ln = $2;
+ # On linux-next, discard the Next/ directory
+ next if ($f =~ m,^Next/,);
+
# Makefiles and scripts contain nasty expressions to parse docs
next if ($f =~ m/Makefile/ || $f =~ m/\.sh$/);
@@ -100,6 +131,7 @@ while (<IN>) {
}
}
}
+close IN;
exit 0 if (!$fix);
diff --git a/scripts/sphinx-pre-install b/scripts/sphinx-pre-install
index 067459760a7b048d4b53c28ac476189ac5884c21..f6a5c0bae31ec5aca92fa3da34aa0408265dad28 100755
--- a/scripts/sphinx-pre-install
+++ b/scripts/sphinx-pre-install
@@ -532,6 +532,7 @@ sub check_needs()
check_program("dot", 1);
check_program("convert", 1);
check_program("rsvg-convert", 1) if ($pdf);
+ check_program("latexmk", 1) if ($pdf);
check_distros();
diff --git a/tools/objtool/Documentation/stack-validation.txt b/tools/objtool/Documentation/stack-validation.txt
index 3995735a878fe796f36513b2bb22b20deaf642d1..8df526c80b6575b97c8bfe72317cc628633c323a 100644
--- a/tools/objtool/Documentation/stack-validation.txt
+++ b/tools/objtool/Documentation/stack-validation.txt
@@ -111,7 +111,7 @@ c) Higher live patching compatibility rate
be detectable). Objtool makes that possible.
For more details, see the livepatch documentation in the Linux kernel
- source tree at Documentation/livepatch/livepatch.txt.
+ source tree at Documentation/livepatch/livepatch.rst.
Rules
-----