Merge branch 'docs-next' of git://git.lwn.net/linux.git

136 files changed, 9918 insertions, 2188 deletions

diff --git a/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp b/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp
index c3fec3c835af..214e9ed4564e 100644
--- a/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp
+++ b/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp
@@ -141,32 +141,44 @@ Description:
 
 		Usage:
 
-		Select over temperature config ID to enable/disable feature
+		Select over temperature config ID to enable/disable feature::
+
 		# echo 1 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
 
-		Check over temperature config ID is selected or not
+		Check over temperature config ID is selected or not::
+
 		# cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
+
 		The expected result is 1.
 
-		Select over temperature config ID to configure OT limit
+		Select over temperature config ID to configure OT limit::
+
 		# echo 2 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
 
-		Check over temperature config ID is selected or not
+		Check over temperature config ID is selected or not::
+
 		# cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
+
 		The expected result is 2.
 
-		Select external watchdog config ID to enable/disable feature
+		Select external watchdog config ID to enable/disable feature::
+
 		# echo 3 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
 
-		Check external watchdog config ID is selected or not
+		Check external watchdog config ID is selected or not::
+
 		# cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
+
 		The expected result is 3.
 
-		Select external watchdog config ID to configure time interval
+		Select external watchdog config ID to configure time interval::
+
 		# echo 4 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
 
-		Check external watchdog config ID is selected or not
+		Check external watchdog config ID is selected or not::
+
 		# cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
+
 		The expected result is 4.
 
 Users:		Xilinx
@@ -205,52 +217,70 @@ Description:
 
 		Usage:
 
-		Enable over temperature feature
+		Enable over temperature feature::
+
 		# echo 1 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
 		# echo 1 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value
 
-		Check whether the over temperature feature is enabled or not
+		Check whether the over temperature feature is enabled or not::
+
 		# cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value
+
 		The expected result is 1.
 
-		Disable over temperature feature
+		Disable over temperature feature::
+
 		# echo 1 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
 		# echo 0 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value
 
-		Check whether the over temperature feature is disabled or not
+		Check whether the over temperature feature is disabled or not::
+
 		# cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value
+
 		The expected result is 0.
 
-		Configure over temperature limit to 50 Degree Celsius
+		Configure over temperature limit to 50 Degree Celsius::
+
 		# echo 2 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
 		# echo 50 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value
 
-		Check whether the over temperature limit is configured or not
+		Check whether the over temperature limit is configured or not::
+
 		# cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value
+
 		The expected result is 50.
 
-		Enable external watchdog feature
+		Enable external watchdog feature::
+
 		# echo 3 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
 		# echo 1 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value
 
-		Check whether the external watchdog feature is enabled or not
+		Check whether the external watchdog feature is enabled or not::
+
 		# cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value
+
 		The expected result is 1.
 
-		Disable external watchdog feature
+		Disable external watchdog feature::
+
 		# echo 3 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
 		# echo 0 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value
 
-		Check whether the external watchdog feature is disabled or not
+		Check whether the external watchdog feature is disabled or not::
+
 		# cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value
+
 		The expected result is 0.
 
-		Configure external watchdog timer interval to 500ms
+		Configure external watchdog timer interval to 500ms::
+
 		# echo 4 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
 		# echo 500 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value
 
-		Check whether the external watchdog timer interval is configured or not
+		Check whether the external watchdog timer interval is configured or not::
+
 		# cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value
+
 		The expected result is 500.
 
 Users:		Xilinx
diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
index c4ff6b538233..be9126e56894 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -492,19 +492,19 @@ Description:
 		These files provide an interface to PCIe Resizable BAR support.
 		A file is created for each BAR resource (N) supported by the
 		PCIe Resizable BAR extended capability of the device.  Reading
-		each file exposes the bitmap of available resource sizes:
+		each file exposes the bitmap of available resource sizes::
 
-		# cat resource1_resize
-		00000000000001c0
+		  # cat resource1_resize
+		  00000000000001c0
 
 		The bitmap represents supported resource sizes for the BAR,
 		where bit0 = 1MB, bit1 = 2MB, bit2 = 4MB, etc.  In the above
 		example the device supports 64MB, 128MB, and 256MB BAR sizes.
 
 		When writing the file, the user provides the bit position of
-		the desired resource size, for example:
+		the desired resource size, for example::
 
-		# echo 7 > resource1_resize
+		  # echo 7 > resource1_resize
 
 		This indicates to set the size value corresponding to bit 7,
 		128MB.  The resulting size is 2 ^ (bit# + 20).  This definition
@@ -606,7 +606,7 @@ Description:
 
 		As all DOE devices must support the DOE discovery feature,
 		if DOE is supported you will at least see the doe_discovery
-		file, with this contents:
+		file, with this contents::
 
 		  # cat doe_features/doe_discovery
 		  0001:00
@@ -614,7 +614,7 @@ Description:
 		If the device supports other features you will see other
 		files as well. For example if CMA/SPDM and secure CMA/SPDM
 		are supported the doe_features directory will look like
-		this:
+		this::
 
 		  # ls doe_features
 		  0001:01        0001:02        doe_discovery
diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb
index baf4bf6d32ee..5213117fd957 100644
--- a/Documentation/ABI/testing/sysfs-bus-usb
+++ b/Documentation/ABI/testing/sysfs-bus-usb
@@ -83,7 +83,8 @@ Description:
 		idVendor idProduct.	After successfully
 		removing an ID, the driver will no longer support the
 		device.  This is useful to ensure auto probing won't
-		match the driver to the device.  For example:
+		match the driver to the device.  For example::
+
 		# echo "046d c315" > /sys/bus/usb/drivers/foo/remove_id
 
 		Reading from this file will list the dynamically added
diff --git a/Documentation/ABI/testing/sysfs-class-firmware-attributes b/Documentation/ABI/testing/sysfs-class-firmware-attributes
index 2713efa509b4..40e35fe97a7d 100644
--- a/Documentation/ABI/testing/sysfs-class-firmware-attributes
+++ b/Documentation/ABI/testing/sysfs-class-firmware-attributes
@@ -397,22 +397,25 @@ Description:
 		unlimited attributes.
 
 		Read the attribute to check what save mode is enabled (single or bulk).
-		E.g:
-		# cat /sys/class/firmware-attributes/thinklmi/attributes/save_settings
-		single
+		E.g::
+
+		  # cat /sys/class/firmware-attributes/thinklmi/attributes/save_settings
+		  single
 
 		Write the attribute with 'bulk' to enable bulk save mode.
-		Write the attribute with 'single' to enable saving, after every attribute set.
+		Write the attribute with 'single' to enable saving after every attribute set.
 		The default setting is single mode.
-		E.g:
-		# echo bulk > /sys/class/firmware-attributes/thinklmi/attributes/save_settings
+		E.g::
+
+		  # echo bulk > /sys/class/firmware-attributes/thinklmi/attributes/save_settings
 
 		When in bulk mode write 'save' to trigger a save of all currently modified attributes.
-		Note, once a save has been triggered, in bulk mode, attributes can no longer be set and
+		Note, once a save has been triggered in bulk mode, attributes can no longer be set and
 		will return a permissions error. This is to prevent users hitting the 48+ save limitation
 		(which requires entering the BIOS to clear the error condition)
-		E.g:
-		# echo save > /sys/class/firmware-attributes/thinklmi/attributes/save_settings
+		E.g::
+
+		  # echo save > /sys/class/firmware-attributes/thinklmi/attributes/save_settings
 
 What:		/sys/class/firmware-attributes/*/attributes/debug_cmd
 Date:		July 2021
diff --git a/Documentation/ABI/testing/sysfs-driver-aspeed-uart-routing b/Documentation/ABI/testing/sysfs-driver-aspeed-uart-routing
index 910df0e5815a..b0b713c85517 100644
--- a/Documentation/ABI/testing/sysfs-driver-aspeed-uart-routing
+++ b/Documentation/ABI/testing/sysfs-driver-aspeed-uart-routing
@@ -8,9 +8,10 @@ Description:	Selects the RX source of the UARTx device.
 		selected option marked by brackets "[]". The list of available options
 		depends on the selected file.
 
-		e.g.
-		cat /sys/bus/platform/drivers/aspeed-uart-routing/\*.uart_routing/uart1
-		[io1] io2 io3 io4 uart2 uart3 uart4 io6
+		E.g.::
+
+		  cat /sys/bus/platform/drivers/aspeed-uart-routing/\*.uart_routing/uart1
+		  [io1] io2 io3 io4 uart2 uart3 uart4 io6
 
 		In this case, UART1 gets its input from IO1 (physical serial port 1).
 
diff --git a/Documentation/ABI/testing/sysfs-driver-xdata b/Documentation/ABI/testing/sysfs-driver-xdata
index f574e8e6dca2..5bcdcba3a5c9 100644
--- a/Documentation/ABI/testing/sysfs-driver-xdata
+++ b/Documentation/ABI/testing/sysfs-driver-xdata
@@ -9,15 +9,19 @@ Description:	Allows the user to enable the PCIe traffic generator which
 
 		Write y/1/on to enable, n/0/off to disable
 
-		Usage e.g.
+		Usage e.g.::
+
 		 echo 1 > /sys/class/misc/dw-xdata-pcie.<device>/write
-		or
+
+		or::
+
 		 echo 0 > /sys/class/misc/dw-xdata-pcie.<device>/write
 
 		The user can read the current PCIe link throughput generated
 		through this generator in MB/s.
 
-		Usage e.g.
+		Usage e.g.::
+
 		 cat /sys/class/misc/dw-xdata-pcie.<device>/write
 		 204
 
@@ -34,15 +38,19 @@ Description:	Allows the user to enable the PCIe traffic generator which
 
 		Write y/1/on to enable, n/0/off to disable
 
-		Usage e.g.
+		Usage e.g.::
+
 		 echo 1 > /sys/class/misc/dw-xdata-pcie.<device>/read
-		or
+
+		or::
+
 		 echo 0 > /sys/class/misc/dw-xdata-pcie.<device>/read
 
 		The user can read the current PCIe link throughput generated
 		through this generator in MB/s.
 
-		Usage e.g.
+		Usage e.g.::
+
 		 cat /sys/class/misc/dw-xdata-pcie.<device>/read
 		 199
 
diff --git a/Documentation/ABI/testing/sysfs-driver-xilinx-tmr-manager b/Documentation/ABI/testing/sysfs-driver-xilinx-tmr-manager
index 57b9b68a73ee..8d07c982d125 100644
--- a/Documentation/ABI/testing/sysfs-driver-xilinx-tmr-manager
+++ b/Documentation/ABI/testing/sysfs-driver-xilinx-tmr-manager
@@ -3,14 +3,16 @@ Date:          Nov 2022
 Contact:       appana.durga.kedareswara.rao@amd.com
 Description:   This control file provides the fault detection count.
                This file cannot be written.
-               Example:
-               # cat /sys/devices/platform/amba_pl/44a10000.tmr_manager/errcnt
-               1
+               Example::
+
+                 # cat /sys/devices/platform/amba_pl/44a10000.tmr_manager/errcnt
+                 1
 
 What:          /sys/devices/platform/amba_pl/<dev>/dis_block_break
 Date:          Nov 2022
 Contact:       appana.durga.kedareswara.rao@amd.com
-Description:   Write any value to it, This control file enables the break signal.
+Description:   Write any value to it. This control file enables the break signal.
                This file is write only.
-               Example:
-               # echo <any value> > /sys/devices/platform/amba_pl/44a10000.tmr_manager/dis_block_break
+               Example::
+
+                 # echo <any value> > /sys/devices/platform/amba_pl/44a10000.tmr_manager/dis_block_break
diff --git a/Documentation/ABI/testing/sysfs-platform-intel-ifs b/Documentation/ABI/testing/sysfs-platform-intel-ifs
index 41b4d5b1e21c..11cd2f412d81 100644
--- a/Documentation/ABI/testing/sysfs-platform-intel-ifs
+++ b/Documentation/ABI/testing/sysfs-platform-intel-ifs
@@ -10,8 +10,10 @@ Description:	Write <cpu#> to trigger IFS test for one online core.
 		Note that the test is per core. The cpu# can be
 		for any thread on the core. Running on one thread
 		completes the test for the core containing that thread.
-		Example: to test the core containing cpu5: echo 5 >
-		/sys/devices/virtual/misc/intel_ifs_<N>/run_test
+		Example: to test the core containing cpu5::
+
+		  echo 5 > /sys/devices/virtual/misc/intel_ifs_<N>/run_test
+
 Devices:	all
 
 What:		/sys/devices/virtual/misc/intel_ifs_<N>/status
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 377a449656c8..ee852afe9bb9 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -74,6 +74,10 @@ htmldocs-redirects: $(srctree)/Documentation/.renames.txt
 refcheckdocs:
 	$(Q)cd $(srctree); tools/docs/documentation-file-ref-check
 
+testdocs:
+	$(Q)PYTHONPYCACHEPREFIX="$(PYTHONPYCACHEPREFIX)" \
+		$(PYTHON3) $(srctree)/tools/unittests/run.py
+
 cleandocs:
 	$(Q)rm -rf $(BUILDDIR)
 
@@ -95,6 +99,7 @@ dochelp:
 	@echo  '                    (will connect to external hosts)'
 	@echo  '  refcheckdocs    - check for references to non-existing files under'
 	@echo  '                    Documentation'
+	@echo  '  testdocs        - run the unit tests of the documentation tools'
 	@echo  '  cleandocs       - clean all generated files'
 	@echo
 	@echo  '  make SPHINXDIRS="s1 s2" [target] Generate only docs of folder s1, s2'
diff --git a/Documentation/admin-guide/LSM/LoadPin.rst b/Documentation/admin-guide/LSM/LoadPin.rst
index dd3ca68b5df1..a90fd9dac960 100644
--- a/Documentation/admin-guide/LSM/LoadPin.rst
+++ b/Documentation/admin-guide/LSM/LoadPin.rst
@@ -23,9 +23,9 @@ sysctl allows for easy testing on systems with a mutable filesystem.)
 It's also possible to exclude specific file types from LoadPin using kernel
 command line option "``loadpin.exclude``". By default, all files are
 included, but they can be excluded using kernel command line option such
-as "``loadpin.exclude=kernel-module,kexec-image``". This allows to use
+as "``loadpin.exclude=kernel-module,kexec-image``". This allows using
 different mechanisms such as ``CONFIG_MODULE_SIG`` and
-``CONFIG_KEXEC_VERIFY_SIG`` to verify kernel module and kernel image while
-still use LoadPin to protect the integrity of other files kernel loads. The
-full list of valid file types can be found in ``kernel_read_file_str``
-defined in ``include/linux/kernel_read_file.h``.
+``CONFIG_KEXEC_SIG`` to verify kernel modules and kernel images while
+still using LoadPin to protect the integrity of other files the kernel
+loads. The full list of valid file types can be found in
+``kernel_read_file_str`` defined in ``include/linux/kernel_read_file.h``.
diff --git a/Documentation/admin-guide/RAS/main.rst b/Documentation/admin-guide/RAS/main.rst
index 5a45db32c49b..c1040e5a5b35 100644
--- a/Documentation/admin-guide/RAS/main.rst
+++ b/Documentation/admin-guide/RAS/main.rst
@@ -623,7 +623,7 @@ Under ``/sys/devices/system/edac/pci`` are control and attribute files as
 follows:
 
 
-- ``check_pci_parity`` - Enable/Disable PCI Parity checking control file
+- ``check_pci_errors`` - Enable/Disable PCI Parity checking control file
 
 	This control file enables or disables the PCI Bus Parity scanning
 	operation. Writing a 1 to this file enables the scanning. Writing
@@ -631,11 +631,11 @@ follows:
 
 	Enable::
 
-		echo "1" >/sys/devices/system/edac/pci/check_pci_parity
+		echo "1" >/sys/devices/system/edac/pci/check_pci_errors
 
 	Disable::
 
-		echo "0" >/sys/devices/system/edac/pci/check_pci_parity
+		echo "0" >/sys/devices/system/edac/pci/check_pci_errors
 
 
 - ``pci_parity_count`` - Parity Count
@@ -725,15 +725,15 @@ Module parameters
 
 	module/kernel parameter::
 
-			edac_panic_on_pci_pe=[0|1]
+			edac_pci_panic_on_pe=[0|1]
 
 	Enable::
 
-		echo "1" > /sys/module/edac_core/parameters/edac_panic_on_pci_pe
+		echo "1" > /sys/module/edac_core/parameters/edac_pci_panic_on_pe
 
 	Disable::
 
-		echo "0" > /sys/module/edac_core/parameters/edac_panic_on_pci_pe
+		echo "0" > /sys/module/edac_core/parameters/edac_pci_panic_on_pe
 
 
 
diff --git a/Documentation/admin-guide/cpu-isolation.rst b/Documentation/admin-guide/cpu-isolation.rst
index 8c65d03fd28c..b9f13a928673 100644
--- a/Documentation/admin-guide/cpu-isolation.rst
+++ b/Documentation/admin-guide/cpu-isolation.rst
@@ -353,5 +353,5 @@ Some tools may also be useful for higher level analysis:
   latency and noise in the system. For example Documentation/tools/rtla/rtla-osnoise.rst
   runs a kernel tracer that analyzes and output a summary of the noises.
 
-- dynticks-testing does something similar to rtla-osnoise but in userspace. It is available
-  at git://git.kernel.org/pub/scm/linux/kernel/git/frederic/dynticks-testing.git
+- cpunoise does something similar to rtla-osnoise but in userspace. It is available
+  at https://git.kernel.org/pub/scm/linux/kernel/git/frederic/cpunoise.git
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 73f53fb0ed15..c31c4285ab96 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -594,8 +594,6 @@ Kernel parameters
 
 	ataflop=	[HW,M68k]
 
-	atarimouse=	[HW,MOUSE] Atari Mouse
-
 	atkbd.extra=	[HW] Enable extra LEDs and keys on IBM RapidAccess,
 			EzKey and similar keyboards
 
@@ -629,13 +627,6 @@ Kernel parameters
 			Format: <int> (must be >=0)
 			Default: 64
 
-	bau=		[X86_UV] Enable the BAU on SGI UV.  The default
-			behavior is to disable the BAU (i.e. bau=0).
-			Format: { "0" | "1" }
-			0 - Disable the BAU.
-			1 - Enable the BAU.
-			unset - Disable the BAU.
-
 	bdev_allow_write_mounted=
 			Format: <bool>
 			Control the ability to open a mounted block device
@@ -1590,14 +1581,6 @@ Kernel parameters
 			PCI device even when its classcode is not of the
 			UART class.
 
-	edac_report=	[HW,EDAC] Control how to report EDAC event
-			Format: {"on" | "off" | "force"}
-			on: enable EDAC to report H/W event. May be overridden
-			by other higher priority error reporting module.
-			off: disable H/W event reporting through EDAC.
-			force: enforce the use of EDAC to report H/W event.
-			default: on.
-
 	edd=		[EDD]
 			Format: {"off" | "on" | "skip[mbr]"}
 
@@ -1667,12 +1650,6 @@ Kernel parameters
 			to discrete, to make X server driver able to add WB
 			entry later. This parameter enables that.
 
-	enable_timer_pin_1 [X86]
-			Enable PIN 1 of APIC timer
-			Can be useful to work around chipset bugs
-			(in particular on some ATI chipsets).
-			The kernel tries to set a reasonable default.
-
 	enforcing=	[SELINUX] Set initial enforcing status.
 			Format: {"0" | "1"}
 			See security/selinux/Kconfig help text.
@@ -4076,27 +4053,6 @@ Kernel parameters
 			Enable or disable the microcode minimal revision
 			enforcement for the runtime microcode loader.
 
-	mini2440=	[ARM,HW,KNL]
-			Format:[0..2][b][c][t]
-			Default: "0tb"
-			MINI2440 configuration specification:
-			0 - The attached screen is the 3.5" TFT
-			1 - The attached screen is the 7" TFT
-			2 - The VGA Shield is attached (1024x768)
-			Leaving out the screen size parameter will not load
-			the TFT driver, and the framebuffer will be left
-			unconfigured.
-			b - Enable backlight. The TFT backlight pin will be
-			linked to the kernel VESA blanking code and a GPIO
-			LED. This parameter is not necessary when using the
-			VGA shield.
-			c - Enable the s3c camera interface.
-			t - Reserved for enabling touchscreen support. The
-			touchscreen support is not enabled in the mainstream
-			kernel as of 2.6.30, a preliminary port can be found
-			in the "bleeding edge" mini2440 support kernel at
-			https://repo.or.cz/w/linux-2.6/mini2440.git
-
 	mitigations=
 			[X86,PPC,S390,ARM64,EARLY] Control optional mitigations for
 			CPU vulnerabilities.  This is a set of curated,
@@ -4598,9 +4554,6 @@ Kernel parameters
 
 	nomce		[X86-32] Disable Machine Check Exception
 
-	nomfgpt		[X86-32] Disable Multi-Function General Purpose
-			Timer usage (for AMD Geode machines).
-
 	nomodeset	Disable kernel modesetting. Most systems' firmware
 			sets up a display mode and provides framebuffer memory
 			for output. With nomodeset, DRM and fbdev drivers will
@@ -4813,11 +4766,6 @@ Kernel parameters
 			waiting for the ACK, so if this is set too high
 			interrupts *may* be lost!
 
-	omap_mux=	[OMAP] Override bootloader pin multiplexing.
-			Format: <mux_mode0.mode_name=value>...
-			For example, to override I2C bus2:
-			omap_mux=i2c2_scl.i2c2_scl=0x100,i2c2_sda.i2c2_sda=0x100
-
 	onenand.bdry=	[HW,MTD] Flex-OneNAND Boundary Configuration
 
 			Format: [die0_boundary][,die0_lock][,die1_boundary][,die1_lock]
@@ -5327,8 +5275,6 @@ Kernel parameters
 		nomsi	Do not use MSI for native PCIe PME signaling (this makes
 			all PCIe root ports use INTx for all services).
 
-	pcmv=		[HW,PCMCIA] BadgePAD 4
-
 	pd_ignore_unused
 			[PM]
 			Keep all power-domains already enabled by bootloader on,
@@ -5454,8 +5400,8 @@ Kernel parameters
 			lazy - Scheduler controlled. Similar to full but instead
 			       of preempting the task immediately, the task gets
 			       one HZ tick time to yield itself before the
-			       preemption will be forced. One preemption is when the
-			       task returns to user space.
+			       preemption will be forced. One such preemption
+			       point is when the task returns to user space.
 
 	print-fatal-signals=
 			[KNL] debug: print fatal signals
diff --git a/Documentation/admin-guide/parport.rst b/Documentation/admin-guide/parport.rst
index ad3f9b8a11e1..4aef45262bd4 100644
--- a/Documentation/admin-guide/parport.rst
+++ b/Documentation/admin-guide/parport.rst
@@ -273,7 +273,7 @@ If that works fine, try with ``io=0x378 irq=7`` (adjust for your
 hardware), to make it use interrupt-driven in-software protocol.
 
 If **that** works fine, then one of the hardware modes isn't working
-right.  Enable ``CONFIG_FIFO`` (no, it isn't a module option,
+right.  Enable ``CONFIG_PARPORT_PC_FIFO`` (no, it isn't a module option,
 and yes, it should be), set the port to ECP mode in the BIOS and note
 the DMA channel, and try with::
 
diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst
index c03369e234a9..608055d7ccc4 100644
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@ -1335,19 +1335,6 @@ seccomp
 See Documentation/userspace-api/seccomp_filter.rst.
 
 
-sg-big-buff
-===========
-
-This file shows the size of the generic SCSI (sg) buffer.
-You can't tune it just yet, but you could change it on
-compile time by editing ``include/scsi/sg.h`` and changing
-the value of ``SG_BIG_BUFF``.
-
-There shouldn't be any reason to change this value. If
-you can come up with one, you probably know what you
-are doing anyway :)
-
-
 shmall
 ======
 
@@ -1610,8 +1597,10 @@ If a value outside of this range is written to ``threads-max`` an
 timer_migration
 ===============
 
-When set to a non-zero value, attempt to migrate timers away from idle cpus to
-allow them to remain in low power states longer.
+When set to a non-zero value, attempt to migrate high-resolution timers from
+nohz isolated (nohz_full) to housekeeping CPUs.
+See Documentation/admin-guide/cpu-isolation.rst
+and Documentation/admin-guide/kernel-parameters.rst.
 
 Default is set (1).
 
diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst
index 5b318d17aa4b..5f4a056e4dc2 100644
--- a/Documentation/admin-guide/sysctl/vm.rst
+++ b/Documentation/admin-guide/sysctl/vm.rst
@@ -438,7 +438,7 @@ zone[i]'s protection[j] is calculated by following expression::
     = (total sums of managed_pages from zone[i+1] to zone[j] on the node)
       / lowmem_reserve_ratio[i];
   (i = j):
-     (should not be protected. = 0;
+     (should not be protected. = 0)
   (i > j):
      (not necessary, but looks 0)
 
diff --git a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst
index 7d38393f31fb..91ebb631a254 100644
--- a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst
+++ b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst
@@ -163,7 +163,7 @@ will be considered the 'good' release and used to prepare the .config file.
      section 'Complementary tasks: cleanup during and after the process'
      below.
 
-  d) Once your finished the bisection, put a few things away::
+  d) Once you have finished the bisection, put a few things away::
 
        cd ~/linux/
        git bisect log > ~/bisect-log
@@ -178,9 +178,9 @@ will be considered the 'good' release and used to prepare the .config file.
        ./scripts/config --set-str CONFIG_LOCALVERSION '-local-cafec0cacaca0-reverted'
 
     This is optional, as some commits are impossible to revert. But if the
-    second command worked flawlessly, build, install, and boot one more kernel
-    kernel; just this time skip the first command copying the base .config file
-    over, as that already has been taken care off.
+    second command worked flawlessly, build, install, and boot one more kernel;
+    just this time skip the first command copying the base .config file over,
+    as that already has been taken care off.
 
 * **Complementary tasks**: cleanup during and after the process.
 
@@ -229,10 +229,10 @@ depends on your issue:
 Execute all steps till the end of *segment 1* to **verify if your kernel problem
 is present in code supported by Linux kernel developers**. If it is, you are all
 set to report the bug -- unless it did not happen with earlier kernel versions,
-as then your want to at least continue with *segment 2* to **check if the issue
+as then you want to at least continue with *segment 2* to **check if the issue
 qualifies as regression** which receive priority treatment. Depending on the
 outcome you then are ready to report a bug or submit a preliminary regression
-report; instead of the latter your could also head straight on and follow
+report; instead of the latter you could also head straight on and follow
 *segment 3* to **perform a bisection** for a full-fledged regression report
 developers are obliged to act upon.
 
@@ -550,7 +550,7 @@ be a waste of time. [:ref:`details <introlatestcheck_bisref>`]
       cd ~/linux/
       git switch --discard-changes --detach stable/linux-6.1.y
 
-    Your series is unsupported, if is not listed or carrying a 'end of life'
+    Your series is unsupported if it is not listed or it is carrying a 'end of life'
     tag. In that case you might want to check if a successor series (say
     linux-6.2.y) or mainline (see next point) fix the bug.
 
@@ -1183,9 +1183,9 @@ Space requirements
 The numbers mentioned are rough estimates with a big extra charge to be on the
 safe side, so often you will need less.
 
-If you have space constraints, be sure to hay attention to the :ref:`step about
-debug symbols' <debugsymbols_bissbs>` and its :ref:`accompanying reference
-section' <debugsymbols_bisref>`, as disabling then will reduce the consumed disk
+If you have space constraints, be sure to pay attention to the :ref:`step about
+debug symbols <debugsymbols_bissbs>` and its :ref:`accompanying reference
+section <debugsymbols_bisref>`, as disabling them will reduce the consumed disk
 space by quite a few gigabytes.
 
 [:ref:`back to step-by-step guide <diskspace_bissbs>`]
@@ -1254,8 +1254,8 @@ distributions:
       kernel-install-tools libelf-devel make modutils openssl openssl-devel \
       perl-base zlib-devel rpm-build ncurses-devel qt6-base-devel
 
-These commands install a few packages that are often, but not always needed. You
-for example might want to skip installing the development headers for ncurses,
+These commands install a few packages that are often, but not always needed. For
+example, you might want to skip installing the development headers for ncurses,
 which you will only need in case you later might want to adjust the kernel build
 configuration using make the targets 'menuconfig' or 'nconfig'; likewise omit
 the headers of Qt6 if you do not plan to adjust the .config using 'xconfig'.
@@ -1407,7 +1407,7 @@ Occasionally odd things happen when trying to use a config file prepared for one
 kernel (say 6.1) on an older mainline release -- especially if it is much older
 (say 5.15). That's one of the reasons why the previous step in the guide told
 you to boot the kernel where everything works. If you manually add a .config
-file you thus want to ensure it's from the working kernel and not from a one
+file you thus want to ensure it's from the working kernel and not from one
 that shows the regression.
 
 In case you want to build kernels for another machine, locate its kernel build
diff --git a/Documentation/arch/powerpc/vas-api.rst b/Documentation/arch/powerpc/vas-api.rst
index 1d0d055356e3..f74ea9fbc8a0 100644
--- a/Documentation/arch/powerpc/vas-api.rst
+++ b/Documentation/arch/powerpc/vas-api.rst
@@ -136,7 +136,7 @@ a connection with NX co-processor engine:
 	follows::
 
 		#define VAS_MAGIC 'v'
-		#define VAS_TX_WIN_OPEN _IOW(VAS_MAGIC, 1,
+		#define VAS_TX_WIN_OPEN _IOW(VAS_MAGIC, 0x20,
 						struct vas_tx_win_open_attr)
 
 		struct vas_tx_win_open_attr attr;
@@ -265,7 +265,7 @@ Simple example
 		{
 			int rc, fd;
 			void *addr;
-			struct vas_setup_attr txattr;
+			struct vas_tx_win_open_attr txattr;
 
 			fd = open("/dev/crypto/nx-gzip", O_RDWR);
 			if (fd < 0) {
diff --git a/Documentation/core-api/cpu_hotplug.rst b/Documentation/core-api/cpu_hotplug.rst
index 6de26d1c6a9a..f8b3f59a3d5f 100644
--- a/Documentation/core-api/cpu_hotplug.rst
+++ b/Documentation/core-api/cpu_hotplug.rst
@@ -607,9 +607,9 @@ ONLINE section for notifications on online and offline operation::
    if (ret)
         return ret;
    ....
-   cpuhp_remove_instance(state, &inst1->node);
+   cpuhp_state_remove_instance(state, &inst1->node);
    ....
-   cpuhp_remove_instance(state, &inst2->node);
+   cpuhp_state_remove_instance(state, &inst2->node);
    ....
    cpuhp_remove_multi_state(state);
 
diff --git a/Documentation/core-api/debug-objects.rst b/Documentation/core-api/debug-objects.rst
index ac926fd55a64..708775fc581b 100644
--- a/Documentation/core-api/debug-objects.rst
+++ b/Documentation/core-api/debug-objects.rst
@@ -129,7 +129,7 @@ When the real object is not yet tracked by debugobjects then the
 fixup_activate function is called if available. This is necessary to
 allow the legitimate activation of statically allocated and initialized
 objects. The fixup function checks whether the object is valid and calls
-the debug_objects_init() function to initialize the tracking of this
+the debug_object_init() function to initialize the tracking of this
 object.
 
 When the activation is legitimate, then the state of the associated
diff --git a/Documentation/core-api/dma-attributes.rst b/Documentation/core-api/dma-attributes.rst
index eee743184acd..b07126b5b616 100644
--- a/Documentation/core-api/dma-attributes.rst
+++ b/Documentation/core-api/dma-attributes.rst
@@ -34,7 +34,7 @@ such mapping is non-trivial task and consumes very limited resources
 (like kernel virtual address space or dma consistent address space).
 Buffers allocated with this attribute can be only passed to user space
 by calling dma_mmap_attrs(). By using this API, you are guaranteeing
-that you won't dereference the pointer returned by dma_alloc_attr(). You
+that you won't dereference the pointer returned by dma_alloc_attrs(). You
 can treat it as a cookie that must be passed to dma_mmap_attrs() and
 dma_free_attrs(). Make sure that both of these also get this attribute
 set on each call.
diff --git a/Documentation/core-api/dma-isa-lpc.rst b/Documentation/core-api/dma-isa-lpc.rst
index 17b193603f0a..296838ff295a 100644
--- a/Documentation/core-api/dma-isa-lpc.rst
+++ b/Documentation/core-api/dma-isa-lpc.rst
@@ -115,17 +115,18 @@ sure that all data has been transferred.
 
 Example::
 
-	int flags, residue;
+	unsigned long flags;
+	int residue;
 
 	flags = claim_dma_lock();
 
-	clear_dma_ff();
+	clear_dma_ff(channel);
 
 	set_dma_mode(channel, DMA_MODE_WRITE);
 	set_dma_addr(channel, phys_addr);
 	set_dma_count(channel, num_bytes);
 
-	dma_enable(channel);
+	enable_dma(channel);
 
 	release_dma_lock(flags);
 
@@ -133,9 +134,9 @@ Example::
 
 	flags = claim_dma_lock();
 
-	dma_disable(channel);
+	disable_dma(channel);
 
-	residue = dma_get_residue(channel);
+	residue = get_dma_residue(channel);
 	if (residue != 0)
 		printk(KERN_ERR "driver: Incomplete DMA transfer!"
 			" %d bytes left!\n", residue);
diff --git a/Documentation/core-api/housekeeping.rst b/Documentation/core-api/housekeeping.rst
index ccb0a88b9cb3..71ba5d86f249 100644
--- a/Documentation/core-api/housekeeping.rst
+++ b/Documentation/core-api/housekeeping.rst
@@ -9,7 +9,7 @@ extreme workloads can't stand, such as in some DPDK usecases.
 
 The kernel work moved away by CPU isolation is commonly described as
 "housekeeping" because it includes ground work that performs cleanups,
-statistics maintainance and actions relying on them, memory release,
+statistics maintenance and actions relying on them, memory release,
 various deferrals etc...
 
 Sometimes housekeeping is just some unbound work (unbound workqueues,
diff --git a/Documentation/core-api/irq/irq-affinity.rst b/Documentation/core-api/irq/irq-affinity.rst
index 9cb460cf60b6..671604c7395f 100644
--- a/Documentation/core-api/irq/irq-affinity.rst
+++ b/Documentation/core-api/irq/irq-affinity.rst
@@ -53,7 +53,7 @@ Now lets restrict that IRQ to CPU(4-7).
 	--- hell ping statistics ---
 	2779 packets transmitted, 2777 packets received, 0% packet loss
 	round-trip min/avg/max = 0.1/0.5/585.4 ms
-	[root@moon 44]# cat /proc/interrupts |  'CPU\|44:'
+	[root@moon 44]# cat /proc/interrupts | grep 'CPU\|44:'
 		CPU0       CPU1       CPU2       CPU3      CPU4       CPU5        CPU6       CPU7
 	44:       1068       1785       1785       1783      1784       1069        1070       1069   IO-APIC-level  eth1
 
diff --git a/Documentation/core-api/irq/irqflags-tracing.rst b/Documentation/core-api/irq/irqflags-tracing.rst
index bdd208259fb3..a3c77046ae6b 100644
--- a/Documentation/core-api/irq/irqflags-tracing.rst
+++ b/Documentation/core-api/irq/irqflags-tracing.rst
@@ -9,12 +9,8 @@ that it gives interested subsystems an opportunity to be notified of
 every hardirqs-off/hardirqs-on, softirqs-off/softirqs-on event that
 happens in the kernel.
 
-CONFIG_TRACE_IRQFLAGS_SUPPORT is needed for CONFIG_PROVE_SPIN_LOCKING
-and CONFIG_PROVE_RW_LOCKING to be offered by the generic lock debugging
-code. Otherwise only CONFIG_PROVE_MUTEX_LOCKING and
-CONFIG_PROVE_RWSEM_LOCKING will be offered on an architecture - these
-are locking APIs that are not used in IRQ context. (the one exception
-for rwsems is worked around)
+CONFIG_TRACE_IRQFLAGS_SUPPORT is needed for CONFIG_PROVE_LOCKING to be
+offered by the generic lock debugging code.
 
 Architecture support for this is certainly not in the "trivial"
 category, because lots of lowlevel assembly code deal with irq-flags
diff --git a/Documentation/core-api/maple_tree.rst b/Documentation/core-api/maple_tree.rst
index 12bccfb6aac1..836342fb1eec 100644
--- a/Documentation/core-api/maple_tree.rst
+++ b/Documentation/core-api/maple_tree.rst
@@ -214,11 +214,10 @@ Advanced Allocating Nodes
 -------------------------
 
 Allocations are usually handled internally to the tree, however if allocations
-need to occur before a write occurs then calling mas_expected_entries() will
-allocate the worst-case number of needed nodes to insert the provided number of
-ranges.  This also causes the tree to enter mass insertion mode.  Once
-insertions are complete calling mas_destroy() on the maple state will free the
-unused allocations.
+need to occur before a write occurs then calling mas_preallocate() will
+allocate the nodes needed to store the provided entry.  The entry is then
+stored with mas_store_prealloc().  If the store is abandoned, calling
+mas_destroy() on the maple state will free the unused allocations.
 
 .. _maple-tree-advanced-locks:
 
diff --git a/Documentation/core-api/real-time/differences.rst b/Documentation/core-api/real-time/differences.rst
index a129570dab5a..6f5be9f0da2e 100644
--- a/Documentation/core-api/real-time/differences.rst
+++ b/Documentation/core-api/real-time/differences.rst
@@ -119,12 +119,20 @@ timers initialized with the HRTIMER_MODE_SOFT flag, which are executed in
 softirq context.
 
 On a PREEMPT_RT kernel, this behavior is reversed: hrtimers are executed in
-softirq context by default, typically within the ktimersd thread. This thread
+softirq context by default, typically within the ktimers thread. This thread
 runs at the lowest real-time priority, ensuring it executes before any
 SCHED_OTHER tasks but does not interfere with higher-priority real-time
 threads. To explicitly request execution in hard interrupt context on
 PREEMPT_RT, the timer must be marked with the HRTIMER_MODE_HARD flag.
 
+Userland sleepers usually deploy a hrtimer to guarantee a precise wakeup
+time. The timer is initialized with hrtimer_setup_sleeper_on_stack(), which
+distinguishes between real-time and regular tasks. The hrtimer of a task
+without a real-time priority is handled in soft interrupt context, but for
+real-time priorities HRTIMER_MODE_HARD is used. This ensures that real-time
+tasks are woken up as soon as possible while ordinary tasks cannot block the
+CPU with a thundering herd of wakeups.
+
 Memory allocation
 -----------------
 
diff --git a/Documentation/core-api/swiotlb.rst b/Documentation/core-api/swiotlb.rst
index 71b4e4c27eb5..211cc3499315 100644
--- a/Documentation/core-api/swiotlb.rst
+++ b/Documentation/core-api/swiotlb.rst
@@ -107,7 +107,7 @@ A single allocation from swiotlb is limited to IO_TLB_SIZE * IO_TLB_SEGSIZE
 bytes, which is 256 KiB with current definitions. When a device's DMA settings
 are such that the device might use swiotlb, the maximum size of a DMA segment
 must be limited to that 256 KiB. This value is communicated to higher-level
-kernel code via dma_map_mapping_size() and swiotlb_max_mapping_size(). If the
+kernel code via dma_max_mapping_size() and swiotlb_max_mapping_size(). If the
 higher-level code fails to account for this limit, it may make requests that
 are too large for swiotlb, and get a "swiotlb full" error.
 
diff --git a/Documentation/core-api/this_cpu_ops.rst b/Documentation/core-api/this_cpu_ops.rst
index 533ac5dd5750..367706d1714b 100644
--- a/Documentation/core-api/this_cpu_ops.rst
+++ b/Documentation/core-api/this_cpu_ops.rst
@@ -150,10 +150,10 @@ preemptible code are addressed by raw_cpu_ptr(), but such use cases need
 to handle cases where two different CPUs are accessing the same per cpu
 variable, which might well be that of a third CPU.  These use cases are
 typically performance optimizations.  For example, SRCU implements a pair
-of counters as a pair of per-CPU variables, and rcu_read_lock_nmisafe()
+of counters as a pair of per-CPU variables, and srcu_read_lock_nmisafe()
 uses raw_cpu_ptr() to get a pointer to some CPU's counter, and uses
-atomic_inc_long() to handle migration between the raw_cpu_ptr() and
-the atomic_inc_long().
+atomic_long_inc() to handle migration between the raw_cpu_ptr() and
+the atomic_long_inc().
 
 Per cpu variables and offsets
 -----------------------------
diff --git a/Documentation/core-api/xarray.rst b/Documentation/core-api/xarray.rst
index c6c91cbd0c3c..82876fbb3bf2 100644
--- a/Documentation/core-api/xarray.rst
+++ b/Documentation/core-api/xarray.rst
@@ -127,6 +127,8 @@ by using xa_set_mark() and remove the mark from an entry by calling
 xa_clear_mark().  You can ask whether any entry in the XArray has a
 particular mark set by calling xa_marked().  Erasing an entry from the
 XArray causes all marks associated with that entry to be cleared.
+Storing a new entry that replaces an existing entry keeps the marks
+associated with the index intact.
 
 Setting or clearing a mark on any index of a multi-index entry will
 affect all indices covered by that entry.  Querying the mark on any
@@ -490,7 +492,7 @@ entry at every index to ``NULL`` and dissolve the tie.  A multi-index
 entry can be split into entries occupying smaller ranges by calling
 xas_split_alloc() without the xa_lock held, followed by taking the lock
 and calling xas_split() or calling xas_try_split() with xa_lock. The
-difference between xas_split_alloc()+xas_split() and xas_try_alloc() is
+difference between xas_split_alloc()+xas_split() and xas_try_split() is
 that xas_split_alloc() + xas_split() split the entry from the original
 order to the new order in one shot uniformly, whereas xas_try_split()
 iteratively splits the entry containing the index non-uniformly.
diff --git a/Documentation/doc-guide/kernel-doc.rst b/Documentation/doc-guide/kernel-doc.rst
index 1c148fe8e1f9..48f62e59c455 100644
--- a/Documentation/doc-guide/kernel-doc.rst
+++ b/Documentation/doc-guide/kernel-doc.rst
@@ -422,7 +422,8 @@ Domain`_ references.
   Function reference.
 
 ``@parameter``
-  Name of a function parameter. (No cross-referencing, just formatting.)
+  Name of a function parameter, struct member, union member, or
+  enum value. (No cross-referencing, just formatting.)
 
 ``%CONST``
   Name of a constant. (No cross-referencing, just formatting.)
@@ -563,8 +564,8 @@ identifiers: *[ function/type ...]*
   Include documentation for each *function* and *type* in *source*.
   If no *function* is specified, the documentation for all functions
   and types in the *source* will be included.
-  *type* can be a ``struct``, ``union``, ``enum``, ``typedef`` or ``var``
-  identifier.
+  *type* can be a ``struct``, ``union``, ``enum``, ``typedef``, ``var``,
+  or ``define`` identifier.
 
   Examples::
 
diff --git a/Documentation/doc-guide/parse-headers.rst b/Documentation/doc-guide/parse-headers.rst
index a7bb01ff04eb..eb36c92e9a06 100644
--- a/Documentation/doc-guide/parse-headers.rst
+++ b/Documentation/doc-guide/parse-headers.rst
@@ -8,26 +8,27 @@ between the code and the documentation. Adding cross-references for
 userspace API files has an additional advantage: Sphinx will generate warnings
 if a symbol is not found at the documentation. That helps to keep the
 uAPI documentation in sync with the Kernel changes.
-The :ref:`parse_headers.py <parse_headers>` provides a way to generate such
-cross-references. It has to be called via Makefile, while building the
-documentation. Please see ``Documentation/userspace-api/media/Makefile`` for an example
-about how to use it inside the Kernel tree.
+The :ref:`parse-headers.py <parse_headers>` provides a way to generate such
+cross-references. During the documentation build, the same parser is used by
+the ``kernel-include`` directive with the ``:generate-cross-refs:`` option.
+Please see ``Documentation/userspace-api/media/cec/cec-header.rst`` for an
+example about how to use it inside the Kernel tree.
 
 .. _parse_headers:
 
-tools/docs/parse_headers.py
+tools/docs/parse-headers.py
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 NAME
 ****
 
-parse_headers.py - parse a C file, in order to identify functions, structs,
+parse-headers.py - parse a C file, in order to identify functions, structs,
 enums and defines and create cross-references to a Sphinx book.
 
 USAGE
 *****
 
-parse-headers.py [-h] [-d] [-t] ``FILE_IN`` ``FILE_OUT`` ``FILE_RULES``
+parse-headers.py [-h] [-d] [-t] ``FILE_IN`` ``FILE_OUT`` [``FILE_RULES``]
 
 SYNOPSIS
 ********
diff --git a/Documentation/driver-api/reset.rst b/Documentation/driver-api/reset.rst
index 7a6571849664..932699c57d1e 100644
--- a/Documentation/driver-api/reset.rst
+++ b/Documentation/driver-api/reset.rst
@@ -213,7 +213,7 @@ devm_reset_controller_register().
    :internal:
 
 .. kernel-doc:: drivers/reset/core.c
-   :functions: of_reset_simple_xlate
+   :functions: fwnode_reset_simple_xlate
                reset_controller_register
                reset_controller_unregister
                devm_reset_controller_register
diff --git a/Documentation/driver-api/serial/serial-rs485.rst b/Documentation/driver-api/serial/serial-rs485.rst
index f53043d21071..98d8d83718c6 100644
--- a/Documentation/driver-api/serial/serial-rs485.rst
+++ b/Documentation/driver-api/serial/serial-rs485.rst
@@ -50,7 +50,10 @@ RS485 Serial Communications
    matching to the current configuration.
 
 .. kernel-doc:: include/uapi/linux/serial.h
-   :identifiers: serial_rs485 uart_get_rs485_mode
+   :identifiers: serial_rs485
+
+.. kernel-doc:: drivers/tty/serial/serial_core.c
+   :identifiers: uart_get_rs485_mode
 
 4. Usage from user-level
 ========================
diff --git a/Documentation/features/locking/cmpxchg-local/arch-support.txt b/Documentation/features/locking/cmpxchg-local/arch-support.txt
index 2c3a4b91f16d..127e8159adaa 100644
--- a/Documentation/features/locking/cmpxchg-local/arch-support.txt
+++ b/Documentation/features/locking/cmpxchg-local/arch-support.txt
@@ -12,7 +12,7 @@
     |       arm64: |  ok  |
     |        csky: | TODO |
     |     hexagon: | TODO |
-    |   loongarch: | TODO |
+    |   loongarch: |  ok  |
     |        m68k: | TODO |
     |  microblaze: | TODO |
     |        mips: | TODO |
diff --git a/Documentation/filesystems/fuse/fuse.rst b/Documentation/filesystems/fuse/fuse.rst
index 0fbd5a03fdc9..063d99959396 100644
--- a/Documentation/filesystems/fuse/fuse.rst
+++ b/Documentation/filesystems/fuse/fuse.rst
@@ -173,10 +173,10 @@ the error set to EINTR.
 It is also possible that there's a race between processing the
 original request and its INTERRUPT request.  There are two possibilities:
 
-  1. The INTERRUPT request is processed before the original request is
+  1) The INTERRUPT request is processed before the original request is
      processed
 
-  2. The INTERRUPT request is processed after the original request has
+  2) The INTERRUPT request is processed after the original request has
      been answered
 
 If the filesystem cannot find the original request, it should wait for
@@ -239,9 +239,9 @@ How are requirements fulfilled?
 
  A) The mount owner could gain elevated privileges by either:
 
-    1. creating a filesystem containing a device file, then opening this device
+    1) creating a filesystem containing a device file, then opening this device
 
-    2. creating a filesystem containing a suid or sgid application, then executing this application
+    2) creating a filesystem containing a suid or sgid application, then executing this application
 
     The solution is not to allow opening device files and ignore
     setuid and setgid bits when executing programs.  To ensure this
diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst
index 6330653287d5..f7363ad770c7 100644
--- a/Documentation/filesystems/locking.rst
+++ b/Documentation/filesystems/locking.rst
@@ -27,7 +27,7 @@ prototypes::
 	int (*d_init)(struct dentry *);
 	void (*d_release)(struct dentry *);
 	void (*d_iput)(struct dentry *, struct inode *);
-	char *(*d_dname)((struct dentry *dentry, char *buffer, int buflen);
+	char *(*d_dname)(struct dentry *dentry, char *buffer, int buflen);
 	struct vfsmount *(*d_automount)(struct path *path);
 	int (*d_manage)(const struct path *, bool);
 	struct dentry *(*d_real)(struct dentry *, enum d_real_type type);
diff --git a/Documentation/filesystems/porting.rst b/Documentation/filesystems/porting.rst
index e666edab789f..c38f5df755bb 100644
--- a/Documentation/filesystems/porting.rst
+++ b/Documentation/filesystems/porting.rst
@@ -673,7 +673,7 @@ watch out, since that shortcut is no longer valid.
 they used to - they just take it exclusive.  However, ->lookup() may be
 called with parent locked shared.  Its instances must not
 
-	* use d_instantiate) and d_rehash() separately - use d_add() or
+	* use d_instantiate() and d_rehash() separately - use d_add() or
 	  d_splice_alias() instead.
 	* use d_rehash() alone - call d_add(new_dentry, NULL) instead.
 	* in the unlikely case when (read-only) access to filesystem
diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
index fc59c98acca1..fa7a468e8edf 100644
--- a/Documentation/filesystems/proc.rst
+++ b/Documentation/filesystems/proc.rst
@@ -440,7 +440,7 @@ ioctl()-based API that gives ability to flexibly and efficiently query and
 filter individual VMAs. This interface is binary and is meant for more
 efficient and easy programmatic use. `struct procmap_query`, defined in
 linux/fs.h UAPI header, serves as an input/output argument to the
-`PROCMAP_QUERY` ioctl() command. See comments in linus/fs.h UAPI header for
+`PROCMAP_QUERY` ioctl() command. See comments in linux/fs.h UAPI header for
 details on query semantics, supported flags, data returned, and general API
 usage information.
 
@@ -576,14 +576,14 @@ encoded manner. The codes are the following:
 
     ==    =============================================================
     rd    readable
-    wr    writeable
+    wr    writable
     ex    executable
     sh    shared
     mr    may read
     mw    may write
     me    may execute
     ms    may share
-    gd    stack segment growns down
+    gd    stack segment grows down
     pf    pure PFN range
     lo    pages are locked in memory
     io    memory mapped I/O area
@@ -719,7 +719,7 @@ size, in KB, that is backing the mapping up.
 
 Note that some kernel configurations do not track the precise number of times
 a page part of a larger allocation (e.g., THP) is mapped. In these
-configurations, "mapmax" might corresponds to the average number of mappings
+configurations, "mapmax" might correspond to the average number of mappings
 per page in such a larger allocation instead.
 
 1.2 Kernel data
@@ -2012,7 +2012,7 @@ For more information on mount propagation see:
 These files provide a method to access a task's comm value. It also allows for
 a task to set its own or one of its thread siblings comm value. The comm value
 is limited in size compared to the cmdline value, so writing anything longer
-then the kernel's TASK_COMM_LEN (currently 16 chars, including the NUL
+than the kernel's TASK_COMM_LEN (currently 16 chars, including the NUL
 terminator) will result in a truncated comm value.
 
 
diff --git a/Documentation/input/devices/yealink.rst b/Documentation/input/devices/yealink.rst
index bb5a1aafeca2..53191a3c83ca 100644
--- a/Documentation/input/devices/yealink.rst
+++ b/Documentation/input/devices/yealink.rst
@@ -120,9 +120,10 @@ Reading /sys/../lineX will return the format string with its current value.
 Writing to /sys/../lineX will set the corresponding LCD line.
 
  - Excess characters are ignored.
- - If less characters are written than allowed, the remaining digits are
+ - If fewer characters than allowed are written, the remaining digits are
    unchanged.
- - The tab '\t'and '\n' char does not overwrite the original content.
+ - The tab ``\t`` and newline ``\n`` characters do not overwrite the original
+   content.
  - Writing a space to an icon will always hide its content.
 
   Example::
@@ -205,7 +206,7 @@ Troubleshooting
 :Q: Module yealink compiled and installed without any problem but phone
     is not initialized and does not react to any actions.
 :A: If you see something like:
-    hiddev0: USB HID v1.00 Device [Yealink Network Technology Ltd. VOIP USB Phone
+    hiddev0: USB HID v1.00 Device [Yealink Network Technology Ltd. VOIP USB Phone]
     in dmesg, it means that the hid driver has grabbed the device first. Try to
     load module yealink before any other usb hid driver. Please see the
     instructions provided by your distribution on module configuration.
diff --git a/Documentation/input/notifier.rst b/Documentation/input/notifier.rst
index 824379399e61..e7facd1a1003 100644
--- a/Documentation/input/notifier.rst
+++ b/Documentation/input/notifier.rst
@@ -31,7 +31,7 @@ In a rough C snippet, we have::
     kbd_keycode(keycode) {
 	...
 	params.value = keycode;
-	if (notifier_call_chain(KBD_KEYCODE,&params) == NOTIFY_STOP)
+	if ((notifier_call_chain(KBD_KEYCODE,&params) == NOTIFY_STOP)
 	    || !bound) {
 		notifier_call_chain(KBD_UNBOUND_KEYCODE,&params);
 		return;
diff --git a/Documentation/livepatch/api.rst b/Documentation/livepatch/api.rst
index 78944b63d74b..2a98c517da9d 100644
--- a/Documentation/livepatch/api.rst
+++ b/Documentation/livepatch/api.rst
@@ -27,4 +27,7 @@ Object Types
 ============
 
 .. kernel-doc:: include/linux/livepatch.h
-   :identifiers: klp_patch klp_object klp_func klp_callbacks klp_state
+   :identifiers: klp_patch klp_object klp_func klp_state
+
+.. kernel-doc:: include/linux/livepatch_external.h
+   :identifiers: klp_callbacks
diff --git a/Documentation/misc-devices/spear-pcie-gadget.rst b/Documentation/misc-devices/spear-pcie-gadget.rst
index 09b9d6c7ac15..13333a20944c 100644
--- a/Documentation/misc-devices/spear-pcie-gadget.rst
+++ b/Documentation/misc-devices/spear-pcie-gadget.rst
@@ -37,9 +37,9 @@ read behavior of nodes:
 -----------------------
 
 =============== ==============================================================
-link 		gives ltssm status.
-int_type 	type of supported interrupt
-no_of_msi 	zero if MSI is not enabled by host. A positive value is the
+link		gives ltssm status.
+int_type	type of supported interrupt
+no_of_msi	zero if MSI is not enabled by host. A positive value is the
 		number of MSI vector granted.
 vendor_id	returns programmed vendor id (hex)
 device_id	returns programmed device id(hex)
@@ -53,7 +53,7 @@ write behavior of nodes:
 ------------------------
 
 =============== ================================================================
-link 		write UP to enable ltsmm DOWN to disable
+link		write UP to enable ltsmm DOWN to disable
 int_type	write interrupt type to be configured and (int_type could be
 		INTA, MSI or NO_INT). Select MSI only when you have programmed
 		no_of_msi node.
@@ -65,7 +65,7 @@ device_id	write device id(hex) to be programmed.
 bar0_size	write size of bar0 in hex. default bar0 size is 1000 (hex)
 		bytes.
 bar0_address	write	address of bar0 mapped area in hex. (default mapping of
-		bar0 is SYSRAM1(E0800000). Always program bar size before bar
+		bar0 is SYSRAM1(E0800000)). Always program bar size before bar
 		address. Kernel might modify bar size and address for alignment,
 		so read back bar size and address after writing to cross check.
 bar0_rw_offset	write offset of bar0 for which	bar0_data will write value.
diff --git a/Documentation/process/1.Intro.rst b/Documentation/process/1.Intro.rst
index 2c93caea069f..847fbe76b6a4 100644
--- a/Documentation/process/1.Intro.rst
+++ b/Documentation/process/1.Intro.rst
@@ -42,7 +42,7 @@ avoid problems at this important stage.  Developers are cautioned against
 assuming that the job is done when a patch is merged into the mainline.
 
 :ref:`development_advancedtopics` introduces a couple of "advanced" topics:
-managing patches with git and reviewing patches posted by others.
+managing patches with Git and reviewing patches posted by others.
 
 :ref:`development_conclusion` concludes the document with pointers to sources
 for more information on kernel development.
diff --git a/Documentation/process/2.Process.rst b/Documentation/process/2.Process.rst
index 77f3f80e7cd7..a8e09ca4e7c7 100644
--- a/Documentation/process/2.Process.rst
+++ b/Documentation/process/2.Process.rst
@@ -223,11 +223,11 @@ of the kernel they manage; they are the ones who will (usually) accept a
 patch for inclusion into the mainline kernel.
 
 Subsystem maintainers each manage their own version of the kernel source
-tree, usually (but certainly not always) using the git source management
-tool.  Tools like git (and related tools like quilt or mercurial) allow
+tree, usually (but certainly not always) using the Git source management
+tool.  Tools like Git (and related tools like Quilt or Mercurial) allow
 maintainers to track a list of patches, including authorship information
 and other metadata.  At any given time, the maintainer can identify which
-patches in his or her repository are not found in the mainline.
+patches in their repository are not found in the mainline.
 
 When the merge window opens, top-level maintainers will ask Linus to "pull"
 the patches they have selected for merging from their repositories.  If
@@ -343,13 +343,13 @@ are well beyond the scope of this document, but there is space for a few
 pointers.
 
 By far the dominant source code management system used by the kernel
-community is git.  Git is one of a number of distributed version control
+community is Git.  Git is one of a number of distributed version control
 systems being developed in the free software community.  It is well tuned
 for kernel development, in that it performs quite well when dealing with
 large repositories and large numbers of patches.  It also has a reputation
 for being difficult to learn and use, though it has gotten better over
-time.  Some sort of familiarity with git is almost a requirement for kernel
-developers; even if they do not use it for their own work, they'll need git
+time.  Some sort of familiarity with Git is almost a requirement for kernel
+developers; even if they do not use it for their own work, they'll need Git
 to keep up with what other developers (and the mainline) are doing.
 
 Git is now packaged by almost all Linux distributions.  There is a home
@@ -359,12 +359,12 @@ page at:
 
 That page has pointers to documentation and tutorials.
 
-Among the kernel developers who do not use git, the most popular choice is
+Among the kernel developers who do not use Git, the most popular choice is
 almost certainly Mercurial:
 
 	https://www.selenic.com/mercurial/
 
-Mercurial shares many features with git, but it provides an interface which
+Mercurial shares many features with Git, but it provides an interface which
 many find easier to use.
 
 The other tool worth knowing about is Quilt:
@@ -374,9 +374,9 @@ The other tool worth knowing about is Quilt:
 Quilt is a patch management system, rather than a source code management
 system.  It does not track history over time; it is, instead, oriented
 toward tracking a specific set of changes against an evolving code base.
-Some major subsystem maintainers use quilt to manage patches intended to go
+Some major subsystem maintainers use Quilt to manage patches intended to go
 upstream.  For the management of certain kinds of trees (-mm, for example),
-quilt is the best tool for the job.
+Quilt is the best tool for the job.
 
 
 Mailing lists
diff --git a/Documentation/process/3.Early-stage.rst b/Documentation/process/3.Early-stage.rst
index 894a920041c6..87fa7875e336 100644
--- a/Documentation/process/3.Early-stage.rst
+++ b/Documentation/process/3.Early-stage.rst
@@ -138,7 +138,7 @@ the place to start.  That file tends to not always be up to date, though,
 and not all subsystems are represented there.  The person listed in the
 MAINTAINERS file may, in fact, not be the person who is actually acting in
 that role currently.  So, when there is doubt about who to contact, a
-useful trick is to use git (and "git log" in particular) to see who is
+useful trick is to use Git (and "git log" in particular) to see who is
 currently active within the subsystem of interest.  Look at who is writing
 patches, and who, if anybody, is attaching Signed-off-by lines to those
 patches.  Those are the people who will be best placed to help with a new
diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst
index 07d7dbed13ec..976cf45a565a 100644
--- a/Documentation/process/5.Posting.rst
+++ b/Documentation/process/5.Posting.rst
@@ -21,7 +21,7 @@ There is a constant temptation to avoid posting patches before they are
 completely "ready."  For simple patches, that is not a problem.  If the
 work being done is complex, though, there is a lot to be gained by getting
 feedback from the community before the work is complete.  So you should
-consider posting in-progress work, or even making a git tree available so
+consider posting in-progress work, or even making a Git tree available so
 that interested developers can catch up with your work at any time.
 
 When posting code which is not yet considered ready for inclusion, it is a
@@ -71,7 +71,7 @@ even in the short term.
 
 Patches must be prepared against a specific version of the kernel.  As a
 general rule, a patch should be based on the current mainline as found in
-Linus's git tree.  When basing on mainline, start with a well-known release
+Linus's Git tree.  When basing on mainline, start with a well-known release
 point - a stable or -rc release - rather than branching off the mainline at
 an arbitrary spot.
 
@@ -233,7 +233,7 @@ the patch. Each of these uses this format::
 
 The tags in common use are:
 
- - Signed-off-by: this is a developer's certification that he or she has
+ - Signed-off-by: this is a developer's certification that they have
    the right to submit the patch for inclusion into the kernel.  It is an
    agreement to the Developer's Certificate of Origin, the full text of
    which can be found in :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
@@ -320,7 +320,7 @@ copies should go to:
    the MAINTAINERS file is the first place to look for these people.
 
  - Other developers who have been working in the same area - especially
-   those who might be working there now.  Using git to see who else has
+   those who might be working there now.  Using Git to see who else has
    modified the files you are working on can be helpful.
 
  - If you are responding to a bug report or a feature request, copy the
@@ -362,7 +362,7 @@ that the patches, themselves, have complete changelog information.
 
 In general, the second and following parts of a multi-part patch should be
 sent as a reply to the first part so that they all thread together at the
-receiving end.  Tools like git and quilt have commands to mail out a set of
+receiving end.  Tools like Git and Quilt have commands to mail out a set of
 patches with the proper threading.  If you have a long series, though, and
-are using git, please stay away from the --chain-reply-to option to avoid
+are using Git, please stay away from the --chain-reply-to option to avoid
 creating exceptionally deep nesting.
diff --git a/Documentation/process/6.Followthrough.rst b/Documentation/process/6.Followthrough.rst
index 66fa400c6d94..ebb0e4cc9584 100644
--- a/Documentation/process/6.Followthrough.rst
+++ b/Documentation/process/6.Followthrough.rst
@@ -114,7 +114,7 @@ What happens next
 If a patch is considered to be a good thing to add to the kernel, and once
 most of the review issues have been resolved, the next step is usually
 entry into a subsystem maintainer's tree.  How that works varies from one
-subsystem to the next; each maintainer has his or her own way of doing
+subsystem to the next; each maintainer has their own way of doing
 things.  In particular, there may be more than one tree - one, perhaps,
 dedicated to patches planned for the next merge window, and another for
 longer-term work.
diff --git a/Documentation/process/7.AdvancedTopics.rst b/Documentation/process/7.AdvancedTopics.rst
index 185651d87f2a..066655e5d536 100644
--- a/Documentation/process/7.AdvancedTopics.rst
+++ b/Documentation/process/7.AdvancedTopics.rst
@@ -8,7 +8,7 @@ works.  There is still more to learn, however!  This section will cover a
 number of topics which can be helpful for developers wanting to become a
 regular part of the Linux kernel development process.
 
-Managing patches with git
+Managing patches with Git
 -------------------------
 
 The use of distributed version control for the kernel began in early 2002,
@@ -17,17 +17,17 @@ application.  While BitKeeper was controversial, the approach to software
 version management it embodied most certainly was not.  Distributed version
 control enabled an immediate acceleration of the kernel development
 project.  In current times, there are several free alternatives to
-BitKeeper.  For better or for worse, the kernel project has settled on git
+BitKeeper.  For better or for worse, the kernel project has settled on Git
 as its tool of choice.
 
-Managing patches with git can make life much easier for the developer,
+Managing patches with Git can make life much easier for the developer,
 especially as the volume of those patches grows.  Git also has its rough
 edges and poses certain hazards; it is a young and powerful tool which is
 still being civilized by its developers.  This document will not attempt to
-teach the reader how to use git; that would be sufficient material for a
-long document in its own right.  Instead, the focus here will be on how git
+teach the reader how to use Git; that would be sufficient material for a
+long document in its own right.  Instead, the focus here will be on how Git
 fits into the kernel development process in particular.  Developers who
-wish to come up to speed with git will find more information at:
+wish to come up to speed with Git will find more information at:
 
 	https://git-scm.com/
 
@@ -36,20 +36,20 @@ wish to come up to speed with git will find more information at:
 and on various tutorials found on the web.
 
 The first order of business is to read the above sites and get a solid
-understanding of how git works before trying to use it to make patches
+understanding of how Git works before trying to use it to make patches
 available to others.  A git-using developer should be able to obtain a copy
 of the mainline repository, explore the revision history, commit changes to
-the tree, use branches, etc.  An understanding of git's tools for the
+the tree, use branches, etc.  An understanding of Git's tools for the
 rewriting of history (such as rebase) is also useful.  Git comes with its
-own terminology and concepts; a new user of git should know about refs,
+own terminology and concepts; a new user of Git should know about refs,
 remote branches, the index, fast-forward merges, pushes and pulls, detached
 heads, etc.  It can all be a little intimidating at the outset, but the
 concepts are not that hard to grasp with a bit of study.
 
-Using git to generate patches for submission by email can be a good
+Using Git to generate patches for submission by email can be a good
 exercise while coming up to speed.
 
-When you are ready to start putting up git trees for others to look at, you
+When you are ready to start putting up Git trees for others to look at, you
 will, of course, need a server that can be pulled from.  Setting up such a
 server with git-daemon is relatively straightforward if you have a system
 which is accessible to the Internet.  Otherwise, free, public hosting sites
@@ -57,9 +57,9 @@ which is accessible to the Internet.  Otherwise, free, public hosting sites
 developers can get an account on kernel.org, but those are not easy to come
 by; see https://kernel.org/faq/ for more information.
 
-The normal git workflow involves the use of a lot of branches.  Each line
+The normal Git workflow involves the use of a lot of branches.  Each line
 of development can be separated into a separate "topic branch" and
-maintained independently.  Branches in git are cheap, there is no reason to
+maintained independently.  Branches in Git are cheap, there is no reason to
 not make free use of them.  And, in any case, you should not do your
 development in any branch which you intend to ask others to pull from.
 Publicly-available branches should be created with care; merge in patches
@@ -72,7 +72,7 @@ say, or which has some other sort of obvious bug) can be fixed in place or
 made to disappear from the history entirely.  A patch series can be
 rewritten as if it had been written on top of today's mainline, even though
 you have been working on it for months.  Changes can be transparently
-shifted from one branch to another.  And so on.  Judicious use of git's
+shifted from one branch to another.  And so on.  Judicious use of Git's
 ability to revise history can help in the creation of clean patch sets with
 fewer problems.
 
@@ -111,16 +111,16 @@ perform test merges in a private branch.  The git "rerere" tool can be
 useful in such situations; it remembers how merge conflicts were resolved
 so that you don't have to do the same work twice.
 
-One of the biggest recurring complaints about tools like git is this: the
+One of the biggest recurring complaints about tools like Git is this: the
 mass movement of patches from one repository to another makes it easy to
 slip in ill-advised changes which go into the mainline below the review
 radar.  Kernel developers tend to get unhappy when they see that kind of
-thing happening; putting up a git tree with unreviewed or off-topic patches
+thing happening; putting up a Git tree with unreviewed or off-topic patches
 can affect your ability to get trees pulled in the future.  Quoting Linus:
 
 ::
 
-	You can send me patches, but for me to pull a git patch from you, I
+	You can send me patches, but for me to pull a Git patch from you, I
 	need to know that you know what you're doing, and I need to be able
 	to trust things *without* then having to go and check every
 	individual change by hand.
@@ -130,7 +130,7 @@ can affect your ability to get trees pulled in the future.  Quoting Linus:
 To avoid this kind of situation, ensure that all patches within a given
 branch stick closely to the associated topic; a "driver fixes" branch
 should not be making changes to the core memory management code.  And, most
-importantly, do not use a git tree to bypass the review process.  Post an
+importantly, do not use a Git tree to bypass the review process.  Post an
 occasional summary of the tree to the relevant list, and, when the time is
 right, request that the tree be included in linux-next.
 
diff --git a/Documentation/process/backporting.rst b/Documentation/process/backporting.rst
index 0de9eacd46a7..abc5f8925a78 100644
--- a/Documentation/process/backporting.rst
+++ b/Documentation/process/backporting.rst
@@ -40,8 +40,8 @@ edit the patch to make it apply.
 
 It is strongly recommended to instead find an appropriate base version
 where the patch applies cleanly and *then* cherry-pick it over to your
-destination tree, as this will make git output conflict markers and let
-you resolve conflicts with the help of git and any other conflict
+destination tree, as this will make Git output conflict markers and let
+you resolve conflicts with the help of Git and any other conflict
 resolution tools you might prefer to use. For example, if you want to
 apply a patch that just arrived on LKML to an older stable kernel, you
 can apply it to the most recent mainline kernel and then cherry-pick it
@@ -54,7 +54,7 @@ problem with applying the patch to the "wrong" base is that it may pull
 in more unrelated changes in the context of the diff when cherry-picking
 it to the older branch.
 
-A good reason to prefer ``git cherry-pick`` over ``git am`` is that git
+A good reason to prefer ``git cherry-pick`` over ``git am`` is that Git
 knows the precise history of an existing commit, so it will know when
 code has moved around and changed the line numbers; this in turn makes
 it less likely to apply the patch to the wrong place (which can result
@@ -69,7 +69,7 @@ article will assume that you are doing a plain ``git cherry-pick``.
 .. _b4: https://people.kernel.org/monsieuricon/introducing-b4-and-patch-attestation
 .. _b4 presentation: https://youtu.be/mF10hgVIx9o?t=2996
 
-Once you have the patch in git, you can go ahead and cherry-pick it into
+Once you have the patch in Git, you can go ahead and cherry-pick it into
 your source tree. Don't forget to cherry-pick with ``-x`` if you want a
 written record of where the patch came from!
 
@@ -101,7 +101,7 @@ backporting from contains patches not in the branch you are backporting
 to. However, the reverse is also possible. In any case, the result is a
 conflict that needs to be resolved.
 
-If your attempted cherry-pick fails with a conflict, git automatically
+If your attempted cherry-pick fails with a conflict, Git automatically
 edits the files to include so-called conflict markers showing you where
 the conflict is and how the two branches have diverged. Resolving the
 conflict typically means editing the end result in such a way that it
@@ -128,7 +128,7 @@ pointers to various tools that you could use:
 -  `IntelliJ <https://www.jetbrains.com/help/idea/resolve-conflicts.html>`__
 -  `VSCode <https://code.visualstudio.com/docs/editor/versioncontrol>`__
 
-To configure git to work with these, see ``git mergetool --help`` or
+To configure Git to work with these, see ``git mergetool --help`` or
 the official `git-mergetool documentation`_.
 
 .. _git-mergetool documentation: https://git-scm.com/docs/git-mergetool
@@ -326,7 +326,7 @@ style, which looks like this::
     this is what the patch wants it to be after being applied
     >>>>>>> <commit> (title)
 
-As you can see, this has 3 parts instead of 2, and includes what git
+As you can see, this has 3 parts instead of 2, and includes what Git
 expected to find there but didn't. It is *highly recommended* to use
 this conflict style as it makes it much clearer what the patch actually
 changed; i.e., it allows you to compare the before-and-after versions
@@ -382,7 +382,7 @@ Dealing with file renames
 
 One of the most annoying things that can happen while backporting a
 patch is discovering that one of the files being patched has been
-renamed, as that typically means git won't even put in conflict markers,
+renamed, as that typically means Git won't even put in conflict markers,
 but will just throw up its hands and say (paraphrased): "Unmerged path!
 You do the work..."
 
@@ -393,7 +393,7 @@ other hand, if the change is big or complicated, you definitely don't
 want to do it by hand.
 
 As a first pass, you can try something like this, which will lower the
-rename detection threshold to 30% (by default, git uses 50%, meaning
+rename detection threshold to 30% (by default, Git uses 50%, meaning
 that two files need to have at least 50% in common for it to consider
 an add-delete pair to be a potential rename)::
 
diff --git a/Documentation/process/embargoed-hardware-issues.rst b/Documentation/process/embargoed-hardware-issues.rst
index d07f16c3c7b8..2c244a6d1463 100644
--- a/Documentation/process/embargoed-hardware-issues.rst
+++ b/Documentation/process/embargoed-hardware-issues.rst
@@ -187,7 +187,7 @@ security issues in the past.
 
 The mailing list operates in the same way as normal Linux development.
 Patches are posted, discussed, and reviewed and if agreed upon, applied to
-a non-public git repository which is only accessible to the participating
+a non-public Git repository which is only accessible to the participating
 developers via a secure connection. The repository contains the main
 development branch against the mainline kernel and backport branches for
 stable kernel versions as necessary.
diff --git a/Documentation/process/handling-regressions.rst b/Documentation/process/handling-regressions.rst
index c71b5d403f0c..6958a2a8b034 100644
--- a/Documentation/process/handling-regressions.rst
+++ b/Documentation/process/handling-regressions.rst
@@ -283,7 +283,7 @@ sure your patch description makes this aspect obvious. Once the change is
 merged, tell the Linux kernel's regression tracker and the regressions mailing
 list about the risk, so everyone has the change on the radar in case reports
 trickle in. Depending on the risk, you also might want to ask the subsystem
-maintainer to mention the issue in his mainline pull request.
+maintainer to mention the issue in their mainline pull request.
 
 What else is there to known about regressions?
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
index 9438e03d6f50..8c60138d03f2 100644
--- a/Documentation/process/howto.rst
+++ b/Documentation/process/howto.rst
@@ -305,7 +305,7 @@ The maintainers of the various kernel subsystems --- and also many
 kernel subsystem developers --- expose their current state of
 development in source repositories.  That way, others can see what is
 happening in the different areas of the kernel.  In areas where
-development is rapid, a developer may be asked to base his submissions
+development is rapid, a developer may be asked to base their submissions
 onto such a subsystem kernel tree so that conflicts between the
 submission and other already ongoing work are avoided.
 
diff --git a/Documentation/process/maintainer-pgp-guide.rst b/Documentation/process/maintainer-pgp-guide.rst
index 652dfbe64102..9f6fff2a78e2 100644
--- a/Documentation/process/maintainer-pgp-guide.rst
+++ b/Documentation/process/maintainer-pgp-guide.rst
@@ -25,16 +25,16 @@ communication channels between developers via PGP-signed email exchange.
 
 The Linux kernel source code is available in two main formats:
 
-- Distributed source repositories (git)
+- Distributed source repositories (Git)
 - Periodic release snapshots (tarballs)
 
-Both git repositories and tarballs carry PGP signatures of the kernel
+Both Git repositories and tarballs carry PGP signatures of the kernel
 developers who create official kernel releases. These signatures offer a
 cryptographic guarantee that downloadable versions made available via
 kernel.org or any other mirrors are identical to what these developers
 have on their workstations. To this end:
 
-- git repositories provide PGP signatures on all tags
+- Git repositories provide PGP signatures on all tags
 - tarballs provide detached PGP signatures with all downloads
 
 .. _devs_not_infra:
@@ -660,12 +660,12 @@ impersonate you without having access to your PGP keys.
 
 .. _`nothing to do with it`: https://github.com/jayphelps/git-blame-someone-else
 
-Configure git to use your PGP key
+Configure Git to use your PGP key
 ---------------------------------
 
 If you only have one secret key in your keyring, then you don't really
 need to do anything extra, as it becomes your default key.  However, if
-you happen to have multiple secret keys, you can tell git which key
+you happen to have multiple secret keys, you can tell Git which key
 should be used (``[fpr]`` is the fingerprint of your key)::
 
     $ git config --global user.signingKey [fpr]
@@ -677,8 +677,8 @@ To create a signed tag, pass the ``-s`` switch to the tag command::
 
     $ git tag -s [tagname]
 
-Our recommendation is to always sign git tags, as this allows other
-developers to ensure that the git repository they are pulling from has
+Our recommendation is to always sign Git tags, as this allows other
+developers to ensure that the Git repository they are pulling from has
 not been maliciously altered.
 
 How to verify signed tags
@@ -689,7 +689,7 @@ To verify a signed tag, use the ``verify-tag`` command::
     $ git verify-tag [tagname]
 
 If you are pulling a tag from another fork of the project repository,
-git should automatically verify the signature at the tip you're pulling
+Git should automatically verify the signature at the tip you're pulling
 and show you the results during the merge operation::
 
     $ git pull [url] tags/sometag
@@ -703,15 +703,15 @@ The merge message will contain something like this::
     # gpg: Signature made [...]
     # gpg: Good signature from [...]
 
-If you are verifying someone else's git tag, you will first need to
+If you are verifying someone else's Git tag, you will first need to
 import their PGP key. Please refer to the ":ref:`verify_identities`"
 section below.
 
-Configure git to always sign annotated tags
+Configure Git to always sign annotated tags
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Chances are, if you're creating an annotated tag, you'll want to sign
-it. To force git to always sign annotated tags, you can set a global
+it. To force Git to always sign annotated tags, you can set a global
 configuration option::
 
     $ git config --global tag.forceSignAnnotated true
@@ -722,15 +722,15 @@ How to work with signed commits
 It is also possible to create signed commits, but they have limited
 usefulness in Linux kernel development. The kernel contribution workflow
 relies on sending in patches, and converting commits to patches does not
-preserve git commit signatures. Furthermore, when rebasing your own
+preserve Git commit signatures. Furthermore, when rebasing your own
 repository on a newer upstream, PGP commit signatures will end up
 discarded. For this reason, most kernel developers don't bother signing
 their commits and will ignore signed commits in any external
 repositories that they rely upon in their work.
 
-That said, if you have your working git tree publicly available at some
-git hosting service (kernel.org, infradead.org, ozlabs.org, or others),
-then the recommendation is that you sign all your git commits even if
+That said, if you have your working Git tree publicly available at some
+Git hosting service (kernel.org, infradead.org, ozlabs.org, or others),
+then the recommendation is that you sign all your Git commits even if
 upstream developers do not directly benefit from this practice.
 
 We recommend this for the following reasons:
@@ -752,10 +752,10 @@ command (it's capital ``-S`` due to collision with another flag)::
 
     $ git commit -S
 
-Configure git to always sign commits
+Configure Git to always sign commits
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-You can tell git to always sign commits::
+You can tell Git to always sign commits::
 
     git config --global commit.gpgSign true
 
@@ -790,7 +790,7 @@ Installing and configuring patatt
 Patatt is packaged for many distributions already, so please check there
 first. You can also install it from pypi using "``pip install patatt``".
 
-If you already have your PGP key configured with git (via the
+If you already have your PGP key configured with Git (via the
 ``user.signingKey`` configuration parameter), then patatt requires no
 further configuration. You can start signing your patches by installing
 the git-send-email hook in the repository you want::
@@ -902,7 +902,7 @@ the new default in GnuPG v2). To set it, add (or modify) the
 Using the kernel.org web of trust repository
 --------------------------------------------
 
-Kernel.org maintains a git repository with developers' public keys as a
+Kernel.org maintains a Git repository with developers' public keys as a
 replacement for replicating keyserver networks that have gone mostly
 dark in the past few years. The full documentation for how to set up
 that repository as your source of public keys can be found here:
diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index 7ae79452e1b4..4c28a239e8cb 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -456,7 +456,7 @@ When to use Acked-by:, Cc:, and Co-developed-by:
 ------------------------------------------------
 
 The Signed-off-by: tag indicates that the signer was involved in the
-development of the patch, or that he/she was in the patch's delivery path.
+development of the patch, or that they were in the patch's delivery path.
 
 If a person was not directly involved in the preparation or handling of a
 patch but wishes to signify and record their approval of it then they can
diff --git a/Documentation/scheduler/index.rst b/Documentation/scheduler/index.rst
index 17ce8d76befc..d6d75421756a 100644
--- a/Documentation/scheduler/index.rst
+++ b/Documentation/scheduler/index.rst
@@ -23,5 +23,6 @@ Scheduler
     sched-stats
     sched-ext
     sched-debug
+    sched-preemption
 
     text_files
diff --git a/Documentation/scheduler/sched-preemption.rst b/Documentation/scheduler/sched-preemption.rst
new file mode 100644
index 000000000000..b48e53587a7a
--- /dev/null
+++ b/Documentation/scheduler/sched-preemption.rst
@@ -0,0 +1,87 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=====================
+Scheduler preemption
+=====================
+
+The kernel can be built to run kernel code either uninterruptibly, or with
+varying degrees of preemptibility.  These are the *preemption models*.
+They apply to kernel code only: a task running in user space is always
+preempted by the scheduler, whichever model is selected.
+
+When CONFIG_PREEMPT_DYNAMIC is enabled the preemption model can additionally
+be selected at boot time with the ``preempt=`` command line parameter, without
+rebuilding the kernel.  See
+Documentation/admin-guide/kernel-parameters.txt for the parameter itself.
+The active model can also be read and changed through
+/sys/kernel/debug/sched/preempt, which exists for debugging purposes and may
+change.
+
+The models selectable at runtime are:
+
+	=========	====================================================
+	none		No preemption of kernel code other than at explicit
+			``cond_resched()`` / blocking points.
+	voluntary	As ``none``, plus ``might_sleep()`` sites.
+	full		Any section that is not explicitly preempt disabled
+			may be preempted at any time.
+	lazy		As ``full``, except that the scheduling request is
+			delayed until the return to user space or the next
+			tick, whichever comes first.  This delay does not
+			apply to real-time tasks.
+	=========	====================================================
+
+Not every model is available on every kernel.  An architecture that provides
+lazy-preempt support offers only ``full`` and ``lazy``, and ``none`` and
+``voluntary`` are rejected there.  A PREEMPT_RT kernel always offers ``full``,
+and ``lazy`` as well if the architecture provides it.
+
+The model that is actually active is reported in the boot log::
+
+	Dynamic Preempt: full
+
+Honouring a scheduling request
+==============================
+
+A wakeup makes a task runnable, and the scheduler then decides whether it
+should run.  If there is an idle CPU which is suitable then the task is moved
+there.  Otherwise the scheduler has to decide which task to preempt, and the
+task that has to leave the CPU gets a reschedule flag.  In the tracing output
+this is the ``need-resched`` column, ``N`` for TIF_NEED_RESCHED and ``l`` for
+TIF_NEED_RESCHED_LAZY.
+
+The kernel then has to honour that request.  A task executing in user space
+can always be preempted; a task executing in kernel space can only be
+preempted where it is safe to do so, and how that is decided is what
+separates the models:
+
+``none``
+	Code paths with long loops contain explicit ``cond_resched()`` calls,
+	which perform the scheduling.
+
+``voluntary``
+	As ``none``, and functions which are known to be able to block gain
+	a ``cond_resched()``-style scheduling point as well, through
+	``might_sleep()``.
+
+``full``
+	Explicit preemption points are no longer involved.  The kernel tracks
+	whether it may be preempted and schedules once the request can be
+	honoured.
+
+``lazy``
+	As ``full``, with one difference: the request the fair scheduler sets
+	is TIF_NEED_RESCHED_LAZY, which is not honoured immediately even where
+	it could be.  It is delayed until the task returns to user space, so
+	that the in-kernel work runs to completion and every lock has been
+	dropped before the CPU is given up.  If the task has not scheduled on
+	its own by then, the request is turned into a full TIF_NEED_RESCHED on
+	the next HZ tick; this is visible as ``B`` in the ``need-resched``
+	column.
+
+Real-time tasks always use TIF_NEED_RESCHED, so the delay above does not
+apply to them.  ``lazy`` is therefore not a replacement for PREEMPT_RT: it
+keeps most of the responsiveness of ``full`` for SCHED_NORMAL tasks while
+letting them run to completion, which avoids leaving a lock behind that
+another task will immediately ask for, and avoids pushing cache-hot data out
+that would have to be pulled back in.
diff --git a/Documentation/timers/hpet.rst b/Documentation/timers/hpet.rst
index c9d05d3caaca..254d0bb2b802 100644
--- a/Documentation/timers/hpet.rst
+++ b/Documentation/timers/hpet.rst
@@ -23,8 +23,37 @@ The driver supports detection of HPET driver allocation and initialization
 of the HPET before the driver module_init routine is called.  This enables
 platform code which uses timer 0 or 1 as the main timer to intercept HPET
 initialization.  An example of this initialization can be found in
-arch/x86/kernel/hpet.c.
+``arch/x86/kernel/hpet.c``.
 
 The driver provides a userspace API which resembles the API found in the
 RTC driver framework.  An example user space program is provided in
-file:samples/timers/hpet_example.c
+``samples/timers/hpet_example.c``
+
+Userspace API and ioctl Commands
+================================
+
+* ``HPET_IE_ON`` / ``HPET_IE_OFF``
+  Enables or disables the interrupt generation for the timer channel.
+
+* ``HPET_INFO``
+  It is used to query the capabilities and current status of the HPET.
+  When the ioctl call is made, the kernel populates the ``struct hpet_info``
+  structure and returns it to userspace:
+
+  .. code-block:: c
+
+     struct hpet_info {
+         unsigned long hi_ireqfreq;	/* Hz */
+         unsigned long hi_flags;	/* information */
+         unsigned short hi_hpet;
+         unsigned short hi_timer;
+     };
+
+* ``HPET_EPI`` / ``HPET_DPI``
+  Enables or disables periodic interrupts. When activated, the timer
+  triggers continuously at the specified frequency.
+
+* ``HPET_IRQFREQ``
+  Sets the interrupt frequency for the periodic timer. This request
+  takes an unsigned long argument specifying the desired frequency in Hz.
+
diff --git a/Documentation/timers/no_hz.rst b/Documentation/timers/no_hz.rst
index 7fe8ef9718d8..4006cab64079 100644
--- a/Documentation/timers/no_hz.rst
+++ b/Documentation/timers/no_hz.rst
@@ -204,9 +204,9 @@ but do not see any change in your workload's behavior.  Is this because
 your workload isn't affected that much by OS jitter, or is it because
 something else is in the way?  This section helps answer this question
 by providing a simple OS-jitter test suite, which is available on branch
-master of the following git archive:
+master of the following git repository:
 
-git://git.kernel.org/pub/scm/linux/kernel/git/frederic/dynticks-testing.git
+https://git.kernel.org/pub/scm/linux/kernel/git/frederic/cpunoise.git
 
 Clone this archive and follow the instructions in the README file.
 This test procedure will produce a trace that will allow you to evaluate
diff --git a/Documentation/translations/pt_BR/admin-guide/README.rst b/Documentation/translations/pt_BR/admin-guide/README.rst
new file mode 100644
index 000000000000..1843f89b12cc
--- /dev/null
+++ b/Documentation/translations/pt_BR/admin-guide/README.rst
@@ -0,0 +1,382 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _pt_BR_readme:
+
+Versão 6.x do kernel Linux <http://kernel.org/>
+===============================================
+
+Estas são as notas de lançamento da versão 6 do Linux. Leia-as com atenção,
+pois elas dizem do que se trata tudo isso, explicam como instalar o kernel e
+o que fazer se algo der errado.
+
+O que é o Linux?
+----------------
+
+  O Linux é um clone do sistema operacional Unix, escrito do zero por Linus
+  Torvalds com a ajuda de uma equipe pouco organizada de hackers espalhados
+  pela Internet. Ele busca a conformidade com o POSIX e com a Single UNIX
+  Specification.
+
+  Possui todos os recursos que você esperaria de um Unix moderno e completo,
+  incluindo multitarefa real, memória virtual, bibliotecas compartilhadas,
+  carregamento sob demanda (demand loading), executáveis compartilhados com
+  cópia-na-escrita (copy-on-write), gerenciamento de memória adequado e rede
+  multipilha, incluindo IPv4 e IPv6.
+
+  É distribuído sob a GNU General Public License v2 --- veja o arquivo
+  COPYING que o acompanha para mais detalhes.
+
+Em qual hardware ele roda?
+--------------------------
+
+  Embora tenha sido originalmente desenvolvido primeiro para PCs de 32 bits
+  baseados em x86 (386 ou superior), hoje o Linux também roda (pelo menos)
+  nas arquiteturas Compaq Alpha AXP, Sun SPARC e UltraSPARC, Motorola 68000,
+  PowerPC, PowerPC64, ARM, Hitachi SuperH, Cell, IBM S/390, MIPS, HP PA-RISC,
+  Intel IA-64, DEC VAX, AMD x86-64 Xtensa e ARC.
+
+  O Linux é facilmente portável para a maioria das arquiteturas de propósito
+  geral de 32 ou 64 bits, desde que possuam uma unidade de gerenciamento de
+  memória paginada (PMMU) e um port do compilador C da GNU (gcc), parte da
+  GNU Compiler Collection (GCC). O Linux também já foi portado para diversas
+  arquiteturas sem PMMU, embora a funcionalidade fique, obviamente, um tanto
+  limitada.
+  O Linux também foi portado para si mesmo. Você pode agora executar o kernel
+  como uma aplicação de espaço de usuário --- isso se chama UserMode Linux
+  (UML).
+
+Documentação
+------------
+
+ - Há muita documentação disponível, tanto em formato eletrônico na Internet
+   quanto em livros, tanto específica do Linux quanto referente a questões
+   gerais do UNIX. Eu recomendaria procurar nos subdiretórios de documentação
+   de qualquer site FTP do Linux pelos livros do LDP (Linux Documentation
+   Project). Este README não pretende ser a documentação do sistema: existem
+   fontes muito melhores disponíveis.
+
+ - Existem vários arquivos README no subdiretório Documentation/: eles
+   normalmente contêm notas de instalação específicas do kernel para alguns
+   drivers, por exemplo. Por favor, leia o arquivo
+   Documentation/translations/pt_BR/process/changes.rst, pois ele contém
+   informações sobre os problemas que podem resultar da atualização do seu
+   kernel.
+
+Instalando o código-fonte do kernel
+-----------------------------------
+
+ - Se você instalar as fontes completas, coloque o tarball do kernel em um
+   diretório no qual você tenha permissões (por exemplo, o seu diretório
+   pessoal) e o descompacte::
+
+     xz -cd linux-6.x.tar.xz | tar xvf -
+
+   Substitua "X" pelo número da versão do kernel mais recente.
+
+   NÃO use a área /usr/src/linux! Essa área possui um conjunto (geralmente
+   incompleto) de cabeçalhos do kernel que são usados pelos arquivos de
+   cabeçalho da biblioteca. Eles devem corresponder à biblioteca, e não ser
+   bagunçados por qualquer que seja o kernel-do-dia.
+
+ - Você também pode atualizar entre versões 6.x aplicando patches. Os patches
+   são distribuídos no formato xz. Para instalar aplicando patches, obtenha
+   todos os arquivos de patch mais novos, entre no diretório de nível
+   superior do código-fonte do kernel (linux-6.x) e execute::
+
+     xz -cd ../patch-6.x.xz | patch -p1
+
+   Substitua "x" para todas as versões maiores que a versão "x" da sua árvore
+   de fontes atual, **em ordem**, e deve dar tudo certo. Talvez você queira
+   remover os arquivos de backup (algum-nome-de-arquivo~ ou
+   algum-nome-de-arquivo.orig) e certificar-se de que não há patches que
+   falharam (algum-nome-de-arquivo# ou algum-nome-de-arquivo.rej). Se
+   houver, ou você ou eu cometemos um erro.
+
+   Diferentemente dos patches para os kernels 6.x, os patches para os kernels
+   6.x.y (também conhecidos como kernels -stable) não são incrementais; em vez
+   disso, eles se aplicam diretamente ao kernel 6.x base. Por exemplo, se o
+   seu kernel base é o 6.0 e você quer aplicar o patch 6.0.3, você não deve
+   aplicar antes os patches 6.0.1 e 6.0.2. Da mesma forma, se você está
+   rodando a versão 6.0.2 do kernel e quer saltar para a 6.0.3, você deve
+   primeiro reverter o patch 6.0.2 (ou seja, patch -R) **antes** de aplicar o
+   patch 6.0.3. Você pode ler mais sobre isso em
+   Documentation/translations/pt_BR/process/applying-patches.rst.
+
+   Como alternativa, o script patch-kernel pode ser usado para automatizar
+   esse processo. Ele determina a versão atual do kernel e aplica quaisquer
+   patches encontrados::
+
+     linux/scripts/patch-kernel linux
+
+   O primeiro argumento no comando acima é a localização do código-fonte do
+   kernel. Os patches são aplicados a partir do diretório atual, mas um
+   diretório alternativo pode ser especificado como segundo argumento.
+
+ - Certifique-se de que não há arquivos .o e dependências obsoletos espalhados
+   por aí::
+
+     cd linux
+     make mrproper
+
+   Agora você deve ter as fontes instaladas corretamente.
+
+Requisitos de software
+----------------------
+
+   Compilar e executar os kernels 6.x exige versões atualizadas de vários
+   pacotes de software. Consulte
+   Documentation/translations/pt_BR/process/changes.rst para os números de
+   versão mínimos exigidos e como obter atualizações desses pacotes. Esteja
+   ciente de que usar versões excessivamente antigas desses pacotes pode
+   causar erros indiretos, muito difíceis de rastrear; portanto, não presuma
+   que basta atualizar os pacotes quando problemas óbvios surgirem durante a
+   compilação ou a execução.
+
+Diretório de compilação do kernel
+---------------------------------
+
+   Ao compilar o kernel, todos os arquivos de saída serão, por padrão,
+   armazenados junto com o código-fonte do kernel.
+   Usar a opção ``make O=output/dir`` permite especificar um local alternativo
+   para os arquivos de saída (incluindo o .config).
+   Exemplo::
+
+     código-fonte do kernel:    /usr/src/linux-6.x
+     diretório de compilação:   /home/nome/build/kernel
+
+   Para configurar e compilar o kernel, use::
+
+     cd /usr/src/linux-6.x
+     make O=/home/nome/build/kernel menuconfig
+     make O=/home/nome/build/kernel
+     sudo make O=/home/nome/build/kernel modules_install install
+
+   Observe: se a opção ``O=output/dir`` for usada, ela deve ser usada em todas
+   as invocações do make.
+
+Configurando o kernel
+---------------------
+
+   Não pule esta etapa, mesmo que você esteja atualizando apenas uma versão
+   menor. Novas opções de configuração são adicionadas a cada lançamento, e
+   problemas estranhos aparecerão se os arquivos de configuração não estiverem
+   preparados como esperado. Se você quiser levar a sua configuração existente
+   para uma nova versão com o mínimo de trabalho, use ``make oldconfig``, que
+   perguntará apenas as respostas para as novas questões.
+
+ - Comandos alternativos de configuração são::
+
+     "make config"      Interface em texto puro.
+
+     "make menuconfig"  Menus coloridos, listas de seleção e diálogos, em
+                        modo texto.
+
+     "make nconfig"     Menus coloridos aprimorados, em modo texto.
+
+     "make xconfig"     Ferramenta de configuração baseada em Qt.
+
+     "make gconfig"     Ferramenta de configuração baseada em GTK.
+
+     "make oldconfig"   Assume o padrão para todas as questões com base no
+                        conteúdo do seu arquivo ./.config existente e
+                        pergunta sobre os novos símbolos de configuração.
+
+     "make olddefconfig"
+                        Como o anterior, mas define os novos símbolos com
+                        seus valores padrão, sem perguntar.
+
+     "make defconfig"   Cria um arquivo ./.config usando os valores padrão
+                        dos símbolos, vindos de
+                        arch/$ARCH/configs/defconfig ou de
+                        arch/$ARCH/configs/${PLATFORM}_defconfig,
+                        dependendo da arquitetura.
+
+     "make ${PLATFORM}_defconfig"
+                        Cria um arquivo ./.config usando os valores padrão
+                        dos símbolos vindos de
+                        arch/$ARCH/configs/${PLATFORM}_defconfig.
+                        Use "make help" para obter uma lista de todas as
+                        plataformas disponíveis para a sua arquitetura.
+
+     "make allyesconfig"
+                        Cria um arquivo ./.config definindo os valores dos
+                        símbolos como 'y' sempre que possível.
+
+     "make allmodconfig"
+                        Cria um arquivo ./.config definindo os valores dos
+                        símbolos como 'm' sempre que possível.
+
+     "make allnoconfig" Cria um arquivo ./.config definindo os valores dos
+                        símbolos como 'n' sempre que possível.
+
+     "make randconfig"  Cria um arquivo ./.config definindo os valores dos
+                        símbolos aleatoriamente.
+
+     "make localmodconfig" Cria uma configuração baseada na configuração
+                           atual e nos módulos carregados (lsmod). Desativa
+                           qualquer opção de módulo que não seja necessária
+                           para os módulos carregados.
+
+                           Para criar um localmodconfig para outra máquina,
+                           armazene o lsmod daquela máquina em um arquivo e
+                           o passe como parâmetro LSMOD.
+
+                           Além disso, você pode preservar módulos em certas
+                           pastas ou arquivos kconfig especificando seus
+                           caminhos no parâmetro LMC_KEEP.
+
+                   alvo$ lsmod > /tmp/mylsmod
+                   alvo$ scp /tmp/mylsmod host:/tmp
+
+                   host$ make LSMOD=/tmp/mylsmod \
+                           LMC_KEEP="drivers/usb:drivers/gpu:fs" \
+                           localmodconfig
+
+                           O acima também funciona em compilação cruzada.
+
+     "make localyesconfig" Semelhante ao localmodconfig, exceto que converte
+                           todas as opções de módulo em opções embutidas
+                           (=y). Você também pode preservar módulos com o
+                           LMC_KEEP.
+
+     "make kvm_guest.config"   Habilita opções adicionais para suporte a
+                               kernel convidado do kvm.
+
+     "make xen.config"   Habilita opções adicionais para suporte a kernel
+                         convidado dom0 do xen.
+
+     "make tinyconfig"  Configura o menor kernel possível.
+
+   Você pode encontrar mais informações sobre o uso das ferramentas de
+   configuração do kernel Linux em Documentation/kbuild/kconfig.rst.
+
+ - NOTAS sobre o ``make config``:
+
+    - Ter drivers desnecessários deixará o kernel maior e, em algumas
+      circunstâncias, pode levar a problemas: sondar uma placa controladora
+      inexistente pode confundir as suas outras controladoras.
+
+    - Um kernel com emulação matemática compilada ainda usará o
+      coprocessador, se houver um presente: a emulação matemática
+      simplesmente nunca será usada nesse caso. O kernel ficará um pouco
+      maior, mas funcionará em máquinas diferentes, independentemente de
+      terem ou não um coprocessador matemático.
+
+    - Os detalhes de configuração de "kernel hacking" normalmente resultam em
+      um kernel maior ou mais lento (ou ambos), e podem até tornar o kernel
+      menos estável, ao configurar algumas rotinas para tentar ativamente
+      quebrar código ruim e encontrar problemas no kernel (kmalloc()).
+      Portanto, você provavelmente deve responder 'n' às questões sobre
+      recursos de "development", "experimental" ou "debugging".
+
+Compilando o kernel
+-------------------
+
+ - Certifique-se de ter pelo menos o gcc 8.1 disponível.
+   Para mais informações, consulte
+   Documentation/translations/pt_BR/process/changes.rst.
+
+ - Execute um ``make`` para criar uma imagem compactada do kernel. Também é
+   possível executar ``make install`` se você tiver o lilo instalado ou se a
+   sua distribuição possuir um script de instalação reconhecido pelo
+   instalador do kernel. A maioria das distribuições populares terá um script
+   de instalação reconhecido. Talvez você queira verificar antes a
+   configuração da sua distribuição.
+
+   Para fazer a instalação de fato, você precisa ser root, mas nada da
+   compilação normal deve exigir isso. Não tome o nome de root em vão.
+
+ - Se você configurou qualquer parte do kernel como ``modules``, também terá
+   que executar ``make modules_install``.
+
+ - Saída detalhada (verbose) da compilação do kernel:
+
+   Normalmente, o sistema de compilação do kernel roda em um modo bastante
+   silencioso (mas não totalmente). No entanto, às vezes você ou outros
+   desenvolvedores do kernel precisam ver os comandos de compilação, de
+   ligação (link) ou outros exatamente como são executados. Para isso, use o
+   modo de compilação "verbose". Isso é feito passando ``V=1`` ao comando
+   ``make``, por exemplo::
+
+     make V=1 all
+
+   Para que o sistema de compilação também informe o motivo da recompilação
+   de cada alvo, use ``V=2``. O padrão é ``V=0``.
+
+ - Mantenha um kernel de backup à mão, caso algo dê errado. Isso é
+   especialmente verdadeiro para as versões de desenvolvimento, já que cada
+   novo lançamento contém código novo que não foi depurado. Certifique-se de
+   manter também um backup dos módulos correspondentes àquele kernel. Se
+   você estiver instalando um novo kernel com o mesmo número de versão do seu
+   kernel em funcionamento, faça um backup do seu diretório de módulos antes
+   de executar um ``make modules_install``.
+
+   Como alternativa, antes de compilar, use a opção de configuração do kernel
+   "LOCALVERSION" para acrescentar um sufixo único à versão normal do kernel.
+   A LOCALVERSION pode ser definida no menu "General Setup".
+
+ - Para inicializar o seu novo kernel, você precisará copiar a imagem do
+   kernel (por exemplo, .../linux/arch/x86/boot/bzImage após a compilação)
+   para o local onde o seu kernel inicializável habitual se encontra.
+
+ - Inicializar um kernel diretamente de um dispositivo de armazenamento, sem
+   a ajuda de um gerenciador de inicialização como o LILO ou o GRUB, não é
+   mais suportado na BIOS (sistemas não EFI). Em sistemas UEFI/EFI, no
+   entanto, você pode usar o EFISTUB, que permite à placa-mãe inicializar
+   diretamente no kernel. Em estações de trabalho e desktops modernos,
+   geralmente recomenda-se usar um gerenciador de inicialização, pois podem
+   surgir dificuldades com múltiplos kernels e com o secure boot.
+   Para mais detalhes sobre o EFISTUB, veja
+   "Documentation/admin-guide/efi-stub.rst".
+
+ - É importante observar que, desde 2016, o LILO (LInux LOader) não está mais
+   em desenvolvimento ativo, embora, por ter sido extremamente popular,
+   apareça com frequência na documentação. Alternativas populares incluem
+   GRUB2, rEFInd, Syslinux, systemd-boot ou EFISTUB. Por diversas razões, não
+   é recomendável usar software que não esteja mais em desenvolvimento ativo.
+
+ - É provável que a sua distribuição inclua um script de instalação e que
+   executar ``make install`` seja tudo o que é necessário. Caso não seja
+   assim, você terá que identificar o seu gerenciador de inicialização e
+   consultar a documentação dele, ou configurar a sua EFI.
+
+Instruções legadas do LILO
+--------------------------
+
+
+ - Se você usa o LILO, as imagens do kernel são especificadas no arquivo
+   /etc/lilo.conf. O arquivo de imagem do kernel geralmente é /vmlinuz,
+   /boot/vmlinuz, /bzImage ou /boot/bzImage. Para usar o novo kernel, salve
+   uma cópia da imagem antiga e copie a nova imagem por cima da antiga.
+   Então, você DEVE EXECUTAR O LILO NOVAMENTE para atualizar o mapa de
+   carregamento! Se não fizer isso, não conseguirá inicializar a nova imagem
+   do kernel.
+
+ - Reinstalar o LILO geralmente é uma questão de executar /sbin/lilo. Talvez
+   você queira editar o /etc/lilo.conf para especificar uma entrada para a
+   sua imagem antiga do kernel (digamos, /vmlinux.old), caso a nova não
+   funcione. Veja a documentação do LILO para mais informações.
+
+ - Após reinstalar o LILO, deve estar tudo pronto. Desligue o sistema,
+   reinicie e aproveite!
+
+ - Se algum dia você precisar alterar o dispositivo raiz padrão, o modo de
+   vídeo, etc. na imagem do kernel, use as opções de inicialização do seu
+   gerenciador de inicialização onde for apropriado. Não é necessário
+   recompilar o kernel para alterar esses parâmetros.
+
+ - Reinicie com o novo kernel e aproveite.
+
+
+Se algo der errado
+------------------
+
+Se você tiver problemas que pareçam ser causados por bugs do kernel, por
+favor, siga as instruções em
+'Documentation/admin-guide/reporting-issues.rst'.
+
+Dicas sobre como entender os relatórios de bugs do kernel estão em
+'Documentation/admin-guide/bug-hunting.rst'. Mais sobre depuração do kernel
+com o gdb está em
+'Documentation/process/debugging/gdb-kernel-debugging.rst' e
+'Documentation/process/debugging/kgdb.rst'.
diff --git a/Documentation/translations/pt_BR/admin-guide/devices.rst b/Documentation/translations/pt_BR/admin-guide/devices.rst
new file mode 100644
index 000000000000..614a32c33968
--- /dev/null
+++ b/Documentation/translations/pt_BR/admin-guide/devices.rst
@@ -0,0 +1,278 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _pt_BR_admin_devices:
+
+Dispositivos alocados no Linux (versão 4.x+)
+============================================
+
+Esta lista é a Linux Device List, o registro oficial dos números de
+dispositivo alocados e dos nós do diretório ``/dev`` para o sistema
+operacional Linux.
+
+A versão deste documento em lanana.org não é mais mantida. Esta versão, no
+kernel Linux mainline, é o documento mestre. Atualizações devem ser enviadas
+como patches aos mantenedores do kernel (veja o documento
+:ref:`Documentation/translations/pt_BR/process/submitting-patches.rst <pt_BR_submittingpatches>`).
+Explore especificamente as seções intituladas "CHAR and MISC DRIVERS" e
+"BLOCK LAYER" no arquivo MAINTAINERS para encontrar os mantenedores certos
+a envolver para dispositivos de caractere e de bloco.
+
+Este documento é incluído por referência no Filesystem Hierarchy Standard
+(FHS). O FHS está disponível em https://www.pathname.com/fhs/.
+
+Alocações marcadas com (68k/Amiga) aplicam-se somente ao Linux/68k na
+plataforma Amiga. Alocações marcadas com (68k/Atari) aplicam-se somente ao
+Linux/68k na plataforma Atari.
+
+Este documento está em domínio público. Os autores solicitam, no entanto,
+que versões semanticamente alteradas não sejam distribuídas sem permissão
+dos autores, presumindo-se que os autores possam ser contatados sem um
+esforço desarrazoado.
+
+
+.. attention::
+
+  AUTORES DE DRIVERS DE DISPOSITIVO, POR FAVOR LEIAM ISTO
+
+  O Linux agora possui amplo suporte à alocação dinâmica de numeração de
+  dispositivos e pode usar ``sysfs`` e ``udev`` (``systemd``) para lidar com
+  as necessidades de nomenclatura. Ainda existem algumas exceções na área de
+  dispositivos seriais e de inicialização. Antes de pedir um número de
+  dispositivo, certifique-se de que você realmente precisa de um.
+
+  Para ter um número maior (major) alocado, ou um número menor (minor) nas
+  situações em que isso se aplica (por exemplo, busmice), por favor envie um
+  patch aos autores conforme indicado acima.
+
+  Mantenha a descrição do dispositivo *no mesmo formato desta lista*. A razão
+  para isso é que essa é a única maneira que encontramos de garantir que
+  temos todas as informações necessárias para publicar o seu dispositivo e
+  evitar conflitos.
+
+  Por fim, às vezes temos que bancar a "polícia do espaço de nomes". Por
+  favor, não se ofenda. Frequentemente recebemos submissões de nomes em
+  ``/dev`` que fatalmente causariam conflitos no futuro. Estamos tentando
+  evitar chegar a uma situação em que teríamos que sofrer uma mudança
+  incompatível para a frente. Portanto, por favor, consulte-nos **antes** de
+  tornar públicos, de qualquer forma, os nomes e números do seu dispositivo
+  --- pelo menos até o ponto em que seria minimamente difícil alterá-los.
+
+  Sua cooperação é apreciada.
+
+.. include:: ../../../admin-guide/devices.txt
+   :literal:
+
+Entradas adicionais do diretório ``/dev/``
+------------------------------------------
+
+Esta seção detalha as entradas adicionais que devem ou podem existir no
+diretório /dev. É preferível que os links simbólicos usem a mesma forma
+(absoluta ou relativa) indicada aqui. Os links são classificados como
+"físicos" (hard) ou "simbólicos", dependendo do tipo de link preferido; se
+possível, o tipo de link indicado deve ser usado.
+
+Links obrigatórios
+++++++++++++++++++
+
+Estes links devem existir em todos os sistemas:
+
+=============== =============== =============== ==============================
+/dev/fd         /proc/self/fd   simbólico       Descritores de arquivo
+/dev/stdin      fd/0            simbólico       Descritor de arquivo da stdin
+/dev/stdout     fd/1            simbólico       Descritor de arquivo da stdout
+/dev/stderr     fd/2            simbólico       Descritor de arquivo da stderr
+/dev/nfsd       socksys         simbólico       Exigido pelo iBCS-2
+/dev/X0R        null            simbólico       Exigido pelo iBCS-2
+=============== =============== =============== ==============================
+
+Observação: ``/dev/X0R`` é <letra X>-<dígito 0>-<letra R>.
+
+Links recomendados
+++++++++++++++++++
+
+Recomenda-se que estes links existam em todos os sistemas:
+
+
+=============== =============== =============== ==========================
+/dev/core       /proc/kcore     simbólico       Compatibilidade retroativa
+/dev/ramdisk    ram0            simbólico       Compatibilidade retroativa
+/dev/ftape      qft0            simbólico       Compatibilidade retroativa
+/dev/bttv0      video0          simbólico       Compatibilidade retroativa
+/dev/radio      radio0          simbólico       Compatibilidade retroativa
+/dev/i2o*       /dev/i2o/*      simbólico       Compatibilidade retroativa
+=============== =============== =============== ==========================
+
+Os nomes alternativos ``/dev/scd?``, sugeridos anteriormente para os
+``/dev/sr?`` de CD-ROM e outras unidades ópticas (que usam comandos SCSI),
+foram removidos na versão 174 do ``udev``, lançada em 2011.
+
+Links definidos localmente
+++++++++++++++++++++++++++
+
+Os links a seguir podem ser estabelecidos localmente para se adequar à
+configuração do sistema. Isto é meramente uma tabulação da prática
+existente, e não constitui uma recomendação. No entanto, se existirem, eles
+devem ter os seguintes usos.
+
+=============== ================= =============== ==============================
+/dev/mouse      porta de mouse    simbólico       Dispositivo de mouse atual
+/dev/tape       unidade de fita   simbólico       Dispositivo de fita atual
+/dev/cdrom      unidade de CD-ROM simbólico       Dispositivo de CD-ROM atual
+/dev/scanner    scanner           simbólico       Scanner atual
+/dev/modem      porta de modem    simbólico       Dispositivo de discagem atual
+/dev/root       dispositivo raiz  simbólico       Sistema de arquivos raiz atual
+/dev/swap       área de swap      simbólico       Dispositivo de swap atual
+=============== ================= =============== ==============================
+
+O ``/dev/modem`` não deve ser usado para um modem que suporte tanto discagem
+de entrada quanto de saída, pois isso tende a causar problemas com arquivos
+de trava (lock). Se existir, o ``/dev/modem`` deve apontar para o
+dispositivo TTY primário apropriado (o uso dos dispositivos alternativos de
+saída é obsoleto).
+
+Para dispositivos SCSI, o ``/dev/tape`` e o ``/dev/cdrom`` devem apontar
+para os dispositivos *cozidos* (*cooked*) (``/dev/st*`` e ``/dev/sr*``,
+respectivamente), enquanto o ``/dev/scanner`` deve apontar para o
+dispositivo SCSI genérico apropriado (``/dev/sg*``).
+
+O ``/dev/mouse`` pode apontar para um dispositivo TTY serial primário, um
+dispositivo de mouse em hardware, ou um socket para um programa de driver de
+mouse (por exemplo, ``/dev/gpmdata``).
+
+Sockets e pipes
++++++++++++++++
+
+Sockets e pipes nomeados não transitórios podem existir em /dev. As entradas
+comuns são:
+
+=============== ======== =============================
+/dev/printer    socket   socket local do lpd
+/dev/log        socket   socket local do syslog
+/dev/gpmdata    socket   multiplexador de mouse do gpm
+=============== ======== =============================
+
+Pontos de montagem
+++++++++++++++++++
+
+Os nomes a seguir são reservados para a montagem de sistemas de arquivos
+especiais sob /dev. Esses sistemas de arquivos especiais fornecem interfaces
+do kernel que não podem ser fornecidas com nós de dispositivo padrão.
+
+=============== ======== ==================================================
+/dev/pts        devpts   Sistema de arquivos de escravos PTY
+/dev/shm        tmpfs    Acesso de manutenção à memória compartilhada POSIX
+=============== ======== ==================================================
+
+Dispositivos de terminal
+------------------------
+
+Dispositivos de terminal, ou TTY, são uma classe especial de dispositivos de
+caractere. Um dispositivo de terminal é qualquer dispositivo que possa atuar
+como terminal de controle de uma sessão; isso inclui consoles virtuais,
+portas seriais e pseudoterminais (PTYs).
+
+Todos os dispositivos de terminal compartilham um conjunto comum de
+capacidades conhecidas como disciplinas de linha (line disciplines); estas
+incluem a disciplina de linha de terminal comum, bem como os modos SLIP e
+PPP.
+
+Todos os dispositivos de terminal são nomeados de forma semelhante; esta
+seção explica a nomenclatura e o uso dos vários tipos de TTY. Observe que as
+convenções de nomenclatura incluem várias verrugas históricas; algumas delas
+são específicas do Linux, algumas foram herdadas de outros sistemas, e
+algumas refletem o Linux tendo superado uma convenção emprestada.
+
+Um sinal de cerquilha (``#``) em um nome de dispositivo é usado aqui para
+indicar um número decimal sem zeros à esquerda.
+
+Consoles virtuais e o dispositivo de console
+++++++++++++++++++++++++++++++++++++++++++++
+
+Consoles virtuais são telas de terminal em tela cheia no monitor de vídeo do
+sistema. Consoles virtuais são nomeados ``/dev/tty#``, com a numeração
+começando em ``/dev/tty1``; o ``/dev/tty0`` é o console virtual atual.
+O ``/dev/tty0`` é o dispositivo que deve ser usado para acessar a placa de
+vídeo do sistema naquelas arquiteturas para as quais os dispositivos de
+frame buffer (``/dev/fb*``) não são aplicáveis. Não use o ``/dev/console``
+para esse fim.
+
+O dispositivo de console, ``/dev/console``, é o dispositivo para o qual as
+mensagens do sistema devem ser enviadas, e no qual os logins devem ser
+permitidos em modo monousuário. A partir do Linux 2.1.71, o ``/dev/console``
+é gerenciado pelo kernel; para versões anteriores, ele deve ser um link
+simbólico para o ``/dev/tty0``, para um console virtual específico como o
+``/dev/tty1``, ou para um dispositivo primário de porta serial (``tty*``,
+não ``cu*``), dependendo da configuração do sistema.
+
+Portas seriais
+++++++++++++++
+
+Portas seriais são portas seriais RS-232 e qualquer dispositivo que simule
+uma, seja em hardware (como modems internos) ou em software (como o driver
+ISDN). No Linux, cada porta serial possui dois nomes de dispositivo: o
+primário, ou de chamada de entrada (callin), e o alternativo, ou de chamada
+de saída (callout). Cada tipo de dispositivo é indicado por uma letra
+diferente. Para qualquer letra X, os nomes dos dispositivos são
+``/dev/ttyX#`` e ``/dev/cux#``, respectivamente; por razões históricas, o
+``/dev/ttyS#`` e o ``/dev/ttyC#`` correspondem ao ``/dev/cua#`` e ao
+``/dev/cub#``. No futuro, deve-se esperar que múltiplas letras sejam usadas;
+todas as letras serão maiúsculas para o dispositivo "tty" (por exemplo,
+``/dev/ttyDP#``) e minúsculas para o dispositivo "cu" (por exemplo,
+``/dev/cudp#``).
+
+Os nomes ``/dev/ttyQ#`` e ``/dev/cuq#`` são reservados para uso local.
+
+Os dispositivos alternativos provêem exclusão baseada no kernel e padrões um
+tanto diferentes dos dispositivos primários. Seu principal propósito é
+permitir o uso de portas seriais com programas sem suporte inerente a portas
+seriais, ou com suporte defeituoso. Seu uso é obsoleto, e eles podem ser
+removidos em uma versão futura do Linux.
+
+A arbitragem de portas seriais é provida pelo uso de arquivos de trava com
+os nomes ``/var/lock/LCK..ttyX#``. O conteúdo do arquivo de trava deve ser o
+PID do processo que está travando, como um número ASCII.
+
+É prática comum instalar links como /dev/modem, que apontam para portas
+seriais. Para garantir o travamento adequado na presença desses links,
+recomenda-se que o software persiga os links simbólicos e trave todos os
+nomes possíveis; adicionalmente, recomenda-se que um arquivo de trava seja
+instalado com o dispositivo alternativo correspondente. Para evitar
+impasses (deadlocks), recomenda-se que as travas sejam adquiridas na
+seguinte ordem, e liberadas na ordem inversa:
+
+        1. O nome do link simbólico, se houver (``/var/lock/LCK..modem``)
+        2. O nome "tty" (``/var/lock/LCK..ttyS2``)
+        3. O nome do dispositivo alternativo (``/var/lock/LCK..cua2``)
+
+No caso de links simbólicos aninhados, os arquivos de trava devem ser
+instalados na ordem em que os links simbólicos são resolvidos.
+
+Sob nenhuma circunstância uma aplicação deve manter uma trava enquanto
+espera que outra seja liberada. Além disso, aplicações que tentam criar
+arquivos de trava para os nomes de dispositivo alternativos correspondentes
+devem levar em conta a possibilidade de serem usadas em um TTY que não seja
+de porta serial, para o qual nenhum dispositivo alternativo existiria.
+
+Pseudoterminais (PTYs)
+++++++++++++++++++++++
+
+Pseudoterminais, ou PTYs, são usados para criar sessões de login ou para
+prover outras capacidades que exijam uma disciplina de linha TTY (incluindo
+capacidade de SLIP ou PPP) a processos arbitrários geradores de dados. Cada
+PTY tem um lado mestre, nomeado ``/dev/pty[p-za-e][0-9a-f]``, e um lado
+escravo, nomeado ``/dev/tty[p-za-e][0-9a-f]``. O kernel arbitra o uso dos
+PTYs permitindo que cada lado mestre seja aberto apenas uma vez.
+
+Uma vez que o lado mestre tenha sido aberto, o dispositivo escravo
+correspondente pode ser usado da mesma maneira que qualquer dispositivo TTY.
+Os dispositivos mestre e escravo são conectados pelo kernel, gerando o
+equivalente a um pipe bidirecional com capacidades de TTY.
+
+Versões recentes dos kernels Linux e da GNU libc contêm suporte ao esquema
+de nomenclatura System V/Unix98 para PTYs, que atribui um dispositivo comum,
+``/dev/ptmx``, a todos os mestres (abri-lo lhe dará automaticamente um PTY
+não atribuído anteriormente) e um subdiretório, ``/dev/pts``, para os
+escravos; os escravos são nomeados com inteiros decimais (``/dev/pts/#`` em
+nossa notação). Isso remove o problema de esgotar o espaço de nomes e
+permite que o kernel crie automaticamente os nós de dispositivo para os
+escravos sob demanda, usando o sistema de arquivos "devpts".
diff --git a/Documentation/translations/pt_BR/admin-guide/index.rst b/Documentation/translations/pt_BR/admin-guide/index.rst
new file mode 100644
index 000000000000..471b76f00e00
--- /dev/null
+++ b/Documentation/translations/pt_BR/admin-guide/index.rst
@@ -0,0 +1,190 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. raw:: latex
+
+	\renewcommand\thesection*
+	\renewcommand\thesubsection*
+
+==================================================
+Guia do usuário e do administrador do kernel Linux
+==================================================
+
+A seguir está uma coleção de documentos voltados ao usuário que foram
+adicionados ao kernel ao longo do tempo. Ainda há pouca ordem ou organização
+geral aqui --- este material não foi escrito para ser um documento único e
+coerente! Com sorte, as coisas melhorarão rapidamente com o tempo.
+
+Guias gerais para a administração do kernel
+-------------------------------------------
+
+Esta seção inicial contém informações gerais, incluindo o arquivo README que
+descreve o kernel como um todo, documentação sobre os parâmetros do kernel,
+etc.
+
+.. toctree::
+   :maxdepth: 1
+
+   README
+   devices
+
+Todolist:
+
+*   features
+
+Uma grande parte da interface administrativa do kernel são os sistemas de
+arquivos virtuais /proc e sysfs; estes documentos descrevem como interagir
+com eles.
+
+Todolist:
+
+*   sysfs-rules
+*   sysctl/index
+*   cputopology
+*   abi
+
+Documentação relacionada à segurança:
+
+Todolist:
+
+*   hw-vuln/index
+*   LSM/index
+*   perf-security
+
+Inicializando o kernel
+----------------------
+
+Todolist:
+
+*   bootconfig
+*   kernel-parameters
+*   efi-stub
+*   initrd
+
+Rastreando e identificando problemas
+------------------------------------
+
+Aqui está um conjunto de documentos voltados a usuários que estão tentando
+rastrear problemas e bugs em particular.
+
+Todolist:
+
+*   reporting-issues
+*   reporting-regressions
+*   quickly-build-trimmed-linux
+*   verify-bugs-and-bisect-regressions
+*   bug-hunting
+*   bug-bisect
+*   tainted-kernels
+*   ramoops
+*   dynamic-debug-howto
+*   init
+*   kdump/index
+*   perf/index
+*   pstore-blk
+*   clearing-warn-once
+*   kernel-per-CPU-kthreads
+*   lockup-watchdogs
+*   RAS/index
+*   sysrq
+
+Subsistemas centrais do kernel
+------------------------------
+
+Estes documentos descrevem interfaces de administração dos subsistemas
+centrais do kernel, que provavelmente são de interesse em quase qualquer
+sistema.
+
+Todolist:
+
+*   cgroup-v2
+*   cgroup-v1/index
+*   cpu-isolation
+*   cpu-load
+*   mm/index
+*   module-signing
+*   namespaces/index
+*   numastat
+*   pm/index
+*   syscall-user-dispatch
+
+Suporte a formatos binários não nativos. Observe que alguns destes
+documentos são ... antigos ...
+
+Todolist:
+
+*   binfmt-misc
+*   java
+*   mono
+
+Administração da camada de blocos e de sistemas de arquivos
+-----------------------------------------------------------
+
+Todolist:
+
+*   bcache
+*   binderfs
+*   blockdev/index
+*   cifs/index
+*   device-mapper/index
+*   ext4
+*   filesystem-monitoring
+*   nfs/index
+*   iostats
+*   jfs
+*   md
+*   ufs
+*   xfs
+
+Guias específicos de dispositivos
+---------------------------------
+
+Como configurar o seu hardware dentro do sistema Linux.
+
+Todolist:
+
+*   acpi/index
+*   aoe/index
+*   auxdisplay/index
+*   braille-console
+*   btmrvl
+*   dell_rbu
+*   edid
+*   gpio/index
+*   hw_random
+*   laptops/index
+*   lcd-panel-cgram
+*   media/index
+*   nvme-multipath
+*   parport
+*   pnp
+*   rapidio
+*   rtc
+*   serial-console
+*   svga
+*   thermal/index
+*   thunderbolt
+*   vga-softcursor
+*   video-output
+
+Análise de carga de trabalho
+----------------------------
+
+Este é o início de uma seção com informações de interesse para
+desenvolvedores de aplicações e integradores de sistemas que fazem análise
+do kernel Linux para aplicações críticas de segurança. Documentos que dão
+suporte à análise das interações do kernel com as aplicações, e às
+expectativas dos principais subsistemas do kernel, serão encontrados aqui.
+
+Todolist:
+
+*   workload-tracing
+
+Todo o resto
+------------
+
+Alguns documentos difíceis de categorizar e geralmente obsoletos.
+
+Todolist:
+
+*   ldm
+*   unicode
diff --git a/Documentation/translations/pt_BR/index.rst b/Documentation/translations/pt_BR/index.rst
index 462267e92f2f..5557c5e4e250 100644
--- a/Documentation/translations/pt_BR/index.rst
+++ b/Documentation/translations/pt_BR/index.rst
@@ -67,3 +67,13 @@ kernel e sobre como ver seu trabalho integrado.
    :maxdepth: 1
 
    process/index
+
+Guias do usuário e do administrador
+===================================
+
+Os guias para usuários e administradores do kernel Linux.
+
+.. toctree::
+   :maxdepth: 1
+
+   admin-guide/index
diff --git a/Documentation/translations/pt_BR/process/2.Process.rst b/Documentation/translations/pt_BR/process/2.Process.rst
index 5ff35f10aac7..0019b7404d33 100644
--- a/Documentation/translations/pt_BR/process/2.Process.rst
+++ b/Documentation/translations/pt_BR/process/2.Process.rst
@@ -75,16 +75,16 @@ Como exemplo, veja como ocorreu o ciclo de desenvolvimento da versão 5.4
 (todas as datas são de 2019):
 
 	==============  ===============================
-	Setembro 15	5.3 Lançamento estável do 5.3
+	Setembro 15	Lançamento estável do 5.3
 	Setembro 30	5.4-rc1, fechamento da janela de integração
 	Outubro 6	5.4-rc2
 	Outubro 13	5.4-rc3
 	Outubro 20	5.4-rc4
-	October 27	5.4-rc5
+	Outubro 27	5.4-rc5
 	Novembro 3	5.4-rc6
 	Novembro 10	5.4-rc7
 	Novembro 17	5.4-rc8
-	Novembro 24	5.4 Lançamento estável do 5.4
+	Novembro 24	Lançamento estável do 5.4
 	==============  ===============================
 
 Como os desenvolvedores decidem quando encerrar o ciclo de desenvolvimento
@@ -330,7 +330,7 @@ A árvore de fontes do kernel contém o diretório drivers/staging/, onde reside
 muitos subdiretórios para drivers ou sistemas de arquivos que estão a caminho
 de serem adicionados à árvore do kernel. Eles permanecem em drivers/staging/
 enquanto ainda precisam de mais trabalho; uma vez concluídos, podem ser movidos
-para o kernel proper Esta é uma maneira de acompanhar drivers que não estão à
+para o kernel propriamente dito. Esta é uma maneira de acompanhar drivers que não estão à
 altura dos padrões de codificação ou de qualidade do kernel Linux, mas que as
 pessoas podem querer usar e acompanhar o desenvolvimento.
 
@@ -433,7 +433,7 @@ Existem algumas dicas que podem ajudar na sobrevivência na lista linux-kernel:
   caixa de entrada principal. É preciso ser capaz de ignorar o fluxo de e-mails
   por períodos prolongados de tempo.
 
-- Não tente acompanhar cada conversa ninguém mais faz isso. É importante
+- Não tente acompanhar cada conversa, ninguém mais faz isso. É importante
   filtrar tanto pelo tópico de interesse (embora note que conversas longas
   podem se desviar do assunto original sem que a linha de assunto do e-mail
   seja alterada) quanto pelas pessoas que estão participando.
@@ -455,13 +455,13 @@ Existem algumas dicas que podem ajudar na sobrevivência na lista linux-kernel:
 - Use respostas intercaladas, o que torna sua resposta mais fácil
   de ler. (ou seja, evite o "top-posting" — a prática de colocar sua resposta
   acima do texto citado ao qual você está respondendo). Para mais detalhes, veja
-  :ref:`Documentation/process/submitting-patches.rst <interleaved_replies>`.
+  :ref:`Documentation/process/submitting-patches.rst <pt_BR_interleaved_replies>`.
 
 - Pergunte na lista de discussão correta. A lista linux-kernel pode até ser o
   ponto de encontro geral, mas não é o melhor lugar para encontrar desenvolvedores
   de todos os subsistemas.
 
-O último ponto, encontrar a lista de discussão correta  é um lugar comum
+O último ponto, encontrar a lista de discussão correta, é um lugar comum
 onde os desenvolvedores iniciantes costumam errar. Alguém que faça uma pergunta
 relacionada a redes na lista linux-kernel quase certamente receberá uma
 sugestão educada para perguntar na lista netdev em seu lugar, já que essa é a
diff --git a/Documentation/translations/pt_BR/process/3.Early-stage.rst b/Documentation/translations/pt_BR/process/3.Early-stage.rst
index 74e741766b46..86c228353084 100644
--- a/Documentation/translations/pt_BR/process/3.Early-stage.rst
+++ b/Documentation/translations/pt_BR/process/3.Early-stage.rst
@@ -74,7 +74,7 @@ Discussão inicial
 
 Ao planejar um projeto de desenvolvimento do kernel, faz todo o sentido realizar
 discussões com a comunidade antes de iniciar a implementação. A comunicação
-inicial pode economizar tempo e problemas de várias maneiras:number of ways:
+inicial pode economizar tempo e problemas de várias maneiras:
 
  - Pode muito bem ser que o problema já seja tratado pelo kernel de maneiras
    que você não compreendeu. O kernel Linux é grande e possui uma série de
@@ -121,8 +121,8 @@ comunidade do kernel. Alguns exemplos incluem:
    consideradas inseguras e não confiáveis. Essa preocupação (entre outras)
    manteve o AppArmor fora do kernel principal (*mainline*) por anos.
 
-In each of these cases, a great deal of pain and extra work could have been
-avoided with some early discussion with the kernel developers.
+Em cada um desses casos, muito sofrimento e trabalho extra poderiam ter sido
+evitados com alguma discussão inicial com os desenvolvedores do kernel.
 
 
 Como encontrar os mantenedores?
@@ -200,8 +200,8 @@ prosseguir, mantendo a comunidade informada à medida que avança.
 Obter a aprovação oficial
 -------------------------
 
-Se o seu trabalho estiver sendo realizado em um ambiente corporativo  como é o
-caso da maior parte do trabalho no kernel do Linux —, você deve, obviamente, ter
+Se o seu trabalho estiver sendo realizado em um ambiente corporativo, como é o
+caso da maior parte do trabalho no kernel do Linux, você deve, obviamente, ter
 a permissão de gerentes devidamente autorizados antes de poder publicar os
 planos ou o código da sua empresa em uma lista de discussão pública.
 A publicação de código que não tenha sido liberado para lançamento sob uma
diff --git a/Documentation/translations/pt_BR/process/4.Coding.rst b/Documentation/translations/pt_BR/process/4.Coding.rst
index ca4c74774a91..7c7567165725 100644
--- a/Documentation/translations/pt_BR/process/4.Coding.rst
+++ b/Documentation/translations/pt_BR/process/4.Coding.rst
@@ -197,8 +197,8 @@ a ferramenta certa para o trabalho. Códigos que mostrem falta de atenção à
 concorrência terão um caminho difícil para entrar no mainline.
 
 
-Regressions
-***********
+Regressões
+**********
 
 Um perigo final que vale a pena mencionar é este: pode ser tentador fazer uma
 alteração (que pode trazer grandes melhorias) que faça algo quebrar para os
@@ -258,7 +258,7 @@ Note que nem todos os avisos do compilador ficam ativados por padrão. Compile o
 kernel com "make KCFLAGS=-W" para obter o conjunto completo.
 
 O kernel fornece várias opções de configuração que ativam recursos de
-depuração; a maioria delas é encontrada no submanu "kernel hacking". Várias
+depuração; a maioria delas é encontrada no submenu "kernel hacking". Várias
 dessas opções devem ser ativadas para qualquer kernel usado para fins de
 desenvolvimento ou teste. Em particular, você deve ativar:
 
diff --git a/Documentation/translations/pt_BR/process/5.Posting.rst b/Documentation/translations/pt_BR/process/5.Posting.rst
index 820a56b661db..2ac7e5557805 100644
--- a/Documentation/translations/pt_BR/process/5.Posting.rst
+++ b/Documentation/translations/pt_BR/process/5.Posting.rst
@@ -37,7 +37,7 @@ Antes de criar patches
 ----------------------
 
 Há uma série de coisas que devem ser feitas antes de você considerar o envio
-de patches para la comunidade de desenvolvimento. Elas incluem:
+de patches para a comunidade de desenvolvimento. Elas incluem:
 
  - Teste o código tanto quanto puder. Faça uso das ferramentas de depuração
    do kernel, garanta que o kernel seja compilado com todas as combinações
@@ -106,7 +106,7 @@ que podem ajudar consideravelmente:
 
  - Como uma forma de reafirmar a diretriz acima: não misture diferentes tipos de
    alterações no mesmo patch. Se um único patch corrige uma falha crítica de
-   segurança, reorganiza algumas estruturas e reformatará o código, há uma grande
+   segurança, reorganiza algumas estruturas e reformata o código, há uma grande
    chance de que ele seja ignorado e a correção importante seja perdida.
 
  - Cada patch deve resultar em um kernel que compile e funcione corretamente; se
@@ -199,7 +199,7 @@ a alteração em um sistema de controle de versão. Ele será seguido por:
    diff associará os nomes das funções às alterações, tornando o patch resultante
    mais fácil de ser lido por outras pessoas.
 
-As tags  já mencionadas brevemente acima são usados para fornecer
+Os marcadores (tags) já mencionados brevemente acima são usados para fornecer
 informações sobre como o patch surgiu. Eles são descritos em detalhes no
 documento :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`;
 o que se segue aqui é um breve resumo.
@@ -215,7 +215,7 @@ documento com uma especificação implementada pelo patch::
 
   Link: https://example.com/somewhere.html  optional-other-stuff
 
-De acordo com as orientações do Pinguim-Chefe, um marcador Link
+De acordo com as orientações do Pinguim-Chefe, um marcador Link:
 só deve ser adicionado a um commit se ele levar a informações úteis que não
 são encontradas no próprio commit.
 
@@ -279,7 +279,7 @@ Os marcadores de uso comum são:
 
 Tenha cuidado ao adicionar os marcadores mencionados acima aos seus patches, pois
 todos, exceto Cc:, Reported-by: e Suggested-by:, precisam de permissão explícita
-fontes da pessoa nomeada. Para esses três, a permissão implícita é suficiente se
+da pessoa nomeada. Para esses três, a permissão implícita é suficiente se
 a pessoa contribuiu para o kernel Linux usando esse nome e endereço de e-mail de
 acordo com os arquivos do lore ou o histórico de commits — e, no caso de
 Reported-by: e Suggested-by:, se fizeram o relato ou a sugestão publicamente.
@@ -322,7 +322,7 @@ kernel incentiva as pessoas a pecarem pelo excesso, enviando cópias demais; nã
 assuma que as pessoas relevantes verão sua publicação nas listas de discussão. Em
 particular, as cópias devem ir para:
 
-- O(s) mantenedor(es) do(s) subsistema(s) afetado(s). Como descrito antes, o
+ - O(s) mantenedor(es) do(s) subsistema(s) afetado(s). Como descrito antes, o
    arquivo MAINTAINERS é o primeiro lugar para procurar por essas pessoas.
 
  - Outros desenvolvedores que estiveram trabalhando na mesma área — especialmente
diff --git a/Documentation/translations/pt_BR/process/6.Followthrough.rst b/Documentation/translations/pt_BR/process/6.Followthrough.rst
index d6bdaa2cb8a4..dbdf479bb063 100644
--- a/Documentation/translations/pt_BR/process/6.Followthrough.rst
+++ b/Documentation/translations/pt_BR/process/6.Followthrough.rst
@@ -58,7 +58,17 @@ fácil se você mantiver algumas coisas em mente:
   de codificação e pedidos para refatorar parte do seu código em seções
   compartilhadas do kernel. Uma das funções dos mantenedores é manter as coisas
   com a mesma aparência. Às vezes, isso significa que aquele truque inteligente
-  (*clever hack*) em seu driver para contornar um problema
+  (*clever hack*) em seu driver para contornar um problema na verdade precisa
+  se tornar um recurso generalizado do kernel, pronto para a próxima vez.
+
+O que tudo isso significa é que, quando os revisores lhe enviam comentários,
+você precisa prestar atenção às observações técnicas que eles estão fazendo.
+Não deixe que a forma como eles se expressam, ou o seu próprio orgulho, impeçam
+que isso aconteça. Quando você receber comentários de revisão em um patch,
+reserve um tempo para entender o que o revisor está tentando dizer. Se
+possível, corrija as coisas que o revisor está pedindo para você corrigir. E
+responda ao revisor: agradeça-o e descreva como você responderá às suas
+perguntas.
 
 Note que você não precisa concordar com todas as mudanças sugeridas pelos
 revisores. Se você acredita que o revisor entendeu mal o seu código, explique
@@ -67,7 +77,7 @@ sugerida, descreva-a e justifique a sua solução para o problema. Se as suas
 explicações fizerem sentido, o revisor as aceitará. Contudo, caso a sua
 explicação não seja persuasiva — especialmente se outros começarem a concordar
 com o revisor —, reserve um tempo para repensar as coisas. Pode ser fácil ficar
-ceguificado por sua própria solução para um problema, a ponto de não perceber
+cego por sua própria solução para um problema, a ponto de não perceber
 que algo está fundamentalmente errado ou que, talvez, você não esteja sequer
 resolvendo o problema certo.
 
diff --git a/Documentation/translations/pt_BR/process/8.Conclusion.rst b/Documentation/translations/pt_BR/process/8.Conclusion.rst
index d5af31e7c4d9..2696ea16756e 100644
--- a/Documentation/translations/pt_BR/process/8.Conclusion.rst
+++ b/Documentation/translations/pt_BR/process/8.Conclusion.rst
@@ -21,6 +21,7 @@ encontradas através do índice do kernel do LWN em:
 	https://lwn.net/Kernel/Index/
 
 Além disso, um recurso valioso para os desenvolvedores do kernel é:
+
 	https://kernelnewbies.org/
 
 E, claro, não se deve esquecer o https://kernel.org/, o local definitivo
@@ -29,7 +30,7 @@ para informações sobre os lançamentos do kernel.
 Há uma série de livros sobre o desenvolvimento do kernel:
 
 	Linux Device Drivers, 3rd Edition (Jonathan Corbet, Alessandro
-	Rubini, and Greg Kroah-Hartman).  Online at
+	Rubini, e Greg Kroah-Hartman). Disponível online em
 	https://lwn.net/Kernel/LDD3/.
 
 	Linux Kernel Development (Robert Love).
diff --git a/Documentation/translations/pt_BR/process/adding-syscalls.rst b/Documentation/translations/pt_BR/process/adding-syscalls.rst
index cdf8b5033765..99607ee5f949 100644
--- a/Documentation/translations/pt_BR/process/adding-syscalls.rst
+++ b/Documentation/translations/pt_BR/process/adding-syscalls.rst
@@ -7,7 +7,7 @@ Adicionando uma Nova Chamada de Sistema
 Este documento descreve o que está envolvido na adição de uma nova chamada de
 sistema (system call) ao kernel Linux, indo além dos conselhos normais de
 submissão em
-:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`.
+:ref:`Documentation/translations/pt_BR/process/submitting-patches.rst <pt_BR_submittingpatches>`.
 
 
 Alternativas às Chamadas de Sistema
@@ -122,10 +122,10 @@ como o handle (identificador) para esse objeto -- não invente um novo tipo de
 handle de objeto para o espaço do usuário quando o kernel já possui mecanismos
 e semânticas bem definidas para o uso de descritores de arquivo.
 
-Se a sua nova chamada de sistema (2) de fato retornar un novo descritor de
+Se a sua nova chamada de sistema xyzzy(2) de fato retornar um novo descritor de
 arquivo, então o argumento de flags deve incluir um valor que seja equivalente
 a definir ``O_CLOEXEC`` no novo FD. Isso torna possível para o espaço do usuário
-fechar a janela de tempo entre a chamada ``()`` e a execução de
+fechar a janela de tempo entre a chamada ``xyzzy()`` e a execução de
 ``fcntl(fd, F_SETFD, FD_CLOEXEC)``, onde um ``fork()`` e ``execve()`` inesperados
 em outra thread poderiam vazar um descritor para o programa executado. (Contudo,
 resista à tentação de reutilizar o valor real da constante ``O_CLOEXEC``, pois
@@ -138,7 +138,7 @@ deve considerar o que significa usar a família de chamadas de sistema
 pronto para leitura ou escrita é a maneira normal de o kernel indicar ao espaço
 do usuário que um evento ocorreu no objeto correspondente do kernel.
 
-Se a sua nova chamada de sistema (2) envolver um argumento de nome de arquivo
+Se a sua nova chamada de sistema xyzzy(2) envolver um argumento de nome de arquivo
 (filename)::
 
     int sys_xyzzy(const char __user *path, ..., unsigned int flags);
@@ -152,18 +152,18 @@ o arquivo em questão; em particular, permite que o espaço do usuário solicite
 funcionalidade para um descritor de arquivo já aberto usando a flag
 ``AT_EMPTY_PATH``, fornecendo efetivamente uma operação fxyzzy(3) de graça::
 
- - xyzzyat(AT_FDCWD, path, ..., 0) é equivalente a (path,...)
+ - xyzzyat(AT_FDCWD, path, ..., 0) é equivalente a xyzzy(path,...)
  - xyzzyat(fd, "", ..., AT_EMPTY_PATH) é equivalente a fxyzzy(fd, ...)
 
 (Para mais detalhes sobre a justificativa das chamadas \*at(), veja a página de
 manual :manpage:`openat(2)`; para um exemplo de AT_EMPTY_PATH, veja a página de
 manual :manpage:`fstatat(2)`.)
 
-Se a sua nova chamada de sistema (2) envolver um parâmetro que descreve um
+Se a sua nova chamada de sistema xyzzy(2) envolver um parâmetro que descreve um
 deslocamento (offset) dentro de um arquivo, mude o seu tipo para ``loff_t`` para
 que offsets de 64 bits possam ser suportados mesmo em arquiteturas de 32 bits.
 
-Se a sua nova chamada de sistema (2) envolver funcionalidades privilegiadas,
+Se a sua nova chamada de sistema xyzzy(2) envolver funcionalidades privilegiadas,
 ela precisa ser governada pelo bit de capacidade (capability) do Linux apropriado
 (verificado com uma chamada a ``capable()``), conforme descrito na página de
 manual :manpage:`capabilities(7)`. Escolha um bit de capacidade existente que governe
@@ -172,7 +172,7 @@ apenas uma vaga relação sob o mesmo bit, pois isso vai contra o propósito das
 capabilities de dividir o poder do root. Em particular, evite adicionar novos
 usos para a capacidade ``CAP_SYS_ADMIN``, que já é excessivamente generalista.
 
-Se a sua nova chamada de sistema (2) manipular um processo diferente do
+Se a sua nova chamada de sistema xyzzy(2) manipular um processo diferente do
 processo que a chamou, ela deve ser restrita (usando uma chamada a
 ``ptrace_may_access()``) para que apenas um processo chamador com as mesmas
 permissões do processo alvo, ou com as capacidades necessárias, possa manipular
@@ -211,7 +211,7 @@ kernel, devem sempre ser enviadas com cópia (cc'ed) para linux-api@vger.kernel.
 Implementação Genérica de Chamadas de Sistema
 ---------------------------------------------
 
-O ponto de entrada principal para a sua nova chamada de sistema (2) será chamado
+O ponto de entrada principal para a sua nova chamada de sistema xyzzy(2) será chamado
 de ``sys_xyzzy()``, mas você deve adicionar esse ponto de entrada com a macro
 ``SYSCALL_DEFINEn()`` apropriada, em vez de fazer isso explicitamente. O 'n'
 indica o número de argumentos da chamada de sistema, e a macro recebe o nome da
@@ -242,7 +242,7 @@ O arquivo ``kernel/sys_ni.c`` fornece uma implementação de stub de fallback pa
 cada chamada de sistema, retornando ``-ENOSYS``. Adicione a sua nova chamada de
 sistema aqui também::
 
-    COND_SYSCALL(sys_xyzzy);
+    COND_SYSCALL(xyzzy);
 
 A sua nova funcionalidade de kernel, e a chamada de sistema que a controla, deve
 normalmente ser opcional, portanto adicione uma opção ``CONFIG`` (tipicamente em
@@ -259,7 +259,7 @@ normalmente ser opcional, portanto adicione uma opção ``CONFIG`` (tipicamente
 Para resumir, você precisa de um commit que inclua:
 
  - Opção ``CONFIG`` para a nova função, normalmente em ``init/Kconfig``
- - ``SYSCALL_DEFINEn(, ...)`` para o ponto de entrada
+ - ``SYSCALL_DEFINEn(xyzzy, ...)`` para o ponto de entrada
  - Protótipo correspondente em ``include/linux/syscalls.h``
  - Entrada na tabela genérica em ``include/uapi/asm-generic/unistd.h``
  - Stub de fallback em ``kernel/sys_ni.c``
@@ -289,7 +289,7 @@ ajustar ``arch/*/kernel/Makefile.syscalls``.
 Como o ``scripts/syscall.tbl`` serve como uma tabela de syscall comum para
 múltiplas arquiteturas, uma nova entrada é necessária nesta tabela::
 
-    468   common        sys_xyzzy
+    468   common   xyzzy     sys_xyzzy
 
 Note que adicionar uma entrada ao ``scripts/syscall.tbl`` com a ABI "common"
 também afeta todas as arquiteturas que compartilham essa tabela. Para alterações
@@ -304,7 +304,7 @@ correspondentes também devem ser feitas em ``arch/*/kernel/Makefile.syscalls``:
 Para resumir, você precisa de um commit que inclua:
 
  - Opção ``CONFIG`` para a nova função, normalmente em ``init/Kconfig``
- - ``SYSCALL_DEFINEn(, ...)`` para o ponto de entrada
+ - ``SYSCALL_DEFINEn(xyzzy, ...)`` para o ponto de entrada
  - Protótipo correspondente em ``include/linux/syscalls.h``
  - Nova entrada em ``scripts/syscall.tbl``
  - (Se necessário) Atualizações de Makefile em ``arch/*/kernel/Makefile.syscalls``
@@ -320,11 +320,11 @@ de sistema não seja especial de alguma forma (veja abaixo), isso envolve uma
 entrada "common" (para x86_64 e x32) em
 ``arch/x86/entry/syscalls/syscall_64.tbl``::
 
-    333   common        sys_xyzzy
+    333   common   xyzzy     sys_xyzzy
 
 e uma entrada "i386" em ``arch/x86/entry/syscalls/syscall_32.tbl``::
 
-    380   i386          sys_xyzzy
+    380   i386     xyzzy     sys_xyzzy
 
 Novamente, esses números estão sujeitos a alterações caso ocorram conflitos na
 janela de mesclagem (merge window) relevante.
@@ -414,7 +414,7 @@ a versão compat; a entrada em ``include/uapi/asm-generic/unistd.h`` deve usar
 
 Para resumir, você precisa de:
 
- - uma macro ``COMPAT_SYSCALL_DEFINEn(, ...)`` para o ponto de entrada compat
+ - uma macro ``COMPAT_SYSCALL_DEFINEn(xyzzy, ...)`` para o ponto de entrada compat
  - protótipo correspondente em ``include/linux/compat.h``
  - (se necessário) struct de mapeamento de 32 bits em ``include/linux/compat.h``
  - instância de ``__SC_COMP``, e não de ``__SYSCALL``, em
@@ -433,11 +433,11 @@ Você precisa estender a entrada em ``scripts/syscall.tbl`` com uma coluna extra
 para indicar que um programa de espaço do usuário de 32 bits rodando em um
 kernel de 64 bits deve atingir o ponto de entrada compat::
 
-    468   common          sys_xyzzy    compat_sys_xyzzy
+    468   common     xyzzy     sys_xyzzy    compat_sys_xyzzy
 
 Para resumir, você precisa de:
 
- - ``COMPAT_SYSCALL_DEFINEn(, ...)`` para o ponto de entrada compat
+ - ``COMPAT_SYSCALL_DEFINEn(xyzzy, ...)`` para o ponto de entrada compat
  - Protótipo correspondente em ``include/linux/compat.h``
  - Modificação da entrada em ``scripts/syscall.tbl`` para incluir uma coluna
    "compat" extra
@@ -454,7 +454,7 @@ compatibilidade voltadas para o espaço do usuário de 32 bits (AArch32):
 ``arch/arm64/tools/syscall_32.tbl``. Você precisa adicionar uma linha adicional
 a esta tabela especificando o ponto de entrada compat::
 
-    468   common          sys_xyzzy    compat_sys_xyzzy
+    468   common     xyzzy     sys_xyzzy    compat_sys_xyzzy
 
 
 Chamadas de Sistema de Compatibilidade (x86)
@@ -467,7 +467,7 @@ Primeiro, a entrada em ``arch/x86/entry/syscalls/syscall_32.tbl`` ganha uma
 coluna extra para indicar que um programa de espaço do usuário de 32 bits rodando
 em um kernel de 64 bits deve atingir o ponto de entrada compat::
 
-    380   i386          sys_xyzzy    __ia32_compat_sys_xyzzy
+    380   i386     xyzzy     sys_xyzzy    __ia32_compat_sys_xyzzy
 
 Segundo, você precisa definir o que deve acontecer para a versão da ABI x32 da
 nova chamada de sistema. Há uma escolha aqui: o layout dos argumentos deve
@@ -479,9 +479,9 @@ corresponder à versão de 32 bits, e a entrada em
 ``arch/x86/entry/syscalls/syscall_64.tbl`` é dividida para que os programas x32
 atinjam o wrapper de compatibilidade::
 
-    333   64            sys_xyzzy
+    333   64       xyzzy     sys_xyzzy
     ...
-    555   x32           __x32_compat_sys_xyzzy
+    555   x32      xyzzy     __x32_compat_sys_xyzzy
 
 Se não houver ponteiros envolvidos, então é preferível reutilizar a chamada de
 sistema de 64 bits para a ABI x32 (e, consequentemente, a entrada em
@@ -518,14 +518,14 @@ Para x86_64, isso é implementado como um ponto de entrada ``stub_xyzzy`` em
 ``arch/x86/entry/entry_64.S``, e a entrada correspondente na tabela de syscalls
 (``arch/x86/entry/syscalls/syscall_64.tbl``) é ajustada para refletir::
 
-    333   common        stub_xyzzy
+    333   common   xyzzy     stub_xyzzy
 
 O equivalente para programas de 32 bits executados em um kernel de 64 bits é
 normalmente chamado de ``stub32_xyzzy`` e implementado em
 ``arch/x86/entry/entry_64_compat.S``, com o respectivo ajuste na tabela de
 syscalls em ``arch/x86/entry/syscalls/syscall_32.tbl``::
 
-    380   i386          sys_xyzzy    stub32_xyzzy
+    380   i386     xyzzy     sys_xyzzy    stub32_xyzzy
 
 Se a chamada de sistema precisar de uma camada de compatibilidade (como na
 seção anterior), a versão ``stub32_`` precisará chamar a versão
@@ -579,12 +579,16 @@ espaço do usuário, o cabeçalho correspondente precisará ser instalado para
 compilar o teste.
 
 Certifique-se de que o autoteste seja executado com sucesso em todas as
-arquiteturas suportadas. Por exemplo, verifique se ele funciona quando compitado
+arquiteturas suportadas. Por exemplo, verifique se ele funciona quando compilado
 como um programa ABI x86_64 (-m64), x86_32 (-m32) e x32 (-mx32).
 
 Para testes mais extensos e minuciosos de novas funcionalidades, você também
 deve considerar a adição de testes ao Linux Test Project ou ao projeto
-xfstests para alterações relacionadas
+xfstests para alterações relacionadas a sistemas de arquivos.
+
+ - https://linux-test-project.github.io/
+ - git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
+
 
 Página de Manual (Man Page)
 ---------------------------
diff --git a/Documentation/translations/pt_BR/process/applying-patches.rst b/Documentation/translations/pt_BR/process/applying-patches.rst
index 313401bc2335..143603b991f7 100644
--- a/Documentation/translations/pt_BR/process/applying-patches.rst
+++ b/Documentation/translations/pt_BR/process/applying-patches.rst
@@ -1,5 +1,7 @@
 .. SPDX-License-Identifier: GPL-2.0
 
+.. _pt_BR_applying_patches:
+
 Aplicando Patches ao Kernel Linux
 +++++++++++++++++++++++++++++++++
 
@@ -12,7 +14,7 @@ Autor Original:
    manualmente, você quase certamente desejará considerar o uso do Git.
 
 Uma pergunta feita com frequência na Linux Kernel Mailing List é como aplicar
-an patch ao kernel ou, mais especificamente, a qual kernel base um patch para
+um patch ao kernel ou, mais especificamente, a qual kernel base um patch para
 uma das muitas árvores/branches deve ser aplicado. Esperamos que este documento
 explique isso a você.
 
@@ -171,7 +173,7 @@ fazer a alteração para fazê-la caber).
 O arquivo resultante pode ou não estar correto, dependendo do motivo pelo qual o
 arquivo estava diferente do esperado.
 
-Isso geralmente acontece se você tentar aplicar un patch que foi gerado contra uma
+Isso geralmente acontece se você tentar aplicar um patch que foi gerado contra uma
 versão de kernel diferente daquela que você está tentando modificar.
 
 Se você receber uma mensagem como ``Hunk #3 FAILED at 2387.``, significa que o
diff --git a/Documentation/translations/pt_BR/process/backporting.rst b/Documentation/translations/pt_BR/process/backporting.rst
index ce3f9fb4fc5b..afcff7085700 100644
--- a/Documentation/translations/pt_BR/process/backporting.rst
+++ b/Documentation/translations/pt_BR/process/backporting.rst
@@ -357,7 +357,7 @@ Processo de resolução
 ~~~~~~~~~~~~~~~~~~~~~
 
 Às vezes, a coisa mais fácil a fazer é apenas remover tudo, exceto a primeira
-parteda do conflito, deixando o arquivo essencialmente inalterado, e aplicar
+parte do conflito, deixando o arquivo essencialmente inalterado, e aplicar
 as alterações manualmente. Talvez o patch esteja alterando um argumento de
 chamada de função de ``0`` para ``1``, enquanto uma alteração conflitante
 adicionou um parâmetro totalmente novo (e insignificante) ao final da lista de
@@ -403,7 +403,7 @@ de volta (``git mv`` e commitando novamente) e, finalmente, esmagar (squash) o
 resultado usando ``git rebase -i`` (veja o `tutorial de rebase`_) para que ele
 apareça como um único commit quando você terminar.
 
-.. _tutorial de rebase: [https://medium.com/@slamflipstrom/a-beginners-guide-to-squashing-commits-with-git-rebase-8185cf6e62ec](https://medium.com/@slamflipstrom/a-beginners-guide-to-squashing-commits-with-git-rebase-8185cf6e62ec)
+.. _tutorial de rebase: https://medium.com/@slamflipstrom/a-beginners-guide-to-squashing-commits-with-git-rebase-8185cf6e62ec
 
 Pegadinhas
 ----------
diff --git a/Documentation/translations/pt_BR/process/code-of-conduct-interpretation.rst b/Documentation/translations/pt_BR/process/code-of-conduct-interpretation.rst
index 866c9f7e7a12..c40886e3d3ce 100644
--- a/Documentation/translations/pt_BR/process/code-of-conduct-interpretation.rst
+++ b/Documentation/translations/pt_BR/process/code-of-conduct-interpretation.rst
@@ -1,5 +1,7 @@
 .. SPDX-License-Identifier: GPL-2.0
 
+.. _pt_BR_code_of_conduct_interpretation:
+
 Interpretação do Código de Conduta do Kernel Linux
 ==================================================
 
diff --git a/Documentation/translations/pt_BR/process/code-of-conduct.rst b/Documentation/translations/pt_BR/process/code-of-conduct.rst
index 1ab171bf21cf..8a3da70b7e6b 100644
--- a/Documentation/translations/pt_BR/process/code-of-conduct.rst
+++ b/Documentation/translations/pt_BR/process/code-of-conduct.rst
@@ -84,5 +84,5 @@ disponível em https://www.contributor-covenant.org/version/1/4/code-of-conduct.
 Interpretação
 =============
 
-Consulte o documento :ref:`code_of_conduct_interpretation` para entender como a
-comunidade do kernel Linux interpretará este documento.
+Consulte o documento :ref:`pt_BR_code_of_conduct_interpretation` para
+entender como a comunidade do kernel Linux interpretará este documento.
diff --git a/Documentation/translations/pt_BR/process/coding-assistants.rst b/Documentation/translations/pt_BR/process/coding-assistants.rst
new file mode 100644
index 000000000000..2055af34a908
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/coding-assistants.rst
@@ -0,0 +1,60 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+IA Assistente de código
++++++++++++++++++++++++
+
+Esta documentação fornece um guia para ferramentas de IA e desenvolvedores que
+usam IA como assistente para contribuir para o kernel do Linux.
+
+Ferramentas de IA que ajudam desenvolvedores do Linux kernel devem seguir os
+padrões de desenvolvimento do kernel:
+
+* Documentation/process/development-process.rst
+* Documentation/process/coding-style.rst
+* Documentation/process/submitting-patches.rst
+
+Para guias e conteúdo sobre códigos gerados por assistentes de IA veja:
+
+* Documentation/process/generated-content.rst
+
+Licenças e Requisitos Legais
+============================
+
+Todas as contribuições devem estar de acordo com os requisitos de licença do
+kernel:
+
+* Todo código deve ser compatível apenas com GPL-2.0
+* Use identificadores SPDX de licença apropriados
+* Veja Documentation/process/license-rules.rst para mais detalhes
+
+Assinatura e certificado de origem do desenvolvedor
+===================================================
+
+Agentes de IA NÃO DEVEM adicionar tags Signed-off-by. Apenas pessoas
+podem legalmente certificar o Certificado de Origem do Desenvolvedor (DCO).
+A pessoa que envia é responsável por:
+
+* Revisar todo código gerado por IA
+* Garantir conformidade com os requisitos de licença
+* Acrescentar sua própria tag Signed-off-by para certificar o DCO
+* Assumir toda responsabilidade pela contribuição
+
+Atribuições
+===========
+
+Quando ferramentas de IA contribuírem para o desenvolvimento do kernel,
+a atribuição adequada ajuda a rastrear a função da IA no processo de
+desenvolvimento. Contribuições devem incluir a tag de assistência seguindo este
+formato::
+
+    Assisted-by: LLM [FERRAMENTA1] [FERRAMENTA2]
+
+* ``[FERRAMENTA1] [FERRAMENTA2]`` são ferramentas de análise especializada
+    opcionais (Exemplo: coccinelle, sparse, smatch, clang-tidy)
+
+Ferramentas básicas de desenvolvimento (git, gcc, make, editors) não são
+listadas.
+
+Exemplo::
+
+  Assisted-by: LLM coccinelle sparse
\ No newline at end of file
diff --git a/Documentation/translations/pt_BR/process/coding-style.rst b/Documentation/translations/pt_BR/process/coding-style.rst
new file mode 100644
index 000000000000..ac9bf0a716bc
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/coding-style.rst
@@ -0,0 +1,1320 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _pt_BR_codingstyle:
+
+Estilo de codificação do kernel Linux
+=====================================
+
+Este é um breve documento descrevendo o estilo de codificação preferido
+para o kernel Linux. O estilo de codificação é muito pessoal, e eu não
+**forçarei** minhas opiniões a ninguém, mas isso é o que vale para tudo
+que eu tenha que manter, e eu preferiria isso para a maioria das outras
+coisas também. Por favor, considere pelo menos os pontos aqui apresentados.
+
+Primeiramente, eu sugiro imprimir uma cópia dos padrões de codificação do GNU,
+e NÃO lê-la. Queime-as, é um grande gesto simbólico.
+
+De qualquer forma, aqui vai:
+
+
+1) Indentação
+-------------
+
+As tabulações têm 8 caracteres, e portanto as indentações também têm 8
+caracteres. Há movimentos heréticos que tentam fazer com que as indentações
+tenham 4 (ou até 2!) caracteres de profundidade, e isso é semelhante a
+tentar definir o valor de PI como 3.
+
+Justificativa: A ideia central da indentação é definir claramente onde um
+bloco de controle começa e termina. Especialmente quando você esteve olhando
+para a tela por 20 horas seguidas, você vai achar muito mais fácil ver como
+a indentação funciona se ela for mais ampla.
+
+Agora, algumas pessoas afirmarão que ter indentações de 8 caracteres faz
+o código se deslocar demais para a direita e dificultam a leitura em um
+terminal de 80 caracteres. A resposta é que, se você precisar de mais de 3
+níveis de indentação, você já está em apuros de qualquer forma, e deve
+corrigir seu programa.
+
+Em resumo, indentações de 8 caracteres deixam as coisas mais fáceis de ler, e
+têm o benefício adicional de avisar quando você está aninhando suas funções
+em excesso. Atenda a esse aviso.
+
+A maneira preferida de aliviar vários níveis de indentação em uma instrução
+``switch`` é alinhar o ``switch`` e seus rótulos subordinados ``case`` na
+mesma coluna, em vez de indentar duplamente os rótulos ``case``. Por exemplo:
+
+.. code-block:: c
+
+	switch (suffix) {
+	case 'G':
+	case 'g':
+		mem <<= 30;
+		break;
+	case 'M':
+	case 'm':
+		mem <<= 20;
+		break;
+	case 'K':
+	case 'k':
+		mem <<= 10;
+		fallthrough;
+	default:
+		break;
+	}
+
+Não coloque múltiplas instruções em uma única linha, a menos que você tenha
+algo para esconder:
+
+.. code-block:: c
+
+	if (condition) do_this;
+	  do_something_everytime;
+
+Não use vírgulas para evitar usar chaves:
+
+.. code-block:: c
+
+	if (condition)
+		do_this(), do_that();
+
+Sempre use chaves para múltiplas instruções:
+
+.. code-block:: c
+
+	if (condition) {
+		do_this();
+		do_that();
+	}
+
+Também não coloque múltiplas atribuições em uma única linha. O estilo de
+codificação do kernel é extremamente simples. Evite expressões complicadas.
+
+
+Fora de comentários, documentação e, exceto em Kconfig, espaços nunca são
+usados para indentação, e o exemplo acima foi deliberadamente quebrado.
+
+Obtenha um editor decente e não deixe espaços em branco no final das linhas.
+
+
+2) Quebrando linhas longas e strings
+------------------------------------
+
+O estilo de codificação trata principalmente da legibilidade e da
+manutenibilidade usando ferramentas comumente disponíveis.
+
+O limite preferido para o comprimento de uma única linha é de 80 colunas.
+
+Instruções com mais de 80 colunas devem ser quebradas em partes sensatas,
+a menos que exceder 80 colunas aumente significativamente a legibilidade e
+não esconda informações.
+
+Os descendentes são sempre substancialmente mais curtos do que o pai e são
+colocados substancialmente à direita. Um estilo muito usado é alinhar os
+descendentes ao parêntese de abertura de uma função.
+
+Essas mesmas regras são aplicadas aos cabeçalhos de função com uma lista de
+argumentos longa.
+
+No entanto, nunca quebre strings visíveis ao usuário, como mensagens
+``printk``, porque isso prejudica a capacidade de fazer ``grep`` nelas.
+
+
+3) Posicionamento de chaves e espaços
+-------------------------------------
+
+A outra questão que sempre surge no estilo em C é o posicionamento das
+chaves. Ao contrário do tamanho da indentação, há poucos motivos técnicos
+para escolher uma estratégia de posicionamento em vez de outra, mas a forma
+preferida, como nos mostraram os profetas Kernighan e Ritchie, é colocar a
+chave de abertura no final da linha e a chave de fechamento no início, assim:
+
+.. code-block:: c
+
+	if (x is true) {
+		we do y
+	}
+
+Isso se aplica a todos os blocos de instruções que não sejam funções (if,
+switch, for, while, do). Por exemplo:
+
+.. code-block:: c
+
+	switch (action) {
+	case KOBJ_ADD:
+		return "add";
+	case KOBJ_REMOVE:
+		return "remove";
+	case KOBJ_CHANGE:
+		return "change";
+	default:
+		return NULL;
+	}
+
+No entanto, há um caso especial: as funções, que têm a chave de abertura no
+início da linha seguinte, assim:
+
+.. code-block:: c
+
+	int function(int x)
+	{
+		body of function
+	}
+
+Pessoas heréticas por todo o mundo afirmaram que essa inconsistência é ...
+bem ... inconsistente, mas todas as pessoas de bom senso sabem que (a) K&R
+estão **corretos** e (b) K&R estão certos. Além disso, as funções são
+especiais de qualquer forma (você não pode aninhá-las em C).
+
+Observe que a chave de fechamento fica vazia em uma linha própria, **exceto**
+nos casos em que ela é seguida por uma continuação da mesma instrução, ou
+seja, um ``while`` em um do-statement ou um ``else`` em um if-statement, como
+neste exemplo:
+
+.. code-block:: c
+
+	do {
+		body of do-loop
+	} while (condition);
+
+e
+
+.. code-block:: c
+
+	if (x == y) {
+		..
+	} else if (x > y) {
+		...
+	} else {
+		....
+	}
+
+Justificativa: K&R.
+
+Além disso, observe que esse posicionamento de chaves também minimiza o
+número de linhas vazias (ou quase vazias), sem qualquer perda de
+legibilidade. Assim, como o suprimento de linhas novas na sua tela não é um
+recurso renovável (pense em telas de terminal de 25 linhas), você tem mais
+linhas vazias para colocar comentários.
+
+Não use chaves desnecessariamente quando uma única instrução basta.
+
+.. code-block:: c
+
+	if (condition)
+		action();
+
+e
+
+.. code-block:: c
+
+	if (condition)
+		do_this();
+	else
+		do_that();
+
+Isso não se aplica se apenas um ramo de uma instrução condicional for uma
+única instrução; nesse último caso, use chaves em ambos os ramos:
+
+.. code-block:: c
+
+	if (condition) {
+		do_this();
+		do_that();
+	} else {
+		otherwise();
+	}
+
+Além disso, use chaves quando um laço contiver mais de uma instrução simples:
+
+.. code-block:: c
+
+	while (condition) {
+		if (test)
+			do_something();
+	}
+
+3.1) Espaços
+************
+
+O estilo do kernel Linux para o uso de espaços depende (em grande parte) do
+uso de função versus palavra-chave. Use um espaço após (a maioria das)
+palavras-chave. As exceções notáveis são ``sizeof``, ``typeof``, ``alignof`` e
+``__attribute__``, que parecem um pouco com funções (e geralmente são usadas
+com parênteses no Linux, embora não sejam obrigatórias na linguagem, como em:
+``sizeof info`` depois que ``struct fileinfo info;`` é declarado).
+
+Então use um espaço após estas palavras-chave::
+
+	if, switch, case, for, do, while
+
+mas não com ``sizeof``, ``typeof``, ``alignof`` ou ``__attribute__``. Por
+exemplo,
+
+.. code-block:: c
+
+
+	s = sizeof(struct file);
+
+Não adicione espaços ao redor (dentro) de expressões entre parênteses. Este
+exemplo é **ruim**:
+
+.. code-block:: c
+
+
+	s = sizeof( struct file );
+
+Ao declarar dados de ponteiro ou uma função que retorna um tipo de ponteiro, o
+uso preferido de ``*`` fica adjacente ao nome dos dados ou ao nome da função e
+não adjacente ao nome do tipo. Exemplos:
+
+.. code-block:: c
+
+
+	char *linux_banner;
+	unsigned long long memparse(char *ptr, char **retptr);
+	char *match_strdup(substring_t *s);
+
+Use um espaço em volta (de cada lado) da maioria dos operadores binários e
+ternários, como qualquer um destes::
+
+	=  +  -  <  >  *  /  %  |  &  ^  <=  >=  ==  !=  ?  :
+
+mas sem espaço após operadores unários::
+
+	&  *  +  -  ~  !  sizeof  typeof  alignof  __attribute__  defined
+
+sem espaço antes dos operadores unários pós-fixados de incremento e
+decremento::
+
+	++  --
+
+sem espaço após os operadores unários prefixados de incremento e
+decremento::
+
+	++  --
+
+e sem espaço ao redor dos operadores de membro de estrutura ``.`` e ``->``.
+
+Não deixe espaços em branco no final das linhas. Alguns editores com
+indentação ``inteligente`` inserem espaços no início das novas linhas conforme
+apropriado, para que você possa começar a digitar a próxima linha de código
+imediatamente. No entanto, alguns desses editores não removem o espaço em
+branco se você acabar não colocando uma linha de código ali, como quando deixa
+uma linha em branco. Como resultado, você termina com linhas contendo espaço
+em branco no final.
+
+O Git avisará você sobre patches que introduzem espaço em branco no final e
+pode remover esse espaço automaticamente para você; entretanto, se você
+aplicar uma série de patches, isso pode fazer com que patches posteriores da
+série falhem ao alterar suas linhas de contexto.
+
+
+4) Nomeação
+-----------
+
+C é uma linguagem espartana, e suas convenções de nomenclatura devem seguir o
+mesmo caminho. Ao contrário dos programadores em Modula-2 e Pascal, os
+programadores em C não usam nomes bonitinhos como ThisVariableIsATemporaryCounter.
+Um programador em C chamaria essa variável de ``tmp``, o que é muito mais fácil
+de escrever e não é menos fácil de entender.
+
+ENTRETANTO, embora nomes em camelCase sejam desencorajados, nomes descritivos
+para variáveis globais são essenciais. Chamar uma função global de ``foo`` é
+um crime.
+
+Variáveis GLOBAIS (a serem usadas somente se você **realmente** precisar) devem
+ter nomes descritivos, assim como as funções globais. Se você tiver uma função
+que conta o número de usuários ativos, você deve chamá-la de
+``count_active_users()`` ou algo parecido; você **não** deve chamá-la de
+``cntusr()``.
+
+Codificar o tipo de uma função no nome (a chamada notação Húngara) é absurdo -
+o compilador conhece os tipos de qualquer forma e pode verificar isso, e isso
+só confunde o programador.
+
+Nomes de variáveis locais devem ser curtos e diretos. Se você tiver algum
+contador inteiro aleatório de loop, provavelmente deve ser chamado de ``i``.
+Chamá-lo de ``loop_counter`` é improdutivo, se não houver chance de ser mal
+interpretado. Da mesma forma, ``tmp`` pode ser praticamente qualquer tipo de
+variável usada para manter um valor temporário.
+
+Se você tem medo de misturar os nomes de variáveis locais, você tem outro
+problema, chamado síndrome de desequilíbrio de hormônio de crescimento da
+função. Veja o capítulo 6 (Funções).
+
+Para nomes de símbolos e documentação, evite introduzir o uso novo de
+'master / slave' (ou 'slave' independente de 'master') e 'blacklist /
+whitelist'.
+
+Substituições recomendadas para 'master / slave' são:
+    '{primary,main} / {secondary,replica,subordinate}'
+    '{initiator,requester} / {target,responder}'
+    '{controller,host} / {device,worker,proxy}'
+    'leader / follower'
+    'director / performer'
+
+Substituições recomendadas para 'blacklist/whitelist' são:
+    'denylist / allowlist'
+    'blocklist / passlist'
+
+Exceções para introduzir novos usos são manter uma ABI/API do espaço do
+usuário, ou ao atualizar código para um hardware ou especificação de
+protocolo existente (a partir de 2020) que exija esses termos. Para novas
+especificações, traduza o uso da terminologia na especificação para o padrão
+de codificação do kernel quando possível.
+
+5) Tipos definidos (typedefs)
+-----------------------------
+
+Por favor, não use coisas como ``vps_t``.
+É um **erro** usar ``typedef`` para estruturas e ponteiros. Quando você vê
+
+.. code-block:: c
+
+
+	vps_t a;
+
+no código-fonte, o que isso significa?
+Em contraste, se diz
+
+.. code-block:: c
+
+	struct virtual_container *a;
+
+você consegue dizer o que ``a`` é.
+
+Muitas pessoas pensam que ``typedef``s ``ajudam na legibilidade``. Não é bem
+assim. Eles são úteis apenas para:
+
+ (a) objetos totalmente opacos (onde o ``typedef`` é usado ativamente para
+     **ocultar** o que o objeto é).
+
+     Exemplo: ``pte_t`` etc. Objetos opacos que você só pode acessar usando
+     as funções de acesso apropriadas.
+
+     .. note::
+
+       Opacidade e ``funções de acesso`` não são boas em si mesmas.
+       A razão pela qual as temos para coisas como ``pte_t`` etc. é que
+       realmente existe absolutamente **zero** informação acessível de forma portátil
+       ali.
+
+ (b) tipos inteiros claros, em que a abstração **ajuda** a evitar confusão
+     sobre se é ``int`` ou ``long``.
+
+     ``u8/u16/u32`` são typedefs perfeitamente aceitáveis, embora se
+     encaixem melhor na categoria (d) do que aqui.
+
+     .. note::
+
+       Novamente - precisa haver uma **razão** para isso. Se algo é
+       ``unsigned long``, não há motivo para fazer
+
+	typedef unsigned long myflags_t;
+
+     mas se houver uma razão clara para que em certas circunstâncias possa
+     ser ``unsigned int`` e em outras configurações possa ser ``unsigned
+     long``, então, claro, use um ``typedef``.
+
+ (c) quando você usa ``sparse`` para criar literalmente um **novo** tipo para
+     verificação de tipos.
+
+ (d) novos tipos idênticos aos tipos padrão do C99, em certas
+     circunstâncias excepcionais.
+
+     Embora levasse apenas um curto período para os olhos e o cérebro se
+     acostumarem aos tipos padrão como ``uint32_t``, algumas pessoas ainda
+     se opõem ao seu uso.
+
+     Portanto, os tipos específicos do Linux ``u8/u16/u32/u64`` e seus
+     equivalentes assinados, que são idênticos aos tipos padrão, são
+     permitidos -- embora não sejam obrigatórios em código novo seu.
+
+     Ao editar código existente que já usa um ou outro conjunto de tipos, você
+     deve seguir as escolhas existentes nesse código.
+
+ (e) tipos seguros para uso em espaço do usuário.
+
+     Em certas estruturas visíveis ao espaço do usuário, não podemos exigir
+     tipos C99 nem usar a forma ``u32`` acima. Portanto, usamos ``__u32`` e
+     tipos semelhantes em todas as estruturas compartilhadas com o espaço do
+     usuário.
+
+Pode haver outros casos também, mas a regra básica deve ser: NUNCA use um
+``typedef`` a menos que você consiga encaixar claramente em uma dessas regras.
+
+Em geral, um ponteiro, ou uma estrutura com elementos que podem ser acessados
+diretamente, **nunca** deve ser um ``typedef``.
+
+
+6) Funções
+----------
+
+As funções devem ser curtas e diretas, e fazer apenas uma coisa. Elas devem
+caber em uma ou duas telas de texto (o tamanho de tela ISO/ANSI é 80x24,
+como todos sabem), e fazer uma coisa e fazê-la bem.
+
+O comprimento máximo de uma função é inversamente proporcional à complexidade
+e ao nível de indentação dessa função. Então, se você tiver uma função
+conceitualmente simples que seja apenas uma longa (mas simples) instrução
+``switch``, em que você precisa fazer várias pequenas coisas para muitos casos
+diferentes, é aceitável ter uma função mais longa.
+
+No entanto, se você tiver uma função complexa e suspeitar que um estudante
+do primeiro ano do ensino médio, menos talentoso, talvez nem entenda do que
+se trata a função, você deve obedecer aos limites máximos ainda mais de
+perto. Use funções auxiliares com nomes descritivos (você pode pedir ao
+compilador para incorporá-las em linha se achar que é crítico para o
+desempenho, e provavelmente ele fará um trabalho melhor do que você faria).
+
+Outra medida da função é o número de variáveis locais. Elas não devem exceder
+5-10, ou algo está errado. Reflita sobre a função e divida em partes menores.
+Um cérebro humano geralmente consegue rastrear facilmente cerca de 7 coisas
+diferentes; qualquer quantidade acima disso o confunde. Você sabe que é
+brilhante, mas talvez queira entender o que fez daqui a 2 semanas.
+
+Nos arquivos de código-fonte, separe as funções com uma linha em branco. Se a
+função for exportada, a macro **EXPORT** para ela deve seguir imediatamente
+depois da linha da chave de fechamento da função. Por exemplo:
+
+.. code-block:: c
+
+	int system_is_up(void)
+	{
+		return system_state == SYSTEM_RUNNING;
+	}
+	EXPORT_SYMBOL(system_is_up);
+
+6.1) Protótipos de função
+*************************
+
+Nos protótipos de função, inclua nomes de parâmetros junto com seus tipos de
+dados. Embora isso não seja obrigatório pela linguagem C, é preferido no Linux
+porque é uma maneira simples de adicionar informações valiosas para o leitor.
+
+Não use a palavra-chave ``extern`` em declarações de função, pois isso torna
+as linhas mais longas e não é estritamente necessário.
+
+Ao escrever protótipos de função, por favor mantenha a `ordem dos elementos
+regular <https://lore.kernel.org/mm-commits/CAHk-=wiOCLRny5aifWNhr621kYrJwhfURsa0vFPeUEm8mF0ufg@mail.gmail.com/>`_.
+Por exemplo, usando este exemplo de declaração de função::
+
+ __init void * __must_check action(enum magic value, size_t size, u8 count,
+				   char *fmt, ...) __printf(4, 5) __malloc;
+
+A ordem preferida dos elementos para um protótipo de função é:
+
+- classe de armazenamento (abaixo, ``static __always_inline``, observando que
+  ``__always_inline`` é tecnicamente um atributo, mas é tratado como ``inline``)
+- atributos de classe de armazenamento (aqui, ``__init`` -- ou seja,
+  declarações de seção, mas também coisas como ``__cold``)
+- tipo de retorno (aqui, ``void *``)
+- atributos do tipo de retorno (aqui, ``__must_check``)
+- nome da função (aqui, ``action``)
+- parâmetros da função (aqui, ``(enum magic value, size_t size, u8 count,
+  char *fmt, ...)``, observando que os nomes dos parâmetros devem sempre ser
+  incluídos)
+- atributos dos parâmetros da função (aqui, ``__printf(4, 5)``)
+- atributos de comportamento da função (aqui, ``__malloc``)
+
+Observe que, para uma **definição** de função (ou seja, o corpo real da
+função), o compilador não permite atributos de parâmetro da função depois dos
+parâmetros da função. Nesses casos, eles devem vir depois dos atributos da
+classe de armazenamento (por exemplo, observe a posição alterada de
+``__printf(4, 5)`` abaixo, em comparação com o exemplo de **declaração**
+acima)::
+
+ static __always_inline __init __printf(4, 5) void * __must_check action(enum magic value,
+		size_t size, u8 count, char *fmt, ...) __malloc
+ {
+	...
+ }
+
+7) Saída centralizada de funções
+--------------------------------
+
+Embora seja depreciado por algumas pessoas, o equivalente da instrução
+``goto`` é usado com frequência pelos compiladores na forma da instrução de
+salto incondicional.
+
+A instrução ``goto`` é útil quando uma função sai de vários pontos e é
+necessária alguma tarefa comum, como limpeza. Se não for necessária nenhuma
+limpeza, basta retornar diretamente.
+
+Escolha nomes de rótulos que indiquem o que o ``goto`` faz ou por que ele
+existe. Um exemplo de nome bom poderia ser ``out_free_buffer:`` se o goto
+liberar ``buffer``. Evite usar nomes do GW-BASIC como ``err1:`` e ``err2:``,
+porque você teria que renumerá-los se adicionasse ou removesse caminhos de
+saída, e isso também torna a correção mais difícil de verificar.
+
+A justificativa para usar gotos é:
+
+- instruções incondicionais são mais fáceis de entender e seguir
+- o aninhamento é reduzido
+- erros por não atualizar pontos de saída individuais ao fazer
+  modificações são evitados
+- economiza o trabalho do compilador de otimizar e remover código redundante ;)
+
+.. code-block:: c
+
+	int fun(int a)
+	{
+		int result = 0;
+		char *buffer;
+
+		buffer = kmalloc(SIZE, GFP_KERNEL);
+		if (!buffer)
+			return -ENOMEM;
+
+		if (condition1) {
+			while (loop1) {
+				...
+			}
+			result = 1;
+			goto out_free_buffer;
+		}
+		...
+	out_free_buffer:
+		kfree(buffer);
+		return result;
+	}
+
+Um tipo comum de bug do qual você deve estar ciente é o ``one err bugs``
+(o "bug de um erro"), que se parece com isto:
+
+.. code-block:: c
+
+	err:
+		kfree(foo->bar);
+		kfree(foo);
+		return ret;
+
+O problema neste código é que, em alguns caminhos de saída, ``foo`` é NULL.
+Normalmente, a correção é dividir em dois rótulos de erro
+``err_free_bar:`` e ``err_free_foo:``:
+
+.. code-block:: c
+
+	err_free_bar:
+		kfree(foo->bar);
+	err_free_foo:
+		kfree(foo);
+		return ret;
+
+Idealmente, você deve simular erros para testar todos os caminhos de saída.
+
+
+8) Comentários
+--------------
+
+Comentários são bons, mas também há o perigo de comentar demais. NUNCA tente
+explicar COMO o seu código funciona em um comentário: é muito melhor escrever
+o código de forma que o **funcionamento** seja óbvio, e é um desperdício de
+tempo explicar código mal escrito.
+
+Em geral, você quer que seus comentários digam O QUE o seu código faz, não
+COMO. Também tente evitar colocar comentários dentro do corpo de uma função:
+se a função for tão complexa que você precisa comentar partes separadas dela,
+provavelmente você deveria voltar ao capítulo 6 por um tempo. Você pode fazer
+pequenos comentários para notar ou avisar sobre algo particularmente esperto
+(ou feio), mas tente evitar excesso. Em vez disso, coloque os comentários no
+início da função, dizendo às pessoas o que ela faz e, possivelmente, POR QUE
+ela faz isso.
+
+Ao comentar as funções da API do kernel, por favor use o formato kernel-doc.
+Veja os arquivos em :ref:`Documentation/doc-guide/ <doc_guide>` e
+``tools/docs/kernel-doc`` para detalhes. Observe que o perigo de comentar em
+excesso se aplica aos comentários kernel-doc da mesma forma. Não adicione
+kernel-doc genérico que apenas repete o que já é óbvio pela assinatura da
+função.
+
+O estilo preferido para comentários longos (em várias linhas) é:
+
+.. code-block:: c
+
+	/*
+	 * Este é o estilo preferido para comentários em várias linhas
+	 * no código-fonte do kernel Linux.
+	 * Por favor, use-o de forma consistente.
+	 *
+	 * Descrição: uma coluna de asteriscos à esquerda,
+	 * com linhas de início e fim quase vazias.
+	 */
+
+Também é importante comentar dados, sejam tipos básicos ou tipos derivados.
+Para isso, use apenas uma declaração de dado por linha (sem vírgulas para
+múltiplas declarações de dados). Isso deixa espaço para um pequeno comentário
+em cada item explicando seu uso.
+
+
+9) Você fez uma bagunça
+-----------------------
+
+Tudo bem, todos fazemos isso. Você provavelmente foi informado por seu
+auxiliar de longa data em Unix que o ``GNU emacs`` formata automaticamente os
+arquivos-fonte em C para você, e você percebeu que ele realmente faz isso, mas as
+configurações padrão que ele usa são menos do que desejáveis (na verdade,
+elas são piores do que digitação aleatória - um número infinito de macacos
+digitando no GNU emacs nunca faria um bom programa).
+
+Então, você pode ou se livrar do GNU emacs, ou mudar para usar valores mais
+sãos. Para fazer isso, você pode colocar o seguinte no seu arquivo .emacs:
+
+.. code-block:: elisp
+
+  (defun c-lineup-arglist-tabs-only (ignored)
+    "Line up argument lists by tabs, not spaces"
+    (let* ((anchor (c-langelem-pos c-syntactic-element))
+          (column (c-langelem-2nd-pos c-syntactic-element))
+          (offset (- (1+ column) anchor))
+          (steps (floor offset c-basic-offset)))
+      (* (max steps 1)
+         c-basic-offset)))
+
+  (dir-locals-set-class-variables
+   'linux-kernel
+   '((c-mode . (
+          (c-basic-offset . 8)
+          (c-label-minimum-indentation . 0)
+          (c-offsets-alist . (
+                  (arglist-close         . c-lineup-arglist-tabs-only)
+                  (arglist-cont-nonempty .
+                      (c-lineup-gcc-asm-reg c-lineup-arglist-tabs-only))
+                  (arglist-intro         . +)
+                  (brace-list-intro      . +)
+                  (c                     . c-lineup-C-comments)
+                  (case-label            . 0)
+                  (comment-intro         . c-lineup-comment)
+                  (cpp-define-intro      . +)
+                  (cpp-macro             . -1000)
+                  (cpp-macro-cont        . +)
+                  (defun-block-intro     . +)
+                  (else-clause           . 0)
+                  (func-decl-cont        . +)
+                  (inclass               . +)
+                  (inher-cont            . c-lineup-multi-inher)
+                  (knr-argdecl-intro     . 0)
+                  (label                 . -1000)
+                  (statement             . 0)
+                  (statement-block-intro . +)
+                  (statement-case-intro  . +)
+                  (statement-cont        . +)
+                  (substatement          . +)
+                  ))
+          (indent-tabs-mode . t)
+          (show-trailing-whitespace . t)
+          ))))
+
+  (dir-locals-set-directory-class
+   (expand-file-name "~/src/linux-trees")
+   'linux-kernel)
+
+Isso fará o emacs funcionar melhor com o estilo de codificação do kernel para
+arquivos C abaixo de ``~/src/linux-trees``.
+
+Mas, mesmo que você falhe em fazer o emacs formatar de maneira sensata, nem
+tudo está perdido: use ``indent``.
+
+Agora, novamente, o GNU indent tem as mesmas configurações sem cérebro do GNU
+emacs, e é por isso que você precisa dar a ele algumas opções de linha de
+comando. No entanto, isso não é tão ruim, porque até os criadores do GNU
+indent reconhecem a autoridade do K&R (as pessoas do GNU não são más, apenas
+estão gravemente equivocadas nessa questão), então você apenas dá ao indent as
+opções ``-kr -i8`` (que significa ``K&R, indentações de 8 caracteres``), ou
+usa ``scripts/Lindent``, que indenta no estilo mais recente.
+
+``indent`` tem muitas opções, e especialmente quando se trata de reformatação
+de comentários, você pode querer dar uma olhada na página de manual. Mas
+lembre-se: ``indent`` não é uma solução para programação ruim.
+
+Observe que você também pode usar a ferramenta ``clang-format`` para ajudá-lo
+com essas regras, para reformatar rapidamente partes do seu código
+automaticamente e revisar arquivos completos para detectar erros de estilo de
+codificação, erros de digitação e possíveis melhorias. Também é útil para
+ordenar ``#includes``, alinhar variáveis/macros, reorganizar texto e outras
+tarefas semelhantes. Consulte o arquivo
+:ref:`Documentation/dev-tools/clang-format.rst <clangformat>`
+para obter mais detalhes.
+
+Algumas configurações básicas do editor, como indentação e finais de linha,
+serão definidas automaticamente se você estiver usando um editor compatível com
+o EditorConfig. Consulte o site oficial do EditorConfig para obter mais
+informação: https://editorconfig.org/
+
+10) Arquivos de configuração Kconfig
+------------------------------------
+
+Para todos os arquivos de configuração Kconfig* em toda a árvore de origem,
+a indentação é um pouco diferente. Linhas sob uma definição ``config`` são
+indentadas com uma tabulação, enquanto o texto de ajuda é indentado com mais
+dois espaços. Exemplo::
+
+  config AUDIT
+	bool "Auditing support"
+	depends on NET
+	help
+	  Enable auditing infrastructure that can be used with another
+	  kernel subsystem, such as SELinux (which requires this for
+	  logging of avc messages output).  Does not do system-call
+	  auditing without CONFIG_AUDITSYSCALL.
+
+Recursos seriamente perigosos (como suporte de gravação para certos sistemas
+de arquivos) devem anunciar isso de forma proeminente na string do prompt::
+
+  config ADFS_FS_RW
+	bool "ADFS write support (DANGEROUS)"
+	depends on ADFS_FS
+	...
+
+Para documentação completa sobre os arquivos de configuração, consulte o
+arquivo Documentation/kbuild/kconfig-language.rst.
+
+
+11) Estruturas de dados
+-----------------------
+
+Estruturas de dados que tenham visibilidade fora do ambiente monothread em que
+são criadas e destruídas devem ter contadores de referência. No kernel, coleta
+de lixo não existe (e fora do kernel, a coleta de lixo é lenta e
+ineficiente), o que significa que você absolutamente **precisa** contar todas
+as referências de uso.
+
+Contagem de referência significa que você pode evitar bloqueios e permite que
+múltiplos usuários tenham acesso à estrutura de dados em paralelo - sem se
+preocupar com a estrutura desaparecendo debaixo deles do nada apenas porque
+eles dormiram ou fizeram outra coisa por um tempo.
+
+Observe que bloqueio **não** substitui contagem de referência. O bloqueio é
+usado para manter estruturas de dados coerentes, enquanto a contagem de
+referência é uma técnica de gerenciamento de memória. Normalmente, ambos são
+necessários, e não devem ser confundidos entre si.
+
+Muitas estruturas de dados podem, de fato, ter dois níveis de contagem de
+referência, quando existem usuários de diferentes ``classes``. A contagem da
+subclasse conta o número de usuários da subclasse e decrementa a contagem
+global apenas uma vez quando a contagem da subclasse chega a zero.
+
+Exemplos desse tipo de ``multi-level-reference-counting`` podem ser encontrados
+em gerenciamento de memória (``struct mm_struct``: mm_users e mm_count) e em
+código de sistema de arquivos (``struct super_block``: s_count e s_active).
+
+Lembre-se: se outra thread puder encontrar sua estrutura de dados, e você não
+tiver contagem de referência nela, quase certamente há um bug.
+
+
+12) Macros, enums e RTL
+-----------------------
+
+Nomes de macros que definem constantes e rótulos em enums são maiúsculos.
+
+.. code-block:: c
+
+	#define CONSTANT 0x12345
+
+Enums são preferidos quando várias constantes relacionadas são definidas.
+
+Nomes de macro em maiúsculas são apreciados, mas macros que se parecem com
+funções podem ser nomeadas em minúsculas.
+
+Em geral, funções inline são preferíveis a macros que se parecem com funções.
+
+Macros com múltiplas instruções devem ser envoltas em um bloco do-while:
+
+.. code-block:: c
+
+	#define macrofun(a, b, c) \
+		do { \
+			if (a == 5) \
+				do_this(b, c); \
+		} while (0)
+
+Macros do tipo função com parâmetros não usados devem ser substituídas por
+funções estáticas inline para evitar o problema de variáveis não usadas:
+
+.. code-block:: c
+
+	static inline void fun(struct foo *foo)
+	{
+	}
+
+Devido a práticas históricas, muitos arquivos ainda empregam a abordagem
+"cast para (void)" para avaliar parâmetros. No entanto, esse método não é
+aconselhável.
+Funções inline resolvem o problema de "expressão com efeitos colaterais
+avaliada mais de uma vez", contornam problemas de variáveis não usadas e, por
+algum motivo, geralmente são mais bem documentadas do que macros.
+
+.. code-block:: c
+
+	/*
+	 * Evite fazer isto sempre que possível e prefira funções estáticas
+	 * inline
+	 */
+	#define macrofun(foo) do { (void) (foo); } while (0)
+
+Coisas a evitar ao usar macros:
+
+1) macros que afetam o fluxo de controle:
+
+.. code-block:: c
+
+	#define FOO(x) \
+		do { \
+			if (blah(x) < 0) \
+				return -EBUGGERED; \
+		} while (0)
+
+é uma ideia **muito** ruim. Ela parece uma chamada de função, mas sai da
+função ``calling``; não quebre os parsers internos de quem lerá o código.
+
+2) macros que dependem de ter uma variável local com um nome mágico:
+
+.. code-block:: c
+
+	#define FOO(val) bar(index, val)
+
+pode parecer uma boa coisa, mas é confuso pra caramba para quem lê o código e
+é propenso a quebrar com mudanças aparentemente inocentes.
+
+3) macros com argumentos usados como l-values: FOO(x) = y; vai te morder se
+alguém, por exemplo, transformar FOO em uma função inline.
+
+4) esquecer da precedência: macros que definem constantes usando expressões
+devem colocar a expressão entre parênteses. Cuidado com problemas semelhantes
+com macros que usam parâmetros.
+
+.. code-block:: c
+
+	#define CONSTANT 0x4000
+	#define CONSTEXP (CONSTANT | 3)
+
+5) colisões de namespace ao definir variáveis locais em macros que se
+parecem com funções:
+
+.. code-block:: c
+
+	#define FOO(x)				\
+	({					\
+		typeof(x) ret;			\
+		ret = calc_ret(x);		\
+		(ret);				\
+	})
+
+``ret`` é um nome comum para uma variável local - ``__foo_ret`` tem menos
+chance de colidir com uma variável existente.
+
+O manual do cpp trata de macros de forma exaustiva. O manual interno do gcc
+também cobre o RTL, que é usado frequentemente com linguagem de montagem no
+kernel.
+
+
+13) Imprimindo mensagens do kernel
+----------------------------------
+
+Desenvolvedores do kernel gostam de ser vistos como letrados. Preste atenção à
+ortografia das mensagens do kernel para causar uma boa impressão. Não use
+contrações incorretas como ``dont``; use ``do not`` ou ``don't`` em vez
+disso. Faça as mensagens concisas, claras e inequívocas.
+
+Mensagens do kernel não precisam terminar com ponto.
+
+Imprimir números entre parênteses (%d) não agrega valor e deve ser evitado.
+
+Há vários macros de diagnóstico do modelo de driver em <linux/dev_printk.h>
+que você deve usar para garantir que as mensagens sejam correspondidas ao
+dispositivo e driver corretos e sejam marcadas com o nível certo: ``dev_err()``,
+``dev_warn()``, ``dev_info()`` e assim por diante. Para mensagens que não
+estão associadas a um device específico, <linux/printk.h> define
+``pr_notice()``, ``pr_info()``, ``pr_warn()``, ``pr_err()`` etc. Quando os
+drivers funcionam corretamente, eles ficam silenciosos, então prefira usar
+``dev_dbg``/``pr_debug`` a menos que algo esteja errado.
+
+Encontrar boas mensagens de depuração pode ser um desafio; e, uma vez que
+você tenha essas mensagens, elas podem ajudar bastante para solução de
+problemas remota. No entanto, a impressão de mensagens de depuração é tratada
+diferentemente da impressão de outras mensagens não de depuração. Enquanto as
+outras funções ``pr_XXX()`` imprimem incondicionalmente, ``pr_debug()`` não;
+ela é compilada fora por padrão, a menos que ``DEBUG`` seja definido ou
+``CONFIG_DYNAMIC_DEBUG`` esteja configurado. Isso também vale para
+``dev_dbg()``, e uma convenção relacionada usa ``VERBOSE_DEBUG`` para adicionar
+mensagens ``dev_vdbg()`` às já habilitadas por ``DEBUG``.
+
+Muitos subsistemas têm opções de depuração do Kconfig para ativar ``-DDEBUG``
+no Makefile correspondente; em outros casos, arquivos específicos fazem
+``#define DEBUG``. E quando uma mensagem de depuração deve ser impressa
+incondicionalmente, por exemplo, se ela já estiver dentro de uma seção
+``#ifdef`` relacionada à depuração, pode-se usar ``printk(KERN_DEBUG ...)``.
+
+
+14) Alocando memória
+--------------------
+
+O kernel fornece os seguintes alocadores de memória de uso geral:
+``kmalloc()``, ``kzalloc()``, ``kmalloc_objs()``, ``kzalloc_objs()``,
+``vmalloc()`` e ``vzalloc()``. Consulte a documentação da API para obter mais
+informações sobre eles. :ref:`Documentation/core-api/memory-allocation.rst
+<memory_allocation>`
+
+A forma preferida de passar o tamanho de uma estrutura é a seguinte:
+
+.. code-block:: c
+
+	p = kmalloc_obj(*p, ...);
+
+A forma alternativa em que o nome da estrutura é escrito explicitamente piora a
+legibilidade e cria oportunidade para um bug quando o tipo da variável ponteiro
+é alterado, mas o ``sizeof`` correspondente passado para um alocador de memória
+não é.
+
+Casting do valor de retorno, que é um ponteiro ``void``, é redundante. A
+conversão de ponteiro ``void`` para qualquer outro tipo de ponteiro é garantida
+pela linguagem de programação C.
+
+A forma preferida para alocar um array é a seguinte:
+
+.. code-block:: c
+
+	p = kmalloc_objs(*p, n, ...);
+
+A forma preferida para alocar um array zerado é a seguinte:
+
+.. code-block:: c
+
+	p = kzalloc_objs(*p, n, ...);
+
+As duas formas verificam estouro no tamanho de alocação ``n * sizeof(...)`` e
+retornam ``NULL`` se isso ocorrer.
+
+Essas funções genéricas de alocação emitem um dump de pilha em caso de falha
+quando usadas sem ``__GFP_NOWARN``, então não há utilidade em emitir uma
+mensagem de falha adicional quando ``NULL`` é retornado.
+
+15) A doença do inline
+----------------------
+
+Parece haver uma percepção errônea comum de que o gcc tem uma opção mágica de
+aceleração chamada ``inline``. Embora o uso de ``inline`` possa ser apropriado
+(por exemplo, como uma forma de substituir macros; veja o Capítulo 12), muitas
+vezes não é. O uso abundante da palavra-chave ``inline`` leva a um kernel
+muito maior, o que, por sua vez, torna o sistema mais lento como um todo, por
+causa de uma maior ocupação de i-cache para a CPU e simplesmente porque há menos
+memória disponível para o ``pagecache``. Pense nisso: uma falha no pagecache
+causa um seek no disco, que facilmente leva 5 milissegundos. Há MUITOS ciclos
+de CPU que podem entrar nesses 5 milissegundos.
+
+Uma regra prática razoável é não colocar ``inline`` em funções com mais de 3
+linhas de código. Uma exceção a essa regra são os casos em que um parâmetro é
+conhecido como uma constante em tempo de compilação, e como resultado dessa
+constância você *sabe* que o compilador será capaz de otimizar grande parte da
+sua função em tempo de compilação. Para um bom exemplo desse caso posterior,
+veja a função inline ``kmalloc()``.
+
+Muitas pessoas argumentam que adicionar ``inline`` a funções ``static`` usadas
+apenas uma vez é sempre uma vantagem, porque não há custo de espaço. Embora
+isso seja tecnicamente correto, o gcc é capaz de fazer esse inline
+automaticamente sem ajuda, e a questão de manutenção de remover o ``inline``
+quando um segundo usuário aparece supera o valor potencial da dica que diz ao
+gcc para fazer algo que ele faria de qualquer forma.
+
+
+16) Valores e nomes de retorno de função
+----------------------------------------
+
+Funções podem retornar valores de vários tipos, e um dos mais comuns é um valor
+que indica se a função teve sucesso ou falhou. Esse valor pode ser representado
+como um inteiro de código de erro (-Exxx = falha, 0 = sucesso) ou como um
+booleano ``succeeded`` (0 = falha, diferente de zero = sucesso).
+
+Misturar esses dois tipos de representação é uma fonte fértil de bugs difíceis
+de encontrar. Se a linguagem C incluísse uma distinção forte entre inteiros e
+booleanos, o compilador encontraria esses erros para nós... mas não inclui. Para
+ajudar a evitar esses bugs, siga sempre esta convenção::
+
+	Se o nome de uma função for uma ação ou um comando imperativo,
+	a função deve retornar um inteiro de código de erro. Se o nome
+	for um predicado, a função deve retornar um booleano de "sucesso".
+
+Por exemplo, ``add work`` é um comando, e a função ``add_work()`` retorna 0
+para sucesso ou -EBUSY para falha. Da mesma forma, ``PCI device present`` é um
+predicado, e a função ``pci_dev_present()`` retorna 1 se encontrar um device
+correspondente ou 0 se não encontrar.
+
+Todas as funções ``EXPORT`` devem respeitar esta convenção, e assim também
+devem todas as funções públicas. Funções privadas (``static``) não precisam,
+mas é recomendável que o façam.
+
+Funções cujo valor de retorno é o resultado real de um cálculo, em vez de uma
+indicação de se o cálculo teve sucesso, não estão sujeitas a essa regra.
+Normalmente, elas indicam falha retornando algum resultado fora do intervalo.
+Exemplos típicos seriam funções que retornam ponteiros; elas usam ``NULL`` ou o
+mecanismo ``ERR_PTR`` para informar falha.
+
+
+17) Usando bool
+---------------
+
+O tipo ``bool`` do kernel Linux é um alias do tipo C99 ``_Bool``. Valores
+``bool`` só podem avaliar para 0 ou 1, e conversão implícita ou explícita para
+``bool`` converte automaticamente o valor para verdadeiro ou falso. Ao usar
+tipos ``bool``, a construção ``!!`` não é necessária, o que elimina uma classe
+de bugs.
+
+Ao trabalhar com valores ``bool``, as definições ``true`` e ``false`` devem ser
+usadas em vez de 1 e 0.
+
+Tipos de retorno de função ``bool`` e variáveis locais na pilha são sempre
+válidos quando apropriados. O uso de ``bool`` é encorajado para melhorar a
+legibilidade e muitas vezes é uma opção melhor do que ``int`` para armazenar
+valores booleanos.
+
+Não use ``bool`` se o layout da linha de cache ou o tamanho do valor importar,
+porque seu tamanho e alinhamento variam conforme a arquitetura compilada.
+Estruturas otimizadas para alinhamento e tamanho não devem usar ``bool``.
+
+Se uma estrutura tiver muitos valores verdadeiro/falso, considere consolidá-los
+em um ``bitfield`` com membros de 1 bit, ou usar um tipo de largura fixa
+apropriado, como ``u8``.
+
+Da mesma forma, para argumentos de função, muitos valores verdadeiro/falso podem
+ser consolidados em um único argumento de sinalizadores bit a bit, e
+``flags`` muitas vezes pode ser uma alternativa mais legível se os pontos de
+chamada tiverem constantes verdadeiras/falsas "nuas".
+
+Caso contrário, o uso limitado de ``bool`` em estruturas e argumentos pode
+melhorar a legibilidade.
+
+18) Não reinventando as macros do kernel
+----------------------------------------
+
+Existem muitos arquivos de cabeçalho em ``include/linux/`` que contêm várias
+macros que você deve usar em vez de escrever explicitamente alguma variante
+delas. Por exemplo, se você precisa calcular o comprimento de um array, aproveite
+a macro
+
+.. code-block:: c
+
+	#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
+
+que é definida em ``array_size.h``.
+
+Da mesma forma, se você precisar calcular o tamanho de um membro de alguma
+estrutura, use
+
+.. code-block:: c
+
+	#define sizeof_field(t, f) (sizeof(((t*)0)->f))
+
+que é definida em ``stddef.h``.
+
+Também existem macros ``min()`` e ``max()`` definidas em ``minmax.h`` que fazem
+verificação estrita de tipos se você precisar delas. Sinta-se à vontade para
+explorar os arquivos de cabeçalho para ver o que já está definido e não deve
+ser reproduzido no seu código.
+
+
+19) Modelines do editor e outros restos
+---------------------------------------
+
+Alguns editores podem interpretar informações de configuração embutidas em
+arquivos de origem, indicadas por marcadores especiais. Por exemplo, o emacs
+interpreta linhas marcadas assim:
+
+.. code-block:: c
+
+	-*- mode: c -*-
+
+Ou assim:
+
+.. code-block:: c
+
+	/*
+	Local Variables:
+	compile-command: "gcc -DMAGIC_DEBUG_FLAG foo.c"
+	End:
+	*/
+
+O Vim interpreta marcadores que parecem com isto:
+
+.. code-block:: c
+
+	/* vim:set sw=8 noet */
+
+Não inclua nenhum desses em arquivos de origem. As pessoas têm suas próprias
+configurações pessoais de editor, e seus arquivos de origem não devem
+substituí-las. Isso inclui marcadores para indentação e configuração de modo.
+As pessoas podem usar seu próprio modo personalizado, ou podem ter algum outro
+método mágico para fazer a indentação funcionar corretamente.
+
+
+20) Montagem inline
+-------------------
+
+Em código específico de arquitetura, pode ser necessário usar montagem inline
+para interagir com a funcionalidade da CPU ou da plataforma. Não hesite em
+fazê-lo quando necessário. No entanto, não use montagem inline de forma
+gratuita quando o C puder fazer o trabalho. Você pode e deve mexer em hardware
+em C quando possível.
+
+Considere escrever funções auxiliares simples que encapsulem partes comuns de
+montagem inline, em vez de escrevê-las repetidamente com pequenas variações.
+Lembre-se de que a montagem inline pode usar parâmetros C.
+
+Funções grandes e não triviais de montagem devem ir para arquivos ``.S``, com
+protótipos C correspondentes definidos em arquivos de cabeçalho C. Os
+protótipos C para funções de montagem devem usar ``asmlinkage``.
+
+Você pode precisar marcar sua instrução ``asm`` como ``volatile`` para impedir
+que o GCC a remova se o GCC não perceber efeitos colaterais. No entanto, você
+nem sempre precisa fazer isso, e fazê-lo desnecessariamente pode limitar a
+otimização.
+
+Ao escrever uma única instrução de montagem inline contendo várias instruções,
+coloque cada instrução em uma linha separada em uma string separada e termine
+cada string, exceto a última, com ``\n\t`` para indentar corretamente a
+próxima instrução na saída de montagem:
+
+.. code-block:: c
+
+	asm ("magic %reg1, #42\n\t"
+	     "more_magic %reg2, %reg3"
+	     : /* outputs */ : /* inputs */ : /* clobbers */);
+
+
+21) Compilação condicional
+--------------------------
+
+Sempre que possível, não use condicionais do pré-processador (#if, #ifdef) em
+arquivos ``.c``; isso torna o código mais difícil de ler e a lógica mais difícil
+de seguir. Em vez disso, use esses condicionais em um arquivo de cabeçalho que
+defina funções para uso nesses arquivos ``.c``, fornecendo versões de stub sem
+efeito no caso ``#else``, e então chame essas funções incondicionalmente nos
+arquivos ``.c``. O compilador evitará gerar qualquer código para as chamadas de
+stub, produzindo resultados idênticos, mas a lógica permanecerá fácil de
+seguir.
+
+Prefira compilar funções inteiras fora do código, em vez de partes de funções
+ou partes de expressões. Em vez de colocar um ``ifdef`` em uma expressão,
+extraia parte ou toda a expressão para uma função auxiliar separada e aplique a
+condicional a essa função.
+
+Se você tiver uma função ou variável que pode potencialmente ficar sem uso em
+uma configuração específica, e o compilador avisaria sobre a definição ficar sem
+uso, marque a definição como ``__maybe_unused`` em vez de envolvê-la em uma
+condicional do pré-processador. (No entanto, se uma função ou variável
+*sempre* ficar sem uso, elimine-a.)
+
+Dentro do código, quando possível, use a macro ``IS_ENABLED`` para converter um
+símbolo Kconfig em uma expressão booleana C e usá-la em uma condicional C
+normal:
+
+.. code-block:: c
+
+	if (IS_ENABLED(CONFIG_SOMETHING)) {
+		...
+	}
+
+O compilador reduzirá a condicional a um valor constante e incluirá ou
+excluirá o bloco de código assim como com um ``#ifdef``, então isso não
+adicionará nenhum custo de runtime. No entanto, essa abordagem ainda permite
+que o compilador C veja o código dentro do bloco e verifique sua correção
+(sintaxe, tipos, referências de símbolo etc.). Portanto, você ainda precisa usar
+um ``#ifdef`` se o código dentro do bloco referenciar símbolos que não existirão
+se a condição não for atendida.
+
+No final de qualquer bloco ``#if`` ou ``#ifdef`` não trivial (mais de algumas
+linhas), coloque um comentário após o ``#endif`` na mesma linha, indicando a
+expressão condicional usada. Por exemplo:
+
+.. code-block:: c
+
+	#ifdef CONFIG_SOMETHING
+	...
+	#endif /* CONFIG_SOMETHING */
+
+
+22) Não derrube o kernel
+------------------------
+
+Em geral, a decisão de derrubar o kernel pertence ao usuário, e não ao
+desenvolvedor do kernel.
+
+Evite ``panic()``
+*****************
+
+``panic()`` deve ser usado com cuidado e principalmente apenas durante a inicialização
+do sistema. ``panic()`` é, por exemplo, aceitável ao ficar sem memória durante
+a inicialização e não ser possível continuar.
+
+Use ``WARN()`` em vez de ``BUG()``
+**********************************
+
+Não adicione novo código que use nenhuma das variantes de ``BUG()``, como
+``BUG()``, ``BUG_ON()`` ou ``VM_BUG_ON()``. Em vez disso, use uma variante de
+``WARN*()``, preferencialmente ``WARN_ON_ONCE()``, e possivelmente com código de
+recuperação. O código de recuperação não é obrigatório se não houver uma
+maneira razoável de pelo menos recuperar parcialmente.
+
+"Sou preguiçoso para tratar erros" não é uma desculpa para usar ``BUG()``.
+Corrupções internas graves sem como continuar ainda podem usar ``BUG()``, mas
+precisam de uma boa justificativa.
+
+Use ``WARN_ON_ONCE()`` em vez de ``WARN()`` ou ``WARN_ON()``
+************************************************************
+
+``WARN_ON_ONCE()`` geralmente é preferido em relação a ``WARN()`` ou
+``WARN_ON()``, porque é comum que uma dada condição de aviso, se ocorrer,
+ocorra várias vezes. Isso pode encher e sobrescrever o log do kernel e até
+diminuir o sistema o suficiente para que o registro excessivo vire um problema
+adicional.
+
+Não emita ``WARN`` levianamente
+*******************************
+
+``WARN*()`` foi concebido para situações inesperadas, em que "isso nunca devia
+acontecer". Macros ``WARN*()`` não devem ser usadas para nada que se espere que
+aconteça durante a operação normal. Esses não são asserts de pré- ou pós-
+condição, por exemplo. Novamente: ``WARN*()`` não deve ser usado para uma
+condição que se espera que seja acionada facilmente, por exemplo, por ações do
+espaço do usuário. ``pr_warn_once()`` é uma alternativa possível, se você
+precisar notificar o usuário sobre um problema.
+
+Não se preocupe com usuários de ``panic_on_warn``
+*************************************************
+
+Mais algumas palavras sobre ``panic_on_warn``: lembre-se de que
+``panic_on_warn`` é uma opção disponível do kernel, e muitos usuários a
+habilitam. É por isso que existe um texto "Não emita WARN levianamente" acima.
+Entretanto, a existência de usuários de ``panic_on_warn`` não é uma razão válida
+para evitar o uso judicioso de ``WARN*()``. Isso ocorre porque quem habilita
+``panic_on_warn`` explicitamente pediu ao kernel para travar se um ``WARN*()``
+for disparado, e esses usuários devem estar preparados para lidar com as
+consequências de um sistema que tem uma chance um pouco maior de travar.
+
+Use ``BUILD_BUG_ON()`` para assertivas em tempo de compilação
+*************************************************************
+
+O uso de ``BUILD_BUG_ON()`` é aceitável e encorajado, porque é uma assertiva
+em tempo de compilação que não tem efeito em tempo de execução.
+
+Apêndice I) Referências
+-----------------------
+
+The C Programming Language, Second Edition
+by Brian W. Kernighan and Dennis M. Ritchie.
+Prentice Hall, Inc., 1988.
+ISBN 0-13-110362-8 (paperback), 0-13-110370-9 (hardback).
+
+The Practice of Programming
+by Brian W. Kernighan and Rob Pike.
+Addison-Wesley, Inc., 1999.
+ISBN 0-201-61586-X.
+
+Manuais GNU - onde em conformidade com K&R e este texto - para cpp, gcc,
+gcc internals e indent, todos disponíveis em https://www.gnu.org/manual/
+
+WG14 é o grupo de trabalho de padronização internacional para a linguagem de
+programação C, URL: http://www.open-std.org/JTC1/SC22/WG14/
+
+Kernel CodingStyle, by greg@kroah.com at OLS 2002:
+http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/
diff --git a/Documentation/translations/pt_BR/process/cve.rst b/Documentation/translations/pt_BR/process/cve.rst
index 18f4b11be369..83977eda34c4 100644
--- a/Documentation/translations/pt_BR/process/cve.rst
+++ b/Documentation/translations/pt_BR/process/cve.rst
@@ -18,7 +18,7 @@ essas atribuições.
 A equipe de desenvolvedores do kernel Linux tem a capacidade de atribuir CVEs
 para possíveis problemas de segurança do kernel Linux. Essa atribuição é
 independente do processo normal de relato de bugs de segurança do kernel
-Linux, descrito em :ref:`securitybugs`.
+Linux, descrito em :ref:`pt_BR_securitybugs`.
 
 Uma lista de todos os CVEs atribuídos ao kernel Linux pode ser encontrada nos
 arquivos da lista de discussão linux-cve, como visto em
@@ -51,7 +51,7 @@ ele é SOMENTE para atribuição de CVEs a correções que já estejam em árvor
 kernel lançadas. Se você acredita ter encontrado um problema de segurança
 ainda
 não corrigido, por favor siga o processo normal de relato de bugs de segurança do kernel
-Linux, descrito em :ref:`securitybugs`.
+Linux, descrito em :ref:`pt_BR_securitybugs`.
 
 Nenhum CVE será atribuído automaticamente para problemas de segurança ainda
 não corrigidos no kernel Linux; a atribuição só acontecerá automaticamente
diff --git a/Documentation/translations/pt_BR/process/debugging/index.rst b/Documentation/translations/pt_BR/process/debugging/index.rst
new file mode 100644
index 000000000000..b223fae34622
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/debugging/index.rst
@@ -0,0 +1,73 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=======================================================
+Dicas de depuração para desenvolvedores do Kernel Linux
+=======================================================
+
+Guias gerais
+------------
+
+Todolist:
+
+*   driver_development_debugging_guide
+*   gdb-kernel-debugging
+*   kgdb
+*   userspace_debugging_guide
+
+Guias específicos de subsistemas
+--------------------------------
+
+Todolist:
+
+*   media_specific_debugging_guide
+
+Dicas gerais de depuração
+-------------------------
+
+Dependendo do problema, um conjunto diferente de ferramentas está disponível
+para rastrear o problema ou até mesmo para perceber se há algum problema em
+primeiro lugar.
+
+Como primeiro passo, você precisa descobrir que tipo de problema você deseja
+depurar. Dependendo da resposta, sua metodologia e escolha de ferramentas podem
+variar.
+
+Preciso depurar com acesso limitado?
+------------------------------------
+
+Você possui acesso limitado à máquina ou não consegue parar a execução em
+andamento?
+
+Nesse caso, sua capacidade de depuração depende do suporte de depuração
+embutido no kernel fornecido pela distribuição.
+O :doc:`/process/debugging/userspace_debugging_guide` fornece uma breve visão
+geral sobre uma variedade de ferramentas de depuração possíveis nessa situação.
+Você pode verificar a capacidade do seu kernel, na maioria dos casos, olhando o
+arquivo de configuração dentro do diretório /boot.
+
+Eu tenho acesso root ao sistema?
+--------------------------------
+
+Você consegue facilmente substituir o módulo em questão ou instalar um novo
+kernel?
+
+Nesse caso, sua gama de ferramentas disponíveis é muito maior. Você
+pode encontrar as ferramentas
+no :doc:`/process/debugging/driver_development_debugging_guide`.
+
+A temporização é um fator?
+--------------------------
+
+É importante entender se o problema que você deseja depurar se manifesta
+de forma consistente (ou seja, para um determinado conjunto de entradas, você
+sempre obtém a mesma saída incorreta) ou de forma inconsistente. Se ele se
+manifestar de forma inconsistente, algum fator de temporização pode estar em
+jogo. Se a inserção de atrasos no código alterar o comportamento, é bastante
+provável que a temporização seja um fator determinante.
+
+Quando a temporização altera o resultado da execução do código, o uso de um
+simples printk() para fins de depuração pode não funcionar; uma alternativa
+semelhante é usar trace_printk(), que registra as mensagens de depuração no
+arquivo de rastreamento, em vez de no log do kernel.
+
+**Copyright** ©2024 : Collabora
diff --git a/Documentation/translations/pt_BR/process/development-process.rst b/Documentation/translations/pt_BR/process/development-process.rst
index d303ab92b2d3..e1441cec8b1a 100644
--- a/Documentation/translations/pt_BR/process/development-process.rst
+++ b/Documentation/translations/pt_BR/process/development-process.rst
@@ -1,5 +1,7 @@
 .. SPDX-License-Identifier: GPL-2.0
 
+.. _pt_BR_development_process_main:
+
 Guia para o Processo de Desenvolvimento do Kernel
 =================================================
 
diff --git a/Documentation/translations/pt_BR/process/embargoed-hardware-issues.rst b/Documentation/translations/pt_BR/process/embargoed-hardware-issues.rst
new file mode 100644
index 000000000000..ae1fda0880cc
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/embargoed-hardware-issues.rst
@@ -0,0 +1,362 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Problemas de hardware sob embargo
+=================================
+
+Escopo
+------
+
+Problemas de hardware que resultam em problemas de segurança formam uma categoria
+de bugs de segurança diferente dos bugs de software puros que afetam apenas o
+kernel do Linux.
+
+Problemas de hardware como Meltdown, Spectre, L1TF, etc., devem ser tratados
+de maneira diferente porque geralmente afetam todos os Sistemas Operacionais ("OS")
+e, portanto, exigem coordenação entre diferentes fornecedores de SO, distribuições,
+fabricantes de silício, integradores de hardware e outras partes. Para alguns
+dos problemas, as mitigações de software podem depender de atualizações de
+microcódigo ou firmware, o que requer ainda mais coordenação.
+
+.. _pt_BR_Contact:
+
+Contato
+-------
+
+A equipe de segurança de hardware do kernel Linux é separada da equipe regular
+de segurança do kernel Linux.
+
+A equipe lida apenas com o desenvolvimento de correções para problemas de
+segurança de hardware sob embargo. Relatos de bugs de segurança de software puro
+no kernel Linux não são tratados por esta equipe, e o autor do relato será
+orientado a contatar a equipe regular de segurança do kernel Linux
+(:ref:`Documentation/admin-guide/ <securitybugs>`) em vez disso.
+
+A equipe pode ser contatada por e-mail em <hardware-security@kernel.org>. Esta
+é uma lista privada de oficiais de segurança que ajudarão você a coordenar uma
+correção de acordo com o nosso processo documentado.
+
+A lista é criptografada e o e-mail para a lista pode ser enviado criptografado
+por PGP ou S/MIME, e deve ser assinado com a chave PGP ou certificado S/MIME do
+autor do relato. A chave PGP e o certificado S/MIME da equipe estão disponíveis
+nas seguintes URLs:
+
+  - PGP: https://www.kernel.org/static/files/hardware-security.asc
+  - S/MIME: https://www.kernel.org/static/files/hardware-security.crt
+
+Embora os problemas de segurança de hardware sejam frequentemente tratados pelo
+fabricante de silício afetado, nós acolhemos o contato de pesquisadores ou
+indivíduos que tenham identificado uma falha potencial de hardware.
+
+Oficiais de segurança de hardware
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+A equipe atual de oficiais de segurança de hardware:
+
+  - Linus Torvalds (Fellow da Linux Foundation)
+  - Greg Kroah-Hartman (Fellow da Linux Foundation)
+  - Thomas Gleixner (Fellow da Linux Foundation)
+
+Operação das listas de e-mail
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+As listas de e-mail criptografadas que são usadas em nosso processo são
+hospedadas na infraestrutura de TI da Linux Foundation. Ao fornecer este
+serviço, os membros da equipe de operações de TI da Linux Foundation têm,
+tecnicamente, a capacidade de acessar as informações sob embargo, mas são
+obrigados à confidencialidade por seu contrato de trabalho. O pessoal de TI
+da Linux Foundation também é responsável por operar e gerenciar o restante da
+infraestrutura do kernel.org.
+
+O atual diretor de infraestrutura de projetos de TI da Linux Foundation é
+Konstantin Ryabitsev.
+
+
+Acordos de não divulgação
+-------------------------
+
+A equipe de segurança de hardware do kernel Linux não é um órgão formal e,
+portanto, é incapaz de celebrar quaisquer acordos de não divulgação. A
+comunidade do kernel está ciente da natureza sensível de tais problemas e
+oferece um Memorando de Entendimento em vez disso.
+
+
+Memorando de Entendimento
+-------------------------
+
+A comunidade do kernel Linux compreende profundamente a necessidade de manter
+os problemas de segurança de hardware sob embargo para a coordenação entre
+diferentes fornecedores de SO, distribuidores, fabricantes de silício e outras
+partes.
+
+A comunidade do kernel Linux lidou com sucesso com problemas de segurança de
+hardware no passado e possui os mecanismos necessários para permitir o
+desenvolvimento compatível com a comunidade sob restrições de embargo.
+
+A comunidade do kernel Linux possui uma equipe dedicada de segurança de hardware
+para o contato inicial, que supervisiona o processo de tratamento de tais
+problemas sob as regras de embargo.
+
+A equipe de segurança de hardware identifica os desenvolvedores (especialistas no
+domínio) que formarão a equipe de resposta inicial para um problema específico.
+A equipe de resposta inicial pode trazer outros desenvolvedores (especialistas no
+domínio) para resolver o problema da melhor maneira técnica.
+
+Todos os desenvolvedores envolvidos comprometem-se a aderir às regras de embargo
+e a manter as informações recebidas em sigilo. A violação do compromisso levará à
+exclusão imediata do problema atual e à remoção de todas as listas de e-mail
+relacionadas. Além disso, a equipe de segurança de hardware também excluirá o
+infrator de futuros problemas. O impacto dessa consequência é um impedimento
+altamente eficaz em nossa comunidade. Caso ocorra uma violação, a equipe de
+segurança de hardware informará as partes envolvidas imediatamente. Se você ou
+qualquer outra pessoa tomar conhecimento de uma potencial violação, por favor,
+relate-a imediatamente aos oficiais de segurança de hardware.
+
+
+Processo
+^^^^^^^^
+
+Devido à natureza globalmente distribuída do desenvolvimento do kernel Linux,
+reuniões presenciais são quase impossíveis para lidar com problemas de
+segurança de hardware. Conferências telefônicas são difíceis de coordenar devido
+a fusos horários e outros fatores, devendo ser usadas apenas quando estritamente
+necessário. O e-mail criptografado tem se mostrado o método de comunicação mais
+eficiente e seguro para esses tipos de problema.
+
+Início da divulgação
+"""""""""""""""""""""
+
+A divulgação começa enviando um e-mail para a equipe de segurança de hardware
+do kernel Linux, conforme a seção Contato acima. Este contato inicial deve
+conter uma descrição do problema e uma lista de qualquer silício afetado
+conhecido. Se a sua organização constrói ou distribui o hardware afetado,
+incentivamos você a considerar também quais outros hardwares podem ser
+afetados. A parte que faz a divulgação é responsável por contatar os
+fabricantes de silício afetados em tempo hábil.
+
+A equipe de segurança de hardware fornecerá uma lista de e-mail criptografada
+específica para o incidente, que será usada para a discussão inicial com o
+relator, divulgação posterior e coordenação de correções.
+
+A equipe de segurança de hardware fornecerá à parte divulgadora uma lista de
+desenvolvedores (especialistas no domínio) que devem ser informados inicialmente
+sobre o problema após confirmar com os desenvolvedores que eles aderirão a
+este Memorando de Entendimento e ao processo documentado. Esses desenvolvedores
+formam a equipe de resposta inicial e serão responsáveis por lidar com o
+problema após o contato inicial. A equipe de segurança de hardware apoia a
+equipe de resposta, mas não está necessariamente envolvida no processo de
+desenvolvimento de mitigações.
+
+Embora desenvolvedores individuais possam estar cobertos por um acordo de não
+divulgação por meio de seu empregador, eles não podem celebrar acordos
+individuais de não divulgação em seu papel como desenvolvedores do kernel
+Linux. No entanto, eles concordarão em aderir a este processo documentado e ao
+Memorando de Entendimento.
+
+A parte divulgadora deve fornecer uma lista de contatos para todas as outras
+entidades que já foram, ou devem ser, informadas sobre o problema. Isso serve
+a vários propósitos:
+
+ - A lista de entidades informadas permite a comunicação em toda a
+   indústria, por exemplo, outros fornecedores de SO, fornecedores de HW, etc.
+
+ - As entidades informadas podem ser contatadas para indicar especialistas
+   que devem participar do desenvolvimento da mitigação.
+
+ - Se um especialista necessário para lidar com um problema for funcionário
+   de uma entidade listada ou membro de uma entidade listada, as equipes de
+   resposta podem solicitar a inclusão desse especialista por parte daquela
+   entidade. Isso garante que o especialista também faça parte da equipe de
+   resposta da entidade.
+
+Divulgação
+""""""""""
+
+A parte divulgadora fornece informações detalhadas à equipe de resposta inicial
+por meio da lista de e-mail criptografada específica.
+
+A partir de nossa experiência, a documentação técnica desses problemas costuma
+ser um ponto de partida suficiente, e esclarecimentos técnicos adicionais são
+melhor feitos por e-mail.
+
+Desenvolvimento de mitigações
+""""""""""""""""""""""""""""""
+
+A equipe de resposta inicial configura uma lista de e-mail criptografada ou
+reaproveita uma já existente, se apropriado.
+
+O uso de uma lista de e-mail é próximo ao processo normal de desenvolvimento
+do Linux e tem sido usado com sucesso para desenvolver mitigações para vários
+problemas de segurança de hardware no passado.
+
+A lista de e-mail opera da mesma forma que o desenvolvimento normal do Linux.
+Os patches são publicados, discutidos, revisados e, se aprovados, aplicados a
+um repositório git não público que é acessível apenas aos desenvolvedores
+participantes por meio de uma conexão segura. O repositório contém o ramo
+(branch) principal de desenvolvimento contra o kernel mainline e ramos de
+retroporte (backport) para versões estáveis do kernel conforme necessário.
+
+A equipe de resposta inicial identificará outros especialistas da comunidade
+de desenvolvedores do kernel Linux conforme necessário. Qualquer parte
+envolvida pode sugerir a inclusão de outros especialistas, cada um dos quais
+estará sujeito aos mesmos requisitos descritos acima.
+
+A inclusão de especialistas pode ocorrer a qualquer momento no processo de
+desenvolvimento e precisa ser tratada em tempo hábil.
+
+Se um especialista for funcionário ou membro de uma entidade na lista de
+divulgação fornecida pela parte divulgadora, a participação será solicitada
+à entidade relevante.
+
+Caso contrário, a parte divulgadora será informada sobre a participação
+dos especialistas. Os especialistas são cobertos pelo Memorando de Entendimento
+e a parte divulgadora é solicitada a reconhecer a participação deles. No caso
+de a parte divulgadora ter um motivo convincente para se opor, qualquer
+objeção deve ser levantada no prazo de cinco dias úteis e resolvida com a
+equipe do incidente imediatamente. Se a parte divulgadora não reagir dentro
+de cinco dias úteis, isso é considerado como reconhecimento tácito.
+
+Após a equipe do incidente reconhecer ou resolver uma objeção, o especialista
+é informado e integrado ao processo de desenvolvimento.
+
+Os participantes da lista não podem se comunicar sobre o problema fora da
+lista de e-mail privada. Os participantes da lista não podem usar nenhum
+recurso compartilhado (por exemplo, fazendas de compilação do empregador,
+sistemas de IC, etc.) ao trabalhar em patches.
+
+Acesso antecipado
+"""""""""""""""""
+
+Os patches discutidos e desenvolvidos na lista não podem ser distribuídos a
+nenhum indivíduo que não seja membro da equipe de resposta, nem a nenhuma outra
+organização.
+
+Para permitir que os fornecedores de silício afetados trabalhem com suas equipes
+internas e parceiros da indústria em testes, validação e logística, a seguinte
+exceção é fornecida:
+
+    Representantes designados dos fornecedores de silício afetados têm permissão
+    para repassar os patches a qualquer momento para a equipe de resposta do
+    fornecedor de silício. O representante deve notificar a equipe de resposta
+    do kernel sobre o repasse. O fornecedor de silício afetado deve possuir e
+    manter seu próprio processo de segurança documentado para quaisquer patches
+    compartilhados com sua equipe de resposta que seja consistente com esta
+    política.
+
+    A equipe de resposta do fornecedor de silício pode distribuir esses patches
+    aos seus parceiros da indústria e às suas equipes internas sob o processo
+    de segurança documentado do fornecedor de silício. O feedback dos parceiros
+    da indústria retorna ao fornecedor de silício e é comunicado por ele à
+    equipe de resposta do kernel.
+
+    O repasse para a equipe de resposta do fornecedor de silício remove
+    qualquer responsabilidade civil ou legal da equipe de resposta do kernel
+    em relação à divulgação prematura que ocorra devido ao envolvimento das
+    equipes internas ou parceiros da indústria do fornecedor de silício. O
+    fornecedor de silício garante esta liberação de responsabilidade ao
+    concordar com este processo.
+
+Lançamento coordenado
+"""""""""""""""""""""
+
+As partes envolvidas negociarão a data e a hora em que o embargo termina. Nesse
+ponto, as mitigações preparadas são publicadas nas árvores de kernel relevantes.
+Não há processo de pré-notificação: as mitigações são publicadas publicamente e
+disponibilizadas para todos ao mesmo tempo.
+
+Embora entendamos que problemas de segurança de hardware exijam tempo de embargo
+coordenado, o tempo de embargo deve ser restrito ao mínimo necessário para que
+todas as partes envolvidas desenvolvam, testem e preparem suas mitigações.
+Estender o tempo de embargo artificialmente para cumprir datas de palestras em
+conferências ou outros motivos não técnicos cria mais trabalho e ônus para os
+desenvolvedores e equipes de resposta envolvidos, pois os patches precisam ser
+mantidos atualizados para acompanhar o desenvolvimento contínuo do kernel
+upstream, o que pode criar alterações conflitantes.
+
+Atribuição de CVE
+""""""""""""""""""
+
+Nem a equipe de segurança de hardware nem a equipe de resposta inicial atribuem
+CVEs, nem os CVEs são necessários para o processo de desenvolvimento. Se os CVEs
+forem fornecidos pela parte divulgadora, eles poderão ser usados para fins de
+documentação.
+
+Embaixadores do processo
+------------------------
+
+Para obter assistência com este processo, estabelecemos embaixadores em várias
+organizações, que podem responder a perguntas sobre ou fornecer orientações
+acerca do processo de relatórios e tratamento posterior. Os embaixadores não
+estão envolvidos na divulgação de um problema específico, a menos que seja
+solicitado por uma equipe de resposta ou por uma parte divulgada envolvida.
+A lista atual de embaixadores:
+
+  ============= ========================================================
+  AMD           Tom Lendacky <thomas.lendacky@amd.com>
+  Ampere        Darren Hart <darren@os.amperecomputing.com>
+  ARM           Catalin Marinas <catalin.marinas@arm.com>
+  IBM Power     Madhavan Srinivasan <maddy@linux.ibm.com>
+  IBM Z         Christian Borntraeger <borntraeger@de.ibm.com>
+  Intel         Tony Luck <tony.luck@intel.com>
+  Qualcomm      Trilok Soni <quic_tsoni@quicinc.com>
+  RISC-V        Palmer Dabbelt <palmer@dabbelt.com>
+  Samsung       Javier González <javier.gonz@samsung.com>
+
+  Microsoft     James Morris <jamorris@linux.microsoft.com>
+  Xen           Andrew Cooper <andrew.cooper3@citrix.com>
+
+  Canonical     John Johansen <john.johansen@canonical.com>
+  Debian        Ben Hutchings <ben@decadent.org.uk>
+  Oracle        Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+  Red Hat       Josh Poimboeuf <jpoimboe@redhat.com>
+  SUSE          Jiri Kosina <jkosina@suse.cz>
+
+  Google        Kees Cook <keescook@chromium.org>
+
+  LLVM          Nick Desaulniers <ndesaulniers@google.com>
+  ============= ========================================================
+
+Se você quiser que sua organização seja adicionada à lista de embaixadores,
+entre em contato com a equipe de segurança de hardware. O embaixador indicado
+deve compreender e apoiar totalmente o nosso processo e, idealmente, estar bem
+conectado na comunidade do kernel Linux.
+
+Listas de e-mail criptografadas
+-------------------------------
+
+Usamos listas de e-mail criptografadas para comunicação. O princípio de
+operação dessas listas é que o e-mail enviado para a lista é criptografado
+com a chave PGP da lista ou com o certificado S/MIME da lista. O software
+da lista de e-mail descriptografa o e-mail e o recriptografa individualmente
+para cada assinante com a chave PGP ou certificado S/MIME do assinante.
+Detalhes sobre o software da lista de e-mail e a configuração usada para
+garantir a segurança das listas e a proteção dos dados podem ser encontrados
+aqui: https://korg.wiki.kernel.org/userdoc/remail.
+
+Listas de chaves
+^^^^^^^^^^^^^^^^
+
+Para o contato inicial, consulte a seção :ref:`pt_BR_Contact` acima. Para listas de
+e-mail específicas de incidentes, a chave e o certificado S/MIME são transmitidos
+aos assinantes por e-mail enviado a partir da lista específica.
+
+Inscrição em listas específicas de incidentes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+A inscrição em listas específicas de incidentes é gerenciada pelas equipes de
+resposta. As partes informadas que desejam participar da comunicação enviam
+uma lista de potenciais especialistas para a equipe de resposta, para que esta
+possa validar as solicitações de inscrição.
+
+Cada assinante precisa enviar uma solicitação de inscrição para a equipe de
+resposta por e-mail. O e-mail deve estar assinado com a chave PGP ou o certificado
+S/MIME do assinante. Se uma chave PGP for utilizada, ela deve estar disponível
+em um servidor de chaves público e, idealmente, conectada à teia de confiança
+(web of trust) PGP do kernel Linux. Veja também:
+https://www.kernel.org/signature.html.
+
+A equipe de resposta verifica se a solicitação do assinante é válida e o
+adiciona à lista. Após a inscrição, o assinante receberá e-mails da lista de
+e-mail que são assinados com a chave PGP da lista ou com o certificado S/MIME
+da lista. O cliente de e-mail do assinante pode extrair a chave PGP ou o
+certificado S/MIME da assinatura para que o assinante possa enviar e-mails
+criptografados para a lista.
\ No newline at end of file
diff --git a/Documentation/translations/pt_BR/process/howto.rst b/Documentation/translations/pt_BR/process/howto.rst
index bcedee7273fd..54ea7fad8d75 100644
--- a/Documentation/translations/pt_BR/process/howto.rst
+++ b/Documentation/translations/pt_BR/process/howto.rst
@@ -67,7 +67,8 @@ Questões Legais
 O código-fonte do kernel Linux é lançado sob a GPL. Por favor, veja o arquivo
 COPYING no diretório principal da árvore de fontes. As regras de licenciamento
 do kernel Linux e como usar os identificadores `SPDX <https://spdx.org/>`_ no
-código-fonte estão descritas em :ref:`Documentation/process/license-rules.rst <kernel_licensing>`.
+código-fonte estão descritas em
+:ref:`Documentation/translations/pt_BR/process/license-rules.rst <pt_BR_kernel_licensing>`.
 Se você tiver mais perguntas sobre a licença, por favor, entre em contato com
 um advogado e não pergunte na lista de discussão do kernel Linux. As pessoas
 nas listas de discussão não são advogados e você não deve confiar em suas
@@ -94,7 +95,7 @@ a lista linux-api@vger.kernel.org.
 Aqui está uma lista de arquivos que estão na árvore de fontes do kernel e
 que são de leitura obrigatória:
 
-  :ref:`Documentation/admin-guide/README.rst <readme>`
+  :ref:`Documentation/translations/pt_BR/admin-guide/README.rst <pt_BR_readme>`
     Este arquivo fornece um breve histórico sobre o kernel Linux e descreve
     o que é necessário fazer para configurar e compilar o kernel. Pessoas
     que são novas no kernel devem começar por aqui.
@@ -104,14 +105,14 @@ que são de leitura obrigatória:
     software que são necessários para compilar e executar o kernel com
     sucesso.
 
-  :ref:`Documentation/process/coding-style.rst <codingstyle>`
+  :ref:`Documentation/translations/pt_BR/process/coding-style.rst <pt_BR_codingstyle>`
     Este documento descreve o estilo de codificação do kernel Linux e parte
     da fundamentação por trás dele. Espera-se que todo código novo siga as
     diretrizes deste documento. A maioria dos mantenedores apenas aceitará
     patches se essas regras forem seguidas, e muitas pessoas apenas
     revisarão o código se ele estiver no estilo adequado.
 
-  :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
+  :ref:`Documentation/translations/pt_BR/process/submitting-patches.rst <pt_BR_submittingpatches>`
     Este arquivo descreve em detalhes explícitos como criar e enviar
     um patch com sucesso, incluindo (mas não limitado a):
 
@@ -144,12 +145,12 @@ Outras excelentes descrições de como criar patches adequadamente são:
     do Linux e é muito importante para pessoas que estão migrando para o
     Linux vindas do desenvolvimento em outros Sistemas Operacionais.
 
-  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
+  :ref:`Documentation/translations/pt_BR/process/security-bugs.rst <pt_BR_securitybugs>`
     Se você acredita ter encontrado um problema de segurança no kernel Linux,
     por favor, siga os passos descritos neste documento para ajudar a
     notificar os desenvolvedores do kernel e auxiliar na resolução do problema.
 
-  :ref:`Documentation/process/management-style.rst <managementstyle>`
+  :ref:`Documentation/translations/pt_BR/process/management-style.rst <pt_BR_managementstyle>`
     Este documento descreve como os mantenedores do kernel Linux operam e o
     ethos compartilhado por trás de suas metodologias. Esta é uma leitura
     importante para qualquer pessoa nova no desenvolvimento do kernel (ou
@@ -162,12 +163,12 @@ Outras excelentes descrições de como criar patches adequadamente são:
     versões estáveis (stable) do kernel e o que fazer se você desejar que
     uma alteração seja incluída em um desses lançamentos.
 
-  :ref:`Documentation/process/kernel-docs.rst <kernel_docs>`
+  :ref:`Documentation/translations/pt_BR/process/kernel-docs.rst <pt_BR_kernel_docs>`
     Uma lista de documentação externa que pertence ao desenvolvimento do
     kernel. Por favor, consulte esta lista caso não encontre o que está
     procurando dentro da documentação interna do kernel.
 
-  :ref:`Documentation/process/applying-patches.rst <applying_patches>`
+  :ref:`Documentation/translations/pt_BR/process/applying-patches.rst <pt_BR_applying_patches>`
     Uma boa introdução descrevendo exatamente o que é um patch e como
     aplicá-lo aos diferentes ramos (branches) de desenvolvimento do kernel.
 
@@ -435,7 +436,7 @@ individualmente, em vez de escrever tudo no topo do e-mail.
 
 Se você adicionar patches ao seu e-mail, certifique-se de que sejam texto
 puro legível, conforme declarado em
-:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`.
+:ref:`Documentation/translations/pt_BR/process/submitting-patches.rst <pt_BR_submittingpatches>`.
 Os desenvolvedores do kernel não querem lidar com anexos ou patches
 compactados; eles podem querer comentar linhas individuais do seu patch,
 o que só funciona dessa forma. Certifique-se de usar um programa de
diff --git a/Documentation/translations/pt_BR/process/index.rst b/Documentation/translations/pt_BR/process/index.rst
index eda2a3fc5166..d072f7e46767 100644
--- a/Documentation/translations/pt_BR/process/index.rst
+++ b/Documentation/translations/pt_BR/process/index.rst
@@ -26,6 +26,7 @@ sua entrada na comunidade do kernel.
 
    Como começar <howto>
    Guia do Processo de Desenvolvimento <development-process>
+   Enviando patches: o guia essencial para colocar o seu código no kernel <submitting-patches>
    Lista de verificação para submissão de patches do kernel Linux <submit-checklist>
 
 Ferramentas e guias técnicos para desenvolvedores do kernel
@@ -38,10 +39,12 @@ devem estar familiarizados.
    :maxdepth: 1
 
    Requisitos mínimos <changes>
+   Estilo de codificação do kernel Linux <coding-style>
    Informações sobre clientes de email para Linux <email-clients>
    Como aplicar patches <applying-patches>
    Backporting e resolução de conflitos <backporting>
    Adicionando uma nova chamada de Sistema <adding-syscalls>
+   Por que a classe de tipo "volatile" não deve ser usada <volatile-considered-harmful>
    Como não Deixar as ioctls malfeitas <botching-up-ioctls>
 
 Guias de políticas e declarações de desenvolvedores
@@ -57,8 +60,12 @@ Estas são as regras pelas quais tentamos viver na comunidade do kernel
    Código de Conduta de Compromisso do Colaborador <code-of-conduct>
    Interpretação do Código de Conduta do Kernel Linux <code-of-conduct-interpretation>
    Modelos de Maturidade para Contribuição no Kernel Linux <contribution-maturity-model.rst>
+   Declaração de Aplicação do Kernel Linux <kernel-enforcement-statement>
    Declaração sobre Drivers do Kernel <kernel-driver-statement>
+   A interface de drivers do kernel Linux <stable-api-nonsense>
    Estilo de gerenciamento do kernel Linux <management-style>
+   Assistentes de código <coding-assistants>
+   O manual da árvore tip <maintainer-tip>
    Conclave (Continuidade do projeto) <conclave>
 
 Lidando com bugs
@@ -71,7 +78,9 @@ gerenciamento de bugs e vulnerabilidades.
 .. toctree::
    :maxdepth: 1
 
+   Dicas de depuração para desenvolvedores do Kernel Linux <debugging/index>
    Falhas de segurança <security-bugs>
+   Problemas de hardware sob embargo <embargoed-hardware-issues>
    CVEs <cve>
 
 Informações para mantenedores
@@ -88,6 +97,7 @@ mantenedores de subsistemas.
    Processo do subsistema SoC <maintainer-soc>
    Conformidade de DTS para SoC <maintainer-soc-clean-dts>
    Processo do subsistema KVM x86 <maintainer-kvm-x86>
+   Subsistema de Devicetree e Open Firmware <maintainer-devicetree>
 
 Outros materiais
 ----------------
diff --git a/Documentation/translations/pt_BR/process/kernel-docs.rst b/Documentation/translations/pt_BR/process/kernel-docs.rst
index 3c8d80ffa567..6235b1e7bde0 100644
--- a/Documentation/translations/pt_BR/process/kernel-docs.rst
+++ b/Documentation/translations/pt_BR/process/kernel-docs.rst
@@ -1,5 +1,7 @@
 .. SPDX-License-Identifier: GPL-2.0
 
+.. _pt_BR_kernel_docs:
+
 Índice de Documentação Adicional do Kernel
 ==========================================
 
diff --git a/Documentation/translations/pt_BR/process/kernel-enforcement-statement.rst b/Documentation/translations/pt_BR/process/kernel-enforcement-statement.rst
new file mode 100644
index 000000000000..3833c433c36b
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/kernel-enforcement-statement.rst
@@ -0,0 +1,163 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Declaração de Aplicação do Kernel Linux
+---------------------------------------
+
+Como desenvolvedores do kernel Linux, temos um grande interesse em como nosso
+software é usado e como a licença do nosso software é aplicada. A conformidade
+com as obrigações de compartilhamento recíproco da GPL-2.0 é crítica para a
+sustentabilidade a longo prazo do nosso software e da nossa comunidade.
+
+Embora exista o direito de aplicar os interesses de direitos autorais separados nas
+contribuições feitas à nossa comunidade, compartilhamos o interesse em garantir
+que ações de aplicação individuais sejam conduzidas de uma maneira que beneficie
+nossa comunidade e não tenham um impacto negativo não intencional na saúde e no
+crescimento do nosso ecossistema de software. A fim de deter ações de aplicação
+inúteis, concordamos que é do melhor interesse da nossa comunidade de
+desenvolvimento assumir o seguinte compromisso com os usuários do kernel Linux,
+em nosso nome e em nome de quaisquer sucessores dos nossos interesses de
+direitos autorais:
+
+    Não obstante as disposições de rescisão da GPL-2.0, concordamos que
+    é do melhor interesse da nossa comunidade de desenvolvimento adotar as
+    seguintes disposições da GPL-3.0 como permissões adicionais sob nossa
+    licença com relação a qualquer reivindicação não defensiva de direitos sob a
+    licença.
+
+	No entanto, se você cessar toda violação desta Licença, sua licença
+	de um detentor de direitos autorais específico será restabelecida (a)
+	provisoriamente, a menos e até que o detentor de direitos autorais encerre
+	explícita e definitivamente sua licença, e (b) permanentemente, se o
+	detentor de direitos autorais não notificar você sobre a violação por
+	algum meio razoável antes de 60 dias após a cessação.
+
+	Além disso, sua licença de um detentor de direitos autorais específico é
+	restabelecida permanentemente se o detentor de direitos autorais
+	notificá-lo da violação por algum meio razoável, se esta for a primeira
+	vez que você recebe um aviso de violação desta Licença (para qualquer
+	trabalho) daquele detentor de direitos autorais, e você sanar a violação
+	antes de 30 dias após o recebimento do aviso.
+
+Nossa intenção ao fornecer essas garantias é incentivar um maior uso do
+software. Queremos que empresas e indivíduos usem, modifiquem e distribuam
+este software. Queremos trabalhar com os usuários de forma aberta e transparente
+para eliminar qualquer incerteza sobre nossas expectativas em relação à
+conformidade ou aplicação que possa limitar a adoção do nosso software. Vemos
+a ação judicial como um último recurso, a ser iniciada apenas quando outros
+esforços da comunidade falharem em resolver o problema.
+
+Por fim, uma vez que um problema de não conformidade seja resolvido, esperamos
+que o usuário se sinta bem-vindo para se juntar a nós em nossos esforços neste
+projeto. Trabalhando juntos, seremos mais fortes.
+
+Exceto onde indicado abaixo, falamos apenas por nós mesmos, e não por qualquer
+empresa para a qual possamos trabalhar hoje, no passado ou no futuro.
+
+  - 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/pt_BR/process/license-rules.rst b/Documentation/translations/pt_BR/process/license-rules.rst
index 1e395dfea875..7a801b2a4f4e 100644
--- a/Documentation/translations/pt_BR/process/license-rules.rst
+++ b/Documentation/translations/pt_BR/process/license-rules.rst
@@ -1,5 +1,7 @@
 .. SPDX-License-Identifier: GPL-2.0
 
+.. _pt_BR_kernel_licensing:
+
 Regras de licenciamento do kernel Linux
 =======================================
 
diff --git a/Documentation/translations/pt_BR/process/maintainer-devicetree.rst b/Documentation/translations/pt_BR/process/maintainer-devicetree.rst
new file mode 100644
index 000000000000..be26d89defdf
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/maintainer-devicetree.rst
@@ -0,0 +1,76 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=========================================
+Subsistema de Devicetree e Open Firmware
+=========================================
+
+Outros documentos sobre o processo
+----------------------------------
+
+Consulte os documentos em Documentation/devicetree/bindings/ para saber como
+escrever bindings de Devicetree corretamente e como enviar patches.
+
+Revisão e tratamento de patches
+-------------------------------
+
+Os patches sob responsabilidade dos mantenedores de Devicetree são processados
+de formas distintas, conforme o tipo de patch:
+
+1. Código central de drivers OF, por exemplo, drivers/of/:
+   os patches são revisados e aplicados pelos mantenedores de DT.
+
+2. Bindings de Devicetree:
+   os patches são revisados pelos mantenedores de DT, mas devem ser aplicados
+   pelos mantenedores do subsistema, exceto em alguns casos. Consulte também
+   *Para mantenedores do kernel* em
+   Documentation/devicetree/bindings/submitting-patches.rst.
+
+3. DTS e drivers:
+   os mantenedores de DT podem fazer comentários, mas, em geral, não se espera
+   uma revisão. Os DTS devem passar nas verificações de esquema
+   (dtbs_check) ou, ao menos, não gerar novos avisos.
+
+Patchwork
+~~~~~~~~~
+
+Os mantenedores de Devicetree revisam patches usando o Patchwork; portanto, o
+status atual de um patch pode ser consultado por lá. Em submissões típicas de
+drivers, o Patchwork recebe toda a série de patches, mas normalmente apenas
+alguns patches são bindings de Devicetree e, assim, revisados pelos
+mantenedores de DT.
+
+Explicação dos status do Patchwork:
+
+ - **New**: ainda não processado pelo conjunto de ferramentas de automação.
+ - **Needs ACK**: aguardando revisão dos mantenedores de DT.
+ - **Handled Elsewhere**: patch não relacionado a DT; não será revisado aqui.
+ - **RFC**: o patch provavelmente foi ignorado por ser um RFC incompleto.
+ - **Changes Requested**: o patch foi revisado e os mantenedores de DT esperam
+   alterações.
+ - **Accepted**: o patch foi revisado e aplicado pelos mantenedores de DT em
+   sua árvore.
+ - **Not Applicable**: o patch foi revisado e provavelmente está em boas
+   condições, com uma tag *Reviewed-by* ou *Acked-by* fornecida, mas os
+   mantenedores de DT esperam que outra pessoa o aplique.
+
+Nova revisão e pings de patches
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Devido ao alto volume de e-mails, os mantenedores de Devicetree não leem todas
+as mensagens que recebem; em vez disso, eles dependem do Patchwork durante o
+processo de revisão. Além disso, muitas vezes deixam de lado patches que já
+foram revisados.
+
+Como resultado, os mantenedores podem não perceber:
+
+1. Perguntas sobre patches já revisados.
+2. Pings, por exemplo, quando um patch foi revisado pelos mantenedores de DT,
+   mas ainda não foi aplicado pelos mantenedores do subsistema.
+
+Esses casos podem ser tratados das seguintes formas:
+
+1. Enviando um ping aos mantenedores de DT no canal de IRC.
+2. Removendo a tag *Acked-by* ou *Reviewed-by* do mantenedor de DT ao enviar
+   uma nova versão da série de patches, junto com uma explicação no changelog
+   do patch sobre o motivo da remoção da tag e o que se espera dos mantenedores
+   de DT.
diff --git a/Documentation/translations/pt_BR/process/maintainer-handbooks.rst b/Documentation/translations/pt_BR/process/maintainer-handbooks.rst
index b7aab788ffdb..1307306501ab 100644
--- a/Documentation/translations/pt_BR/process/maintainer-handbooks.rst
+++ b/Documentation/translations/pt_BR/process/maintainer-handbooks.rst
@@ -5,8 +5,8 @@ Notas sobre o processo de desenvolvimento de subsistemas e mantenedores
 
 O propósito deste documento é fornecer informações específicas de
 subsistemas que são suplementares ao manual geral do processo de
-desenvolvimento.
-:ref:`Documentation/process <development_process_main>`.
+desenvolvimento
+:ref:`Documentation/translations/pt_BR/process <pt_BR_development_process_main>`.
 
 Para desenvolvedores, veja abaixo todos os guias específicos de
 subsistemas conhecidos. Se o subsistema para o qual você está
diff --git a/Documentation/translations/pt_BR/process/maintainer-kvm-x86.rst b/Documentation/translations/pt_BR/process/maintainer-kvm-x86.rst
index 6480ff08b9d8..ef133d32c517 100644
--- a/Documentation/translations/pt_BR/process/maintainer-kvm-x86.rst
+++ b/Documentation/translations/pt_BR/process/maintainer-kvm-x86.rst
@@ -122,7 +122,7 @@ Quando se trata de estilo, nomenclatura, padrões, etc., a consistência é a
 prioridade número um no KVM x86. Se tudo mais falhar, siga o que já existe.
 
 Com algumas ressalvas listadas abaixo, siga o estilo de codificação preferido
-dos mantenedores da árvore "tip" (:ref:`maintainer-tip-coding-style`), já que
+dos mantenedores da árvore "tip" (:ref:`pt_BR_maintainer-tip-coding-style`), já que
 patches/séries frequentemente tocam tanto arquivos do KVM quanto arquivos x86
 não-KVM, ou seja, atraem a atenção de mantenedores do KVM *e* da árvore "tip".
 
@@ -206,7 +206,7 @@ Novos tópicos surgem ocasionalmente, mas, por favor, inicie uma discussão na
 lista se desejar propor a introdução de um novo tópico; ou seja, não aja por
 conta própria.
 
-Veja :ref:`the_canonical_patch_format` para mais informações, com uma ressalva:
+Veja :ref:`pt_BR_the_canonical_patch_format` para mais informações, com uma ressalva:
 não trate o limite de 70-75 caracteres como um limite absoluto e rígido. Em
 vez disso, use 75 caracteres como um limite firme, mas não rígido, e use 80
 caracteres como um limite intransponível. Ou seja, permita que o shortlog
@@ -218,7 +218,7 @@ Changelog
 O mais importante: escreva os changelogs usando o modo imperativo e evite o uso
 de pronomes.
 
-Veja :ref:`describe_changes` para mais informações, com uma ressalva: comece com
+Veja :ref:`pt_BR_describe_changes` para mais informações, com uma ressalva: comece com
 uma breve descrição das mudanças reais e, em seguida, apresente o contexto e o
 histórico. Note! Esta ordem entra em conflito direto com a abordagem preferida
 da árvore "tip"! Por favor, siga o estilo preferido da árvore "tip" ao enviar
@@ -431,5 +431,5 @@ Bugs que podem ser explorados pelo convidado (guest) para atacar o hospedeiro
 (host) (kernel ou espaço do usuário), ou que podem ser explorados por uma VM
 aninhada (nested) contra o *seu* próprio hospedeiro (L2 atacando L1), são de
 interesse particular para o KVM. Por favor, siga o protocolo em
-:ref:`securitybugs` se você suspeitar que um bug possa levar a um escape,
-vazamento de dados, etc.
+:ref:`pt_BR_securitybugs` se você suspeitar que um bug possa levar a um
+escape, vazamento de dados, etc.
diff --git a/Documentation/translations/pt_BR/process/maintainer-soc-clean-dts.rst b/Documentation/translations/pt_BR/process/maintainer-soc-clean-dts.rst
index a7e7bf0f106f..7256c71534a7 100644
--- a/Documentation/translations/pt_BR/process/maintainer-soc-clean-dts.rst
+++ b/Documentation/translations/pt_BR/process/maintainer-soc-clean-dts.rst
@@ -8,8 +8,9 @@ Visão Geral
 -----------
 
 As plataformas SoC ou subarquiteturas devem seguir todas as regras de
-Documentation/process/maintainer-soc.rst. Este documento, referenciado em
-MAINTAINERS, impõe requisitos adicionais listados abaixo.
+Documentation/translations/pt_BR/process/maintainer-soc.rst. Este
+documento, referenciado em MAINTAINERS, impõe requisitos adicionais
+listados abaixo.
 
 Conformidade Estrita com DT Schema de DTS e dtc
 -----------------------------------------------
diff --git a/Documentation/translations/pt_BR/process/maintainer-tip.rst b/Documentation/translations/pt_BR/process/maintainer-tip.rst
new file mode 100644
index 000000000000..e583bad4282d
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/maintainer-tip.rst
@@ -0,0 +1,847 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+O manual da árvore tip
+======================
+
+O que é a árvore tip?
+---------------------
+
+A árvore tip é uma coleção de vários subsistemas e áreas de
+desenvolvimento. A árvore tip é tanto uma árvore de desenvolvimento direto quanto uma
+árvore de agregação para várias árvores de sub-mantenedores. A URL gitweb da árvore tip
+é: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
+
+A árvore tip contém os seguintes subsistemas:
+
+   - **Arquitetura x86**
+
+     O desenvolvimento da arquitetura x86 ocorre na árvore tip, exceto
+     pelas partes específicas do KVM e XEN no x86, que são mantidas nos
+     subsistemas correspondentes e roteadas diretamente para a mainline a partir
+     dali. Ainda é uma boa prática enviar Cc para os mantenedores x86 nos
+     patches do KVM e XEN específicos para x86.
+
+     Alguns subsistemas x86 têm seus próprios mantenedores além dos
+     mantenedores gerais do x86. Por favor, envie Cc para os mantenedores gerais do x86 em
+     patches que toquem em arquivos em arch/x86, mesmo quando não forem indicados
+     pelo arquivo MAINTAINER.
+
+     Note que ``x86@kernel.org`` não é uma lista de discussão. É meramente um
+     alias de e-mail que distribui mensagens para a equipe de mantenedores de nível superior
+     do x86. Por favor, sempre envie Cc para a lista de discussão do Linux Kernel (LKML)
+     ``linux-kernel@vger.kernel.org``, caso contrário, seu e-mail acabará apenas nas
+     caixas de entrada privadas dos mantenedores.
+
+   - **Scheduler**
+
+     O desenvolvimento do scheduler ocorre na árvore -tip, na
+     branch sched/core - com ocasionais árvores de subtópicos para
+     conjuntos de patches em progresso.
+
+   - **Locking e atomics**
+
+     O desenvolvimento de locking (incluindo atomics e outras primitivas de
+     sincronização que estão conectadas ao locking) ocorre na árvore -tip,
+     na branch locking/core - com ocasionais árvores de subtópicos
+     para conjuntos de patches em progresso.
+
+   - **Subsistema genérico de interrupções e drivers de chip de interrupção**:
+
+     - o desenvolvimento do núcleo de interrupções ocorre na branch irq/core
+
+     - o desenvolvimento do driver de chip de interrupção também ocorre na branch
+       irq/core, mas os patches geralmente são aplicados em uma árvore de mantenedor
+       separada e depois agregados na irq/core
+
+   - **Tempo, timers, timekeeping, NOHZ e drivers de chip relacionados**:
+
+     - o desenvolvimento do timekeeping, núcleo clocksource, NTP e alarmtimer
+       ocorre na branch timers/core, mas os patches geralmente são aplicados em
+       uma árvore de mantenedor separada e depois agregados na timers/core
+
+     - o desenvolvimento do driver clocksource/event ocorre na branch
+       timers/core, mas os patches são em sua maioria aplicados em uma árvore de mantenedor
+       separada e depois agregados na timers/core
+
+   - **Núcleo de contadores de desempenho, suporte a arquitetura e ferramentas**:
+
+     - o desenvolvimento do núcleo perf e suporte a arquitetura ocorre na
+       branch perf/core
+
+     - o desenvolvimento de ferramentas perf ocorre na árvore do mantenedor
+       de ferramentas perf e é agregado à árvore tip.
+
+   - **Núcleo de hotplug de CPU**
+
+   - **Núcleo RAS**
+
+     Em sua maioria, os patches RAS específicos para x86 são coletados na branch
+     ras/core da árvore tip.
+
+   - **Núcleo EFI**
+
+     Desenvolvimento EFI na árvore git efi. Os patches coletados são
+     agregados na branch efi/core da árvore tip.
+
+   - **RCU**
+
+     O desenvolvimento do RCU ocorre na árvore linux-rcu. As mudanças resultantes
+     são agregadas na branch core/rcu da árvore tip.
+
+   - **Vários componentes de código do núcleo**:
+
+       - debugobjects
+
+       - objtool
+
+       - partes e peças aleatórias
+
+
+Notas de submissão de patch
+---------------------------
+
+Selecionando a árvore/branch
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Em geral, o desenvolvimento contra o head da branch master da árvore tip é
+adequado, mas para os subsistemas que são mantidos separadamente, possuem sua
+própria árvore git e são apenas agregados na árvore tip, o desenvolvimento deve
+ocorrer contra a árvore ou branch do subsistema relevante.
+
+Correções de bugs que visam a mainline devem sempre ser aplicáveis contra a
+árvore do kernel mainline. Potenciais conflitos contra mudanças que já estão
+na fila da árvore tip são resolvidos pelos mantenedores.
+
+Assunto do patch
+^^^^^^^^^^^^^^^^
+
+O formato preferido da árvore tip para prefixos de assunto do patch é
+'subsys/component:', ex. 'x86/apic:', 'x86/mm/fault:', 'sched/fair:',
+'genirq/core:'. Por favor, não use nomes de arquivos ou caminhos de arquivos completos como
+prefixo. 'git log path/to/file' deve lhe dar uma dica razoável na maioria
+dos casos.
+
+A descrição condensada do patch na linha de assunto deve começar com uma
+letra maiúscula e deve ser escrita em tom imperativo.
+
+
+Changelog
+^^^^^^^^^
+
+As regras gerais sobre changelogs no :ref:`Guia de submissão de patches
+<pt_BR_describe_changes>`, se aplicam.
+
+Os mantenedores da árvore tip valorizam seguir essas regras, especialmente no
+pedido para escrever changelogs no modo imperativo e não personificando
+o código ou sua execução. Isso não é apenas um capricho dos
+mantenedores. Changelogs escritos em palavras abstratas são mais precisos e
+tendem a ser menos confusos do que aqueles escritos em forma de romances.
+
+Também é útil estruturar o changelog em vários parágrafos e não
+juntar tudo em um só. Uma boa estrutura é explicar
+o contexto, o problema e a solução em parágrafos separados e nesta
+ordem.
+
+Exemplos para ilustração:
+
+  Exemplo 1::
+
+    x86/intel_rdt/mbm: Corrigir o manipulador de overflow do MBM durante hot cpu
+
+    Quando uma CPU está morrendo, cancelamos o worker e agendamos um novo worker em uma
+    CPU diferente no mesmo domínio. Mas se o timer já está prestes a
+    expirar (digamos 0.99s) então essencialmente dobramos o intervalo.
+
+    Modificamos o tratamento de hot cpu para cancelar o trabalho atrasado na cpu
+    que está morrendo e executar o worker imediatamente em uma cpu diferente no mesmo domínio. Não
+    fazemos o flush do worker porque o worker de overflow do MBM reagenda o
+    worker na mesma CPU e escaneia a domain->cpu_mask para obter o ponteiro
+    do domínio.
+
+  Versão melhorada::
+
+    x86/intel_rdt/mbm: Corrigir o manipulador de overflow do MBM durante hotplug de CPU
+
+    Quando uma CPU está morrendo, o worker de overflow é cancelado e reagendado em uma
+    CPU diferente no mesmo domínio. Mas se o timer já estiver prestes a
+    expirar isso essencialmente dobra o intervalo, o que pode resultar em um overflow
+    não detectado.
+
+    Cancele o worker de overflow e reagende-o imediatamente em uma CPU diferente
+    no mesmo domínio. O trabalho também poderia sofrer um flush, mas isso iria
+    reagendá-lo na mesma CPU.
+
+  Exemplo 2::
+
+    time: POSIX CPU timers: Garantir que a variável seja inicializada
+
+    Se cpu_timer_sample_group retornar -EINVAL, ela não terá escrito em
+    *sample. Checar o valor de retorno de cpu_timer_sample_group previne o
+    uso potencial de um valor não inicializado de now no bloco seguinte.
+    Dado um clock_idx inválido, o código anterior poderia caso contrário sobrescrever
+    *oldval de maneira indefinida. Isso agora é prevenido. Também exploramos
+    o curto-circuito do && para amostrar o timer apenas se o resultado for
+    realmente usado para atualizar *oldval.
+
+  Versão melhorada::
+
+    posix-cpu-timers: Tornar set_process_cpu_timer() mais robusto
+
+    Como o valor de retorno de cpu_timer_sample_group() não é checado,
+    compiladores e checadores estáticos podem legitimamente avisar sobre um uso potencial
+    da variável não inicializada 'now'. Isso não é um problema de tempo de execução pois todos
+    os locais de chamada passam ids de clock válidos.
+
+    Além disso, cpu_timer_sample_group() é invocado incondicionalmente mesmo quando o
+    resultado não é usado porque *oldval é NULL.
+
+    Torne a invocação condicional e cheque o valor de retorno.
+
+  Exemplo 3::
+
+    A entidade também pode ser usada para outros propósitos.
+
+    Vamos renomeá-la para ser mais genérica.
+
+  Versão melhorada::
+
+    A entidade também pode ser usada para outros propósitos.
+
+    Renomeie para ser mais genérica.
+
+
+Para cenários complexos, especialmente condições de corrida (race conditions) e problemas
+de ordenação de memória, é valioso descrever o cenário com uma tabela que mostra
+o paralelismo e a ordem temporal dos eventos. Aqui está um exemplo::
+
+    CPU0                            CPU1
+    free_irq(X)                     interrupt X
+                                    spin_lock(desc->lock)
+                                    wake irq thread()
+                                    spin_unlock(desc->lock)
+    spin_lock(desc->lock)
+    remove action()
+    shutdown_irq()
+    release_resources()             thread_handler()
+    spin_unlock(desc->lock)           access released resources.
+                                      ^^^^^^^^^^^^^^^^^^^^^^^^^
+    synchronize_irq()
+
+O Lockdep fornece uma saída útil semelhante para descrever um possível cenário
+de deadlock::
+
+    CPU0                                    CPU1
+    rtmutex_lock(&rcu->rt_mutex)
+      spin_lock(&rcu->rt_mutex.wait_lock)
+                                            local_irq_disable()
+                                            spin_lock(&timer->it_lock)
+                                            spin_lock(&rcu->mutex.wait_lock)
+    --> Interrupt
+        spin_lock(&timer->it_lock)
+
+Referências a funções em changelogs
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Quando uma função é mencionada no changelog, seja no corpo do texto ou na
+linha de assunto, por favor use o formato 'nome_da_funcao()'. Omitir os
+parênteses após o nome da função pode ser ambíguo::
+
+  Subject: subsys/component: Make reservation_count static
+
+  reservation_count is only used in reservation_stats. Make it static.
+
+A variante com parênteses é mais precisa::
+
+  Subject: subsys/component: Make reservation_count() static
+
+  reservation_count() is only called from reservation_stats(). Make it
+  static.
+
+
+Backtraces em changelogs
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Veja :ref:`pt_BR_backtraces`.
+
+Ordenação das tags de commit
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Para ter uma visão uniforme das tags de commit, os mantenedores da tip usam o
+seguinte esquema de ordenação de tags:
+
+ - Fixes: 12+char-SHA1 ("sub/sys: Original subject line")
+
+   Uma tag Fixes deve ser adicionada mesmo para alterações que não precisam ser
+   portadas de volta (backported) para kernels estáveis, ou seja, quando abordar um
+   problema recém-introduzido que afeta apenas a árvore tip ou o head atual da linha principal (mainline). Estas tags
+   são úteis para identificar o commit original e são muito mais valiosas
+   do que mencionar de forma proeminente o commit que introduziu um problema no
+   próprio texto do changelog, porque elas podem ser automaticamente
+   extraídas.
+
+   O exemplo a seguir ilustra a diferença::
+
+     Commit
+
+       abcdef012345678 ("x86/xxx: Replace foo with bar")
+
+     deixou uma instância não utilizada da variável foo. Remova-a.
+
+     Signed-off-by: J.Dev <j.dev@mail>
+
+   Por favor, diga em vez disso::
+
+     A recente substituição de foo por bar deixou uma instância não utilizada da
+     variável foo. Remova-a.
+
+     Fixes: abcdef012345678 ("x86/xxx: Replace foo with bar")
+     Signed-off-by: J.Dev <j.dev@mail>
+
+   O último coloca as informações sobre o patch em foco e
+   as complementa com a referência ao commit que introduziu o problema,
+   em vez de colocar o foco no commit original em primeiro lugar.
+
+ - Reported-by: ``Reporter <reporter@mail>``
+
+ - Closes: ``URL or Message-ID of the bug report this is fixing``
+
+ - Originally-by: ``Original author <original-author@mail>``
+
+ - Suggested-by: ``Suggester <suggester@mail>``
+
+ - Co-developed-by: ``Co-author <co-author@mail>``
+
+   Signed-off-by: ``Co-author <co-author@mail>``
+
+   Note que Co-developed-by e Signed-off-by do(s) co-autor(es) devem
+   vir em pares.
+
+ - Signed-off-by: ``Author <author@mail>``
+
+   O primeiro Signed-off-by (SOB) após o último par Co-developed-by/SOB é o
+   SOB do autor, ou seja, a pessoa marcada como autora pelo git.
+
+ - Signed-off-by: ``Patch handler <handler@mail>``
+
+   SOBs após o SOB do autor são de pessoas que lidam e transportam
+   o patch, mas não estiveram envolvidas no desenvolvimento. As cadeias de SOB devem
+   refletir a rota **real** que um patch tomou conforme foi propagado para nós,
+   com a primeira entrada de SOB sinalizando a autoria principal de um único
+   autor. Acks devem ser dados como linhas Acked-by e aprovações de revisão
+   como linhas Reviewed-by.
+
+   Se o manipulador fez modificações no patch ou no changelog, então
+   isso deve ser mencionado **após** o texto do changelog e **acima**
+   de todas as tags de commit no seguinte formato::
+
+     ... o texto do changelog termina.
+
+     [ handler: Substituiu foo por bar e atualizou o changelog ]
+
+     First-tag: .....
+
+   Observe as duas novas linhas vazias que separam o texto do changelog e as
+   tags de commit daquele aviso.
+
+   Se um patch for enviado para a lista de discussão por um manipulador, então o autor tem
+   que ser notado na primeira linha do changelog com::
+
+     From: Author <author@mail>
+
+     O texto do changelog começa aqui....
+
+   assim a autoria é preservada. A linha 'From:' tem que ser seguida
+   por uma nova linha vazia. Se essa linha 'From:' estiver faltando, então o patch
+   seria atribuído à pessoa que o enviou (transportou, manipulou).
+   A linha 'From:' é automaticamente removida quando o patch é aplicado
+   e não aparece no changelog final do git. Ela meramente afeta
+   a informação de autoria do commit resultante do Git.
+
+ - Tested-by: ``Tester <tester@mail>``
+
+ - Reviewed-by: ``Reviewer <reviewer@mail>``
+
+ - Acked-by: ``Acker <acker@mail>``
+
+ - Cc: ``cc-ed-person <person@mail>``
+
+   Se o patch deve ser portado para stable, então por favor adicione uma tag '``Cc:
+   stable@vger.kernel.org``', mas não coloque em Cc o stable ao enviar o seu
+   e-mail.
+
+ - Link: ``https://link/to/information``
+
+   Para se referir a um e-mail postado nas listas de discussão do kernel, por favor
+   use o URL de redirecionamento lore.kernel.org::
+
+     Link: https://lore.kernel.org/email-message-id@here
+
+   Esta URL deve ser usada ao se referir a tópicos de lista de discussão relevantes,
+   conjuntos de patches relacionados, ou outras threads de discussão notáveis.
+   Uma maneira conveniente de associar os trailers ``Link:`` com a mensagem de commit
+   é usar a notação de colchetes semelhante ao markdown, por exemplo::
+
+     A similar approach was attempted before as part of a different
+     effort [1], but the initial implementation caused too many
+     regressions [2], so it was backed out and reimplemented.
+
+     Link: https://lore.kernel.org/some-msgid@here # [1]
+     Link: https://bugzilla.example.org/bug/12345  # [2]
+
+   Você também pode usar os trailers ``Link:`` para indicar a origem do
+   patch ao aplicá-lo em sua árvore git. Neste caso, por favor use o
+   domínio dedicado ``patch.msgid.link`` em vez de ``lore.kernel.org``.
+   Esta prática torna possível que as ferramentas automatizadas identifiquem
+   qual link usar para recuperar o envio do patch original. Por
+   exemplo::
+
+     Link: https://patch.msgid.link/patch-source-message-id@here
+
+Por favor não use tags combinadas, ex. ``Reported-and-tested-by``, pois
+elas apenas complicam a extração automatizada de tags.
+
+
+Links para documentação
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Fornecer links para a documentação no changelog é uma grande ajuda para depuração e
+análise posteriores. Infelizmente, os URLs costumam quebrar muito rapidamente
+porque as empresas reestruturam seus sites frequentemente. Exceções não 'voláteis'
+incluem o Intel SDM e o AMD APM.
+
+Portanto, para documentos 'voláteis', por favor crie uma entrada no bugzilla do kernel
+https://bugzilla.kernel.org e anexe uma cópia desses documentos
+à entrada do bugzilla. Finalmente, forneça o URL da entrada do bugzilla no
+changelog.
+
+Reenvio de patch ou lembretes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Veja :ref:`pt_BR_resend_reminders`.
+
+Janela de merge
+^^^^^^^^^^^^^^^
+
+Por favor, não espere que os patches sejam revisados ou mesclados pelos mantenedores da árvore tip
+em torno ou durante a janela de merge. As árvores ficam fechadas
+para todos, exceto correções urgentes, durante esse tempo. Elas reabrem assim que a janela de merge
+fecha e um novo kernel -rc1 é lançado.
+
+Grandes séries devem ser enviadas em estado mesclável (mergeable state) *pelo* *menos* uma semana
+antes da janela de merge abrir. Exceções são feitas para correções de bugs e
+*às vezes* para pequenos drivers independentes para novos hardwares ou patches minimamente
+invasivos para ativação de hardware.
+
+Durante a janela de merge, os mantenedores se concentram em seguir as
+alterações upstream, corrigir problemas resultantes da janela de merge, coletar correções de bugs, e
+se permitir um respiro. Por favor, respeite isso.
+
+Os chamados branches _urgent_ serão mesclados na linha principal (mainline) durante a
+fase de estabilização de cada versão.
+
+
+Git
+^^^
+
+Os mantenedores da árvore tip aceitam pull requests do git de mantenedores que fornecem
+alterações de subsistema para agregação na árvore tip.
+
+Pull requests para novos envios de patches normalmente não são aceitos e não
+substituem o envio adequado de patch para a lista de discussão. O principal motivo para
+isso é que o fluxo de trabalho de revisão é baseado em e-mail.
+
+Se você enviar uma série maior de patches, é útil fornecer um branch git
+em um repositório privado que permita que pessoas interessadas façam pull da
+série facilmente para testes. A maneira usual de oferecer isso é uma URL do git na carta de apresentação (cover letter)
+da série de patches.
+
+Testes
+^^^^^^
+
+O código deve ser testado antes de ser enviado para os mantenedores da árvore tip. Qualquer coisa
+além de alterações menores deve ser construída, inicializada e testada com
+opções abrangentes (e pesadas) de depuração do kernel ativadas.
+
+Essas opções de depuração podem ser encontradas em kernel/configs/x86_debug.config
+e podem ser adicionadas a uma configuração de kernel existente executando:
+
+	make x86_debug.config
+
+Algumas dessas opções são específicas do x86 e podem ser deixadas de fora ao testar
+em outras arquiteturas.
+
+.. _pt_BR_maintainer-tip-coding-style:
+
+Notas de estilo de código
+-------------------------
+
+Estilo de comentário
+^^^^^^^^^^^^^^^^^^^^
+
+Frases em comentários começam com uma letra maiúscula.
+
+Comentários de linha única::
+
+	/* Este é um comentário de linha única */
+
+Comentários de várias linhas::
+
+	/*
+	 * This is a properly formatted
+	 * multi-line comment.
+	 *
+	 * Larger multi-line comments should be split into paragraphs.
+	 */
+
+Sem comentários no fim da linha (veja abaixo):
+
+  Por favor, abstenha-se de usar comentários no fim da linha. Comentários no fim da linha atrapalham o
+  fluxo de leitura em quase todos os contextos, mas especialmente em código::
+
+	if (somecondition_is_true) /* Não coloque um comentário aqui */
+		dostuff(); /* Nem aqui */
+
+	seed = MAGIC_CONSTANT; /* Nem aqui */
+
+  Use comentários independentes em vez disso::
+
+	/* Esta condição não é óbvia sem um comentário */
+	if (somecondition_is_true) {
+		/* Isso realmente precisa ser documentado */
+		dostuff();
+	}
+
+	/* Esta inicialização mágica precisa de um comentário. Talvez não? */
+	seed = MAGIC_CONSTANT;
+
+  Use o estilo C++, comentários no fim da linha ao documentar structs em headers para
+  alcançar um layout mais compacto e melhor legibilidade::
+
+        // eax
+        u32     x2apic_shift    :  5, // Número de bits para deslocar o ID APIC para a direita
+                                      // para o ID de topologia no próximo nível
+                                : 27; // Reservado
+        // ebx
+        u32     num_processors  : 16, // Número de processadores no nível atual
+                                : 16; // Reservado
+
+  versus::
+
+	/* eax */
+	        /*
+	         * Número de bits para deslocar o ID APIC para a direita para o ID de topologia
+	         * no próximo nível
+	         */
+         u32     x2apic_shift    :  5,
+		 /* Reservado */
+				 : 27;
+
+	/* ebx */
+		/* Número de processadores no nível atual */
+	u32     num_processors  : 16,
+		/* Reservado */
+				: 16;
+
+Comente as coisas importantes:
+
+  Comentários devem ser adicionados onde a operação não é óbvia. Documentar
+  o óbvio é apenas uma distração::
+
+	/* Decrementa o refcount e verifica por zero */
+	if (refcount_dec_and_test(&p->refcnt)) {
+		do;
+		lots;
+		of;
+		magic;
+		things;
+	}
+
+  Em vez disso, os comentários devem explicar os detalhes não óbvios e documentar
+  as restrições::
+
+	if (refcount_dec_and_test(&p->refcnt)) {
+		/*
+		 * Explicação muito boa de por que as coisas mágicas abaixo
+		 * precisam ser feitas, restrições de ordenação e locking,
+		 * etc..
+		 */
+		do;
+		lots;
+		of;
+		magic;
+		/* Precisa ser a última operação porque ... */
+		things;
+	}
+
+Comentários de documentação de função:
+
+  Para documentar funções e seus argumentos por favor use o formato kernel-doc
+  e não comentários de formato livre::
+
+	/**
+	 * magic_function - Faz muitas coisas mágicas
+	 * @magic:	Ponteiro para os dados mágicos nos quais operar
+	 * @offset:	Deslocamento no array de dados de @magic
+	 *
+	 * Explicação profunda das coisas misteriosas feitas com @magic junto
+         * com a documentação dos valores de retorno.
+	 *
+	 * Note que os descritores de argumento acima estão dispostos
+	 * de forma tabular.
+	 */
+
+  Isto se aplica especialmente a funções visíveis globalmente e funções
+  inline em arquivos de cabeçalho públicos. Pode ser um exagero usar o formato
+  kernel-doc para cada função (estática) que precisa de uma pequena explicação. O
+  uso de nomes de funções descritivos frequentemente substitui esses pequenos comentários.
+  Aplique o bom senso como sempre.
+
+
+Documentando requisitos de locking
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  Documentar requisitos de locking é uma coisa boa, mas comentários não
+  são necessariamente a melhor escolha. Em vez de escrever::
+
+	/* Caller must hold foo->lock */
+	void func(struct foo *foo)
+	{
+		...
+	}
+
+  Por favor, use::
+
+	void func(struct foo *foo)
+	{
+		lockdep_assert_held(&foo->lock);
+		...
+	}
+
+  Em kernels PROVE_LOCKING, lockdep_assert_held() emite um aviso
+  se o chamador não detém o lock. Comentários não podem fazer isso.
+
+Regras de chaves
+^^^^^^^^^^^^^^^^
+
+Chaves devem ser omitidas apenas se a instrução que se segue a 'if', 'for',
+'while' etc. for verdadeiramente uma única linha::
+
+	if (foo)
+		do_something();
+
+O seguinte não é considerado uma instrução de linha única mesmo
+que o C não exija chaves::
+
+	for (i = 0; i < end; i++)
+		if (foo[i])
+			do_something(foo[i]);
+
+Adicionar chaves ao redor do loop externo melhora o fluxo de leitura::
+
+	for (i = 0; i < end; i++) {
+		if (foo[i])
+			do_something(foo[i]);
+	}
+
+
+Declarações de variáveis
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+A ordem preferida das declarações de variáveis no início de uma
+função é a ordem de árvore de abeto invertida (reverse fir tree order)::
+
+	struct long_struct_name *descriptive_name;
+	unsigned long foo, bar;
+	unsigned int tmp;
+	int ret;
+
+O que está acima é mais rápido de analisar do que a ordem invertida::
+
+	int ret;
+	unsigned int tmp;
+	unsigned long foo, bar;
+	struct long_struct_name *descriptive_name;
+
+E ainda mais do que uma ordem aleatória::
+
+	unsigned long foo, bar;
+	int ret;
+	struct long_struct_name *descriptive_name;
+	unsigned int tmp;
+
+Também por favor tente agregar variáveis do mesmo tipo em uma única
+linha. Não há sentido em desperdiçar espaço na tela::
+
+	unsigned long a;
+	unsigned long b;
+	unsigned long c;
+	unsigned long d;
+
+É realmente suficiente fazer::
+
+	unsigned long a, b, c, d;
+
+Por favor, evite também introduzir divisões de linha em declarações de variáveis::
+
+	struct long_struct_name *descriptive_name = container_of(bar,
+						      struct long_struct_name,
+	                                              member);
+	struct foobar foo;
+
+É muito melhor mover a inicialização para uma linha separada após as
+declarações::
+
+	struct long_struct_name *descriptive_name;
+	struct foobar foo;
+
+	descriptive_name = container_of(bar, struct long_struct_name, member);
+
+
+Tipos de variáveis
+^^^^^^^^^^^^^^^^^^
+
+Por favor use os tipos u8, u16, u32, u64 adequados para variáveis que são destinadas
+a descrever hardware ou são usadas como argumentos para funções que acessam
+hardware. Estes tipos definem claramente a largura em bits e evitam
+truncamento, expansão e confusão entre 32/64 bits.
+
+u64 também é recomendado em código que se tornaria ambíguo para kernels
+de 32 bits quando 'unsigned long' fosse usado em vez disso. Embora em tais
+situações 'unsigned long long' pudesse ser usado também, u64 é mais curto
+e também mostra claramente que a operação requer uma largura de 64 bits
+independente da CPU alvo.
+
+Por favor use 'unsigned int' em vez de 'unsigned'.
+
+
+Constantes
+^^^^^^^^^^
+
+Por favor, não use números (hexa)decimais literais em código ou inicializadores.
+Ou use defines adequados que tenham nomes descritivos ou considere usar
+um enum.
+
+
+Declarações e inicializadores de struct
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+As declarações de struct devem alinhar os nomes dos membros da struct de forma
+tabular::
+
+	struct bar_order {
+		unsigned int	guest_id;
+		int		ordered_item;
+		struct menu	*menu;
+	};
+
+Por favor, evite documentar os membros da struct dentro da declaração, pois
+isso frequentemente resulta em comentários formatados de maneira estranha e os membros da struct
+ficam ofuscados::
+
+	struct bar_order {
+		unsigned int	guest_id; /* ID único do convidado */
+		int		ordered_item;
+		/* Ponteiro para uma instância de menu que contém todas as bebidas */
+		struct menu	*menu;
+	};
+
+Em vez disso, por favor considere usar o formato kernel-doc em um comentário precedendo
+a declaração da struct, que é mais fácil de ler e tem a vantagem adicional
+de incluir a informação na documentação do kernel, por exemplo, da
+seguinte forma::
+
+
+	/**
+	 * struct bar_order - Descrição de um pedido de bar
+	 * @guest_id:		ID único do convidado
+	 * @ordered_item:	O número do item do menu
+	 * @menu:		Ponteiro para o menu do qual o item
+	 *  			foi pedido
+	 *
+	 * Informação suplementar para usar a struct.
+	 *
+	 * Note que os descritores dos membros da struct acima estão dispostos
+	 * de forma tabular.
+	 */
+	struct bar_order {
+		unsigned int	guest_id;
+		int		ordered_item;
+		struct menu	*menu;
+	};
+
+Inicializadores de struct estáticos devem usar inicializadores C99 e também devem ser
+alinhados de forma tabular::
+
+	static struct foo statfoo = {
+		.a		= 0,
+		.plain_integer	= CONSTANT_DEFINE_OR_ENUM,
+		.bar		= &statbar,
+	};
+
+Note que embora a sintaxe C99 permita a omissão da vírgula final,
+nós recomendamos o uso de uma vírgula na última linha porque isso torna
+o reordenamento e a adição de novas linhas mais fáceis, e também torna tais
+patches futuros ligeiramente mais fáceis de ler.
+
+Quebras de linha
+^^^^^^^^^^^^^^^^
+
+Restringir o comprimento da linha a 80 caracteres torna código profundamente indentado difícil de
+ler. Considere dividir o código em funções auxiliares para evitar quebra de
+linha excessiva.
+
+A regra de 80 caracteres não é uma regra estrita, então por favor use bom senso ao
+quebrar linhas. Especialmente strings de formato nunca devem ser divididas.
+
+Ao dividir declarações de funções ou chamadas de funções, então por favor alinhe
+o primeiro argumento na segunda linha com o primeiro argumento na primeira
+linha::
+
+  static int long_function_name(struct foobar *barfoo, unsigned int id,
+				unsigned int offset)
+  {
+
+	if (!id) {
+		ret = longer_function_name(barfoo, DEFAULT_BARFOO_ID,
+					   offset);
+	...
+
+Namespaces
+^^^^^^^^^^
+
+Namespaces de funções/variáveis melhoram a legibilidade e permitem
+grepping fácil. Estes namespaces são prefixos de string para nomes
+de funções e variáveis visíveis globalmente, incluindo inlines. Estes prefixos devem
+combinar o subsistema e o nome do componente como 'x86_comp\_',
+'sched\_', 'irq\_', e 'mutex\_'.
+
+Isso também inclui funções estáticas de escopo de arquivo que são imediatamente colocadas
+em templates de driver visíveis globalmente - é útil que esses símbolos
+também carreguem um bom prefixo, para legibilidade do backtrace.
+
+Prefixos de namespace podem ser omitidos para funções e variáveis
+estáticas locais. Funções verdadeiramente locais, chamadas apenas por outras funções locais,
+podem ter nomes descritivos mais curtos - nossa preocupação principal é a facilidade de grepping
+e a legibilidade do backtrace.
+
+Por favor note que os prefixos 'xxx_vendor\_' e 'vendor_xxx\_' não são
+úteis para funções estáticas em arquivos específicos de fornecedores. Afinal,
+já está claro que o código é específico do fornecedor. Além disso, nomes
+de fornecedores devem ser apenas para funcionalidades verdadeiramente específicas de fornecedores.
+
+Como sempre, aplique o bom senso e vise a consistência e a legibilidade.
+
+
+Notificações de commit
+----------------------
+
+A árvore tip é monitorada por um bot por novos commits. O bot envia um email
+para cada novo commit para uma lista de discussão dedicada
+(``linux-tip-commits@vger.kernel.org``) e coloca em Cc todas as pessoas que são
+mencionadas em uma das tags de commit. Ele usa o ID da mensagem de email da
+tag Link no final da lista de tags para definir o cabeçalho de email In-Reply-To para que
+a mensagem seja encadeada corretamente com o email de submissão do patch.
+
+Os mantenedores e submantenedores tip tentam responder ao remetente
+ao fazer o merge de um patch, mas às vezes eles esquecem ou isso não se encaixa no
+fluxo de trabalho do momento. Embora a mensagem do bot seja puramente mecânica, ela
+também implica em um 'Obrigado! Aplicado.'.
diff --git a/Documentation/translations/pt_BR/process/management-style.rst b/Documentation/translations/pt_BR/process/management-style.rst
index b92f8705c30f..9d067e04650a 100644
--- a/Documentation/translations/pt_BR/process/management-style.rst
+++ b/Documentation/translations/pt_BR/process/management-style.rst
@@ -1,13 +1,16 @@
 .. SPDX-License-Identifier: GPL-2.0
 
+.. _pt_BR_managementstyle:
+
 Estilo de gerenciamento do kernel Linux
 =======================================
 
 Este é um documento curto descrevendo o estilo de gerenciamento preferido (ou
 inventado, dependendo de quem você perguntar) para o kernel do Linux. Ele se
-destina a espelhar o documento :ref:`process/coding-style.rst <codingstyle>` em
-algum grau, e foi escrito principalmente para evitar responder [#f1]_ as mesmas
-(ou semelhantes) perguntas repetidamente.
+destina a espelhar o documento
+:ref:`Documentation/translations/pt_BR/process/coding-style.rst <pt_BR_codingstyle>`
+em algum grau, e foi escrito principalmente para evitar responder [#f1]_ as
+mesmas (ou semelhantes) perguntas repetidamente.
 
 Estilo de gerenciamento é muito pessoal e muito mais difícil de quantificar do
 que simples regras de estilo de codificação, então este documento pode ou não ter
diff --git a/Documentation/translations/pt_BR/process/security-bugs.rst b/Documentation/translations/pt_BR/process/security-bugs.rst
index 72c771869566..321575657b28 100644
--- a/Documentation/translations/pt_BR/process/security-bugs.rst
+++ b/Documentation/translations/pt_BR/process/security-bugs.rst
@@ -1,5 +1,7 @@
 .. SPDX-License-Identifier: GPL-2.0
 
+.. _pt_BR_securitybugs:
+
 Falhas de segurança
 ===================
 
@@ -59,11 +61,11 @@ Além disso, as seguintes informações são altamente desejáveis:
     mantenedores, mesmo que a correção acabe não sendo a correta, pois ajuda a
     entender o bug. Ao propor uma correção testada, por favor, formate-a
     sempre de uma maneira que possa ser mesclada imediatamente (consulte
-    Documentation/process/submitting-patches.rst). Isso evitará algumas trocas
-    de mensagens caso ela seja aceita, e você receberá o crédito por
-    encontrar e corrigir o problema. Observe que, neste caso, apenas uma tag
-    ``Signed-off-by:`` é necessária, sem ``Reported-by:`` quando o relator e
-    o autor forem a mesma pessoa.
+    Documentation/translations/pt_BR/process/submitting-patches.rst). Isso
+    evitará algumas trocas de mensagens caso ela seja aceita, e você receberá
+    o crédito por encontrar e corrigir o problema. Observe que, neste caso,
+    apenas uma tag ``Signed-off-by:`` é necessária, sem ``Reported-by:``
+    quando o relator e o autor forem a mesma pessoa.
 
   * **mitigações**: com muita frequência, durante a análise de um bug,
     surgem algumas maneiras de mitigar o problema. É útil compartilhá-las,
@@ -228,8 +230,8 @@ a tornar esses relatórios desnecessariamente difíceis de lidar:
     Se a correção não puder ser testada porque depende de hardware raro ou de
     protocolos de rede quase extintos, é provável que o problema não seja um
     bug de segurança. Em qualquer caso, se uma correção for proposta, ela deve
-    aderir a Documentation/process/submitting-patches.rst e incluir uma tag
-    'Fixes:' designando o commit que introduziu o bug.
+    aderir a Documentation/translations/pt_BR/process/submitting-patches.rst
+    e incluir uma tag 'Fixes:' designando o commit que introduziu o bug.
 
 A falha em considerar estes pontos expõe seu relatório ao risco de ser
 ignorado.
@@ -280,7 +282,7 @@ entender e corrigir a vulnerabilidade de segurança.
 Por favor, envie e-mails em **texto simples** sem anexos, sempre que possível.
 É muito mais difícil ter uma discussão com citações de contexto sobre um
 problema complexo se todos os detalhes estiverem ocultos em anexos. Pense nisso
-como uma :doc:`regular path submission </../../../process/submitting-patches>`
+como uma :doc:`submissão pelo caminho normal <submitting-patches>`
 (mesmo que você ainda não tenha um patch): descreva o problema e o impacto,
 liste as etapas de reprodução e siga com uma proposta de correção, tudo em
 texto simples. Relatórios formatados em Markdown, HTML e RST são
@@ -288,8 +290,9 @@ particularmente malvistos, pois são bastante difíceis de ler por humanos e
 incentivam o uso de visualizadores dedicados, às vezes online, o que por
 definição não é aceitável para um relatório de segurança confidencial. Note
 que alguns clientes de e-mail tendem a corromper a formatação de texto simples
-por padrão; por favor, consulte Documentation/process/email-clients.rst para
-mais informações.
+por padrão; por favor, consulte
+Documentation/translations/pt_BR/process/email-clients.rst para mais
+informações.
 
 Divulgação e informações sob embargo
 ------------------------------------
@@ -359,7 +362,7 @@ A equipe de segurança não atribui CVEs, nem os exigimos para relatórios ou
 correções, pois isso pode complicar desnecessariamente o processo e adiar o
 tratamento do bug. Se um relator desejar que um identificador CVE seja
 atribuído para um problema confirmado, ele pode entrar em contato com a
-:doc:`kernel CVE assignment team<../../../process/cve>` para obter um.
+:doc:`equipe de atribuição de CVEs do kernel <cve>` para obter um.
 
 Acordo de não divulgação
 ------------------------
diff --git a/Documentation/translations/pt_BR/process/stable-api-nonsense.rst b/Documentation/translations/pt_BR/process/stable-api-nonsense.rst
new file mode 100644
index 000000000000..c5d0e643eb32
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/stable-api-nonsense.rst
@@ -0,0 +1,208 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+A interface de drivers do kernel Linux
+=======================================
+
+(todas as suas perguntas respondidas e mais algumas)
+
+Greg Kroah-Hartman <greg@kroah.com>
+
+Este texto foi escrito para tentar explicar por que o Linux **não possui uma
+interface binária do kernel nem uma interface estável do kernel**.
+
+.. note::
+
+   Observe que este artigo descreve as interfaces **internas do kernel**, e não
+   as interfaces entre o kernel e o espaço de usuário.
+
+   A interface entre o kernel e o espaço de usuário é aquela utilizada pelos
+   aplicativos: a interface de chamadas de sistema (syscalls). Essa
+   interface é **muito** estável ao longo do tempo e não será quebrada. Tenho
+   programas antigos, compilados em uma versão do kernel anterior à 0.9 e alguma
+   coisa, que ainda funcionam perfeitamente na versão mais recente do kernel
+   2.6. Essa é a interface cuja estabilidade os usuários e desenvolvedores de
+   aplicativos podem considerar garantida.
+
+
+Resumo executivo
+----------------
+
+Você acha que quer uma interface estável do kernel, mas, na verdade, não quer,
+e nem sabe disso. O que você realmente quer é um driver que continue
+funcionando de maneira estável, e isso só é possível se o seu driver estiver
+na árvore principal do kernel. Você também obtém muitos outros benefícios se
+o seu driver fizer parte da árvore principal do kernel. São esses benefícios
+que ajudaram a tornar o Linux um sistema operacional tão robusto, estável e
+maduro — justamente a razão pela qual você o está usando.
+
+
+Introdução
+----------
+
+Apenas quem escreve drivers para o kernel precisa se preocupar com as mudanças
+nas interfaces internas do kernel. Para a grande maioria das pessoas, essas
+interfaces nem sequer são visíveis e tampouco são motivo de preocupação.
+
+Antes de mais nada, não abordarei **nenhuma** questão jurídica relacionada a
+código-fonte fechado, código-fonte oculto, blobs binários, wrappers de
+código-fonte ou qualquer outro termo usado para descrever drivers do kernel
+cujo código-fonte não seja disponibilizado sob a GPL. Consulte um advogado
+caso tenha alguma dúvida jurídica. Sou programador e, portanto, descreverei
+aqui apenas as questões técnicas (isso não significa que as questões
+jurídicas sejam pouco importantes; elas são reais e você precisa estar sempre
+ciente delas).
+
+Portanto, há dois tópicos principais: interfaces binárias do kernel e
+interfaces estáveis de código-fonte do kernel. Ambos dependem um do outro,
+mas discutiremos primeiro a parte referente às interfaces binárias para
+deixá-la de lado.
+
+
+Interface binária do kernel
+---------------------------
+
+Supondo que tivéssemos uma interface estável de código-fonte para o kernel,
+uma interface binária surgiria naturalmente também, certo? Errado. Considere
+os seguintes fatos sobre o kernel Linux:
+
+  - Dependendo da versão do compilador C utilizada, diferentes estruturas de
+    dados do kernel terão diferentes alinhamentos e poderão até mesmo incluir
+    funções de maneiras distintas (por exemplo, tornando determinadas funções
+    inline ou não). A organização das funções individuais não é tão importante,
+    mas as diferenças no preenchimento das estruturas de dados são muito
+    importantes.
+  - Dependendo das opções selecionadas durante a compilação do kernel, uma
+    grande variedade de comportamentos pode ser assumida pelo kernel:
+
+      - diferentes estruturas podem conter campos diferentes;
+      - algumas funções podem nem sequer ser implementadas (por exemplo,
+        determinados bloqueios são completamente eliminados durante a
+        compilação em kernels sem SMP);
+      - a memória dentro do kernel pode ser alinhada de maneiras diferentes,
+        dependendo das opções de compilação.
+  - O Linux é executado em uma grande variedade de arquiteturas de
+    processadores. Não há como drivers binários compilados para uma arquitetura
+    funcionarem corretamente em outra.
+
+Vários desses problemas podem ser contornados simplesmente compilando o módulo
+para uma configuração específica e exata do kernel, utilizando exatamente o
+mesmo compilador C empregado na compilação do kernel. Isso é suficiente caso
+você queira fornecer um módulo para uma determinada versão de uma distribuição
+Linux específica. Porém, multiplique essa única compilação pelo número de
+distribuições Linux existentes e pelo número de versões suportadas de cada
+distribuição e você rapidamente terá um pesadelo de diferentes opções de
+compilação em diferentes versões. Além disso, cada versão de uma distribuição
+Linux contém vários kernels, cada um ajustado para diferentes tipos de
+hardware (diferentes tipos de processadores e diferentes opções). Portanto,
+mesmo para uma única versão, você precisará criar várias versões do seu módulo.
+
+Acredite em mim: com o tempo, você enlouquecerá se tentar oferecer suporte a
+esse tipo de distribuição. Aprendi isso da maneira mais difícil há muito
+tempo...
+
+Interfaces estáveis de código-fonte do kernel
+----------------------------------------------
+
+Esse é um tópico um pouco mais "volátil" se você conversar com alguém que está
+tentando manter atualizado, ao longo do tempo, um driver do kernel Linux que
+não está na árvore principal do kernel.
+
+O desenvolvimento do kernel Linux é contínuo e ocorre em ritmo acelerado,
+sem desacelerar. Por isso, os desenvolvedores do kernel encontram bugs nas
+interfaces existentes ou descobrem maneiras melhores de fazer as coisas.
+Quando isso acontece, eles corrigem as interfaces atuais para que funcionem
+melhor. Nesse processo, nomes de funções podem mudar, estruturas podem crescer
+ou diminuir e parâmetros de funções podem ser reformulados. Quando isso
+acontece, todos os locais dentro do kernel que utilizam essa interface são
+corrigidos ao mesmo tempo, garantindo que tudo continue funcionando
+corretamente.
+
+Como exemplos específicos disso, as interfaces USB internas do kernel
+passaram por pelo menos três reformulações diferentes ao longo da existência
+desse subsistema. Essas reformulações foram feitas para resolver diversos
+problemas:
+
+  - Uma mudança de um modelo síncrono de fluxos de dados para um modelo
+    assíncrono. Isso reduziu a complexidade de vários drivers e aumentou a
+    taxa de transferência de todos os drivers USB, de modo que atualmente
+    executamos quase todos os dispositivos USB na maior velocidade possível.
+  - Foi feita uma mudança na maneira como os pacotes de dados eram alocados
+    pelos drivers USB a partir do núcleo USB, de modo que todos os drivers
+    passaram a precisar fornecer mais informações ao núcleo USB, corrigindo
+    diversos deadlocks documentados.
+
+Isso contrasta fortemente com vários sistemas operacionais de código fechado,
+que tiveram de manter suas interfaces USB antigas ao longo do tempo. Isso
+permite que novos desenvolvedores utilizem acidentalmente interfaces antigas
+e façam as coisas de maneira inadequada, prejudicando a estabilidade do
+sistema operacional.
+
+Em ambos os casos, todos os desenvolvedores concordaram que essas eram
+mudanças importantes que precisavam ser feitas, e elas foram realizadas com
+relativamente pouco esforço. Se o Linux tivesse de garantir a preservação de
+uma interface de código-fonte estável, uma nova interface teria de ser criada,
+enquanto a interface antiga e defeituosa teria de continuar sendo mantida ao
+longo do tempo, resultando em trabalho adicional para os desenvolvedores USB.
+Como todos os desenvolvedores USB do Linux realizam esse trabalho em seu
+próprio tempo, pedir que programadores façam trabalho extra, sem nenhum
+benefício e gratuitamente, não é uma possibilidade.
+
+Questões de segurança também são muito importantes para o Linux. Quando um
+problema de segurança é encontrado, ele é corrigido em um período muito curto.
+Em diversas ocasiões, isso fez com que interfaces internas do kernel fossem
+reformuladas para impedir que o problema de segurança ocorresse. Quando isso
+acontece, todos os drivers que utilizam essas interfaces também são corrigidos
+ao mesmo tempo, garantindo que o problema de segurança seja resolvido e não
+possa reaparecer acidentalmente no futuro. Se as interfaces internas não
+pudessem ser alteradas, não seria possível corrigir esse tipo de problema de
+segurança e garantir que ele não voltasse a ocorrer.
+
+As interfaces do kernel são aprimoradas ao longo do tempo. Se ninguém estiver
+utilizando uma determinada interface, ela é removida. Isso garante que o
+kernel permaneça o menor possível e que todas as interfaces existentes possam
+ser testadas da melhor maneira possível (é praticamente impossível testar
+adequadamente a validade de interfaces que não são utilizadas).
+
+
+O que fazer
+-----------
+
+Então, se você possui um driver do kernel Linux que não está na árvore
+principal do kernel, o que você, como desenvolvedor, deve fazer? Distribuir
+um driver binário para cada versão diferente do kernel em cada distribuição
+é um pesadelo, e tentar acompanhar uma interface do kernel que está em
+constante mudança também é uma tarefa difícil.
+
+Simples: coloque seu driver na árvore principal do kernel (lembre-se de que
+estamos falando aqui de drivers distribuídos sob uma licença compatível com
+a GPL; se seu código não se enquadra nessa categoria, boa sorte, você está
+por conta própria aqui, seu parasita). Se seu driver estiver na árvore e uma
+interface do kernel mudar, ele será corrigido pela própria pessoa que realizou
+a alteração no kernel. Isso garante que seu driver continue sempre compilável
+e funcionando ao longo do tempo, exigindo muito pouco esforço de sua parte.
+
+Os excelentes efeitos colaterais de ter seu driver na árvore principal do
+kernel são:
+
+  - A qualidade do driver aumentará, enquanto os custos de manutenção
+    (para o desenvolvedor original) diminuirão.
+  - Outros desenvolvedores adicionarão funcionalidades ao seu driver.
+  - Outras pessoas encontrarão e corrigirão bugs no seu driver.
+  - Outras pessoas encontrarão oportunidades de otimização no seu driver.
+  - Outras pessoas atualizarão o driver para você quando mudanças em
+    interfaces externas exigirem isso.
+  - O driver será automaticamente distribuído por todas as distribuições
+    Linux, sem que seja necessário pedir às distribuições que o adicionem.
+
+Como o Linux oferece suporte, "pronto para uso", a um número maior de
+dispositivos diferentes do que qualquer outro sistema operacional, e oferece
+suporte a esses dispositivos em mais arquiteturas de processadores diferentes
+do que qualquer outro sistema operacional, esse modelo comprovado de
+desenvolvimento deve estar fazendo alguma coisa certa :)
+
+
+------
+
+Agradecimentos a Randy Dunlap, Andrew Morton, David Brownell, Hanna Linder,
+Robert Love e Nishanth Aravamudan pela revisão e pelos comentários sobre
+este documento.
diff --git a/Documentation/translations/pt_BR/process/submit-checklist.rst b/Documentation/translations/pt_BR/process/submit-checklist.rst
index 003fc956832d..3e0ee38b9a72 100644
--- a/Documentation/translations/pt_BR/process/submit-checklist.rst
+++ b/Documentation/translations/pt_BR/process/submit-checklist.rst
@@ -8,7 +8,7 @@ Aqui estão algumas coisas básicas que os desenvolvedores devem fazer se
 quiserem ver suas submissões de patches de kernel aceitas mais rapidamente.
 
 Estas diretrizes vão além da documentação fornecida em
-:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
+:ref:`Documentation/translations/pt_BR/process/submitting-patches.rst <pt_BR_submittingpatches>`
 e em outros locais sobre o envio de patches para o kernel Linux.
 
 Revise seu código
@@ -19,7 +19,7 @@ Revise seu código
    os que você usa de forma indireta.
 
 2) Verifique o estilo geral do seu patch conforme detalhado em
-   :ref:`Documentation//process/coding-style.rst <codingstyle>`.
+   :ref:`Documentation/translations/pt_BR/process/coding-style.rst <pt_BR_codingstyle>`.
 
 3) Todas as barreiras de memória {por exemplo, ``barrier()``, ``rmb()``,
    ``wmb()``} precisam de um comentário no código-fonte que explique a
diff --git a/Documentation/translations/pt_BR/process/submitting-patches.rst b/Documentation/translations/pt_BR/process/submitting-patches.rst
new file mode 100644
index 000000000000..aad926c17fb4
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/submitting-patches.rst
@@ -0,0 +1,963 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _pt_BR_submittingpatches:
+
+Enviando patches: o guia essencial para colocar o seu código no kernel
+======================================================================
+
+Para uma pessoa ou empresa que deseja enviar uma mudança para o
+kernel Linux, o processo pode, por vezes, ser intimidador se você não
+estiver familiarizado com "o sistema". Este texto é uma coleção de sugestões
+que podem aumentar muito as chances de sua mudança ser aceita.
+
+Este documento contém um grande número de sugestões em um formato relativamente
+conciso. Para informações detalhadas sobre como funciona o processo de
+desenvolvimento do kernel, consulte Documentation/process/development-process.rst.
+Além disso, leia Documentation/process/submit-checklist.rst
+para uma lista de itens a serem verificados antes de enviar o código.
+Para patches de binding de device tree, leia
+Documentation/devicetree/bindings/submitting-patches.rst.
+
+Esta documentação assume que você está usando o ``git`` para preparar seus
+patches. Se você não está familiarizado com o ``git``, é muito recomendado que
+você aprenda a usá-lo, ele tornará a sua vida como um desenvolvedor do kernel e,
+em geral, muito mais fácil.
+
+Alguns subsistemas e árvores de mantenedores possuem informações adicionais
+sobre seus fluxos de trabalho e expectativas, consulte
+Documentation/process/maintainer-handbooks.rst.
+
+Obtenha uma árvore de código-fonte atual
+----------------------------------------
+
+Se você não tiver um repositório com o código-fonte atual do kernel em mãos,
+use o ``git`` para obter um. Você vai querer começar com o repositório mainline,
+que pode ser obtido com::
+
+  git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
+
+Note, no entanto, que você pode não querer desenvolver diretamente na
+árvore mainline. A maioria dos mantenedores de subsistemas mantém suas
+próprias árvores e desejam ver os patches preparados em relação a essas árvores.
+Consulte a entrada **T:** do subsistema no arquivo MAINTAINERS para encontrar
+essa árvore, ou simplesmente pergunte ao mantenedor se a árvore não estiver
+listada lá.
+
+.. _pt_BR_describe_changes:
+
+Descreva as suas mudanças
+-------------------------
+
+Descreva o seu problema. Seja o seu patch uma correção de bug de uma linha ou
+5000 linhas de um novo recurso, deve haver um problema subjacente que o motivou
+a fazer esse trabalho. Convença o revisor de que existe um problema que vale a
+pena corrigir e que faz sentido que ele leia além do primeiro parágrafo.
+
+Descreva o impacto visível ao usuário. Travamentos e bloqueios diretos são
+bastante convincentes, mas nem todos os bugs são tão evidentes. Mesmo que o
+problema tenha sido identificado durante a revisão do código, descreva o impacto
+que você acredita que ele pode ter sobre os usuários. Tenha em mente que a
+maioria das instalações Linux executa kernels de árvores estáveis secundárias
+ou árvores específicas de fornecedores/produtos que selecionam apenas patches
+específicos do upstream, então inclua qualquer coisa que possa ajudar a
+direcionar sua mudança downstream: circunstâncias provocadoras, trechos do
+dmesg, descrições do travamento, regressões de desempenho, picos de latência,
+bloqueios, etc.
+
+Quantifique as otimizações e compensações. Se você afirma haver melhorias no
+desempenho, consumo de memória, uso da pilha ou tamanho do binário, inclua
+números que as comprovem. Mas também descreva custos que não são óbvios.
+Otimizações geralmente não são gratuitas, sendo trocas entre CPU, memória e
+legibilidade; ou, quando se trata de heurísticas, entre diferentes cargas de
+trabalho. Descreva as desvantagens esperadas da sua otimização para que o
+revisor possa pesar os custos contra os benefícios.
+
+Uma vez estabelecido o problema, descreva o que você está efetivamente fazendo
+sobre ele, com detalhes técnicos. É importante descrever a mudança em inglês
+claro para o revisor verificar que o código está se comportando como
+você pretendia.
+
+O mantenedor agradecerá se você escrever a descrição do seu patch em uma forma
+que possa ser facilmente inserida no sistema de gerenciamento de código-fonte do
+Linux, o ``git``, como uma "mensagem de commit". Veja
+:ref:`pt_BR_the_canonical_patch_format`.
+
+Resolva apenas um problema por patch. Se a sua descrição começar a ficar longa,
+isso é um sinal de que você provavelmente precisa dividir o seu patch.
+Consulte :ref:`pt_BR_split_changes`.
+
+Quando você enviar ou reenviar um patch ou uma série de patches, inclua a
+descrição completa do patch e a justificativa para ele. Não diga apenas
+que esta é a versão N do patch (ou série). Não espere que o mantenedor
+do subsistema consulte versões anteriores do patch ou URLs de referência
+para encontrar a descrição do patch e colocá-la no patch.
+Ou seja, o patch (ou a série) e sua descrição devem ser autossuficientes.
+Isso beneficia tanto os mantenedores quanto os revisores. Alguns revisores
+provavelmente nem chegaram a receber as versões anteriores do patch.
+
+Descreva suas alterações no modo imperativo, por exemplo, "faça xyzzy executar
+frotz" em vez de "[Este patch] faz xyzzy executar frotz" ou "[Eu] mudei xyzzy
+para executar frotz", como se você estivesse dando ordens à base de código para
+mudar o seu comportamento.
+
+Se você quiser se referir a um commit específico, não se refira apenas ao
+ID SHA-1 do commit. Por favor, inclua também o resumo de uma linha do
+commit, para tornar mais fácil para os revisores saberem sobre o que se trata.
+Exemplo::
+
+	Commit e21d2170f36602ae2708 ("video: remove unnecessary
+	platform_set_drvdata()") removed the unnecessary
+	platform_set_drvdata(), but left the variable "dev" unused,
+	delete it.
+
+Você também deve ter a certeza de usar pelo menos os primeiros doze caracteres do
+ID SHA-1. O repositório do kernel possui um número *muito* grande de objetos, o que torna as
+colisões com IDs mais curtos uma possibilidade real. Tenha em mente que, mesmo que
+não haja colisão com o seu ID de seis caracteres agora, essa condição pode
+mudar daqui a cinco anos.
+
+Se discussões relacionadas ou qualquer outra informação de contexto por trás da mudança
+puderem ser encontradas na web, adicione tags 'Link:' apontando para isso. Se o patch é o
+resultado de algumas discussões anteriores na lista de e-mails ou algo documentado na
+web, aponte para ele.
+
+Ao criar links para arquivos de listas de e-mails, de preferência use o serviço
+de arquivo de mensagens lore.kernel.org. Para criar a URL do link, use o
+conteúdo do cabeçalho ``Message-ID`` da mensagem, sem os colchetes angulares
+circundantes. Por exemplo::
+
+    Link: https://lore.kernel.org/30th.anniversary.repost@klaava.Helsinki.FI
+
+Por favor, verifique o link para se certificar de que ele está realmente
+funcionando e aponta para a mensagem relevante.
+
+No entanto, tente tornar a sua explicação compreensível sem recursos
+externos. Além de fornecer um URL para um arquivo da lista de e-mails ou bug,
+resuma os pontos relevantes da discussão que levaram ao patch conforme enviado.
+
+Caso o seu patch corrija um bug, use a tag 'Closes:' com um URL que referencie o
+relato nos arquivos da lista de e-mails ou em um rastreador público de bugs. Por exemplo::
+
+	Closes: https://example.com/issues/1234
+
+Alguns rastreadores de bugs têm a capacidade de fechar os problemas
+automaticamente quando um commit com tal tag é aplicado. Alguns bots que monitoram as listas de
+e-mails também podem rastrear tais tags e tomar certas ações. Rastreadores de bugs
+privados e URLs inválidos são proibidos.
+
+Se o seu patch corrige um bug em um commit específico, por exemplo, você encontrou um problema usando
+``git bisect``, por favor, use a tag 'Fixes:' com pelo menos os primeiros 12
+caracteres do ID SHA-1 e o resumo de uma linha. Não divida a tag em
+várias linhas, as tags estão isentas da regra de "quebra de linha nas 75 colunas" para
+simplificar os scripts de parsing. Por exemplo::
+
+	Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually freed")
+
+As seguintes configurações do ``git config`` podem ser usadas para adicionar um formato aprimorado para
+exibir o estilo acima nos comandos ``git log`` ou ``git show``::
+
+	[core]
+		abbrev = 12
+	[pretty]
+		fixes = Fixes: %h (\"%s\")
+
+Um exemplo de chamada::
+
+	$ git log -1 --pretty=fixes 54a4f0239f2e
+	Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually freed")
+
+.. _pt_BR_split_changes:
+
+Separe as suas mudanças
+-----------------------
+
+Separe cada **mudança lógica** em um patch separado.
+
+Por exemplo, se as suas alterações incluírem tanto correções de bugs quanto melhorias
+de desempenho para um único driver, separe essas alterações em dois
+ou mais patches. Se as suas alterações incluírem uma atualização de API e um novo
+driver que utiliza essa nova API, separe-os em dois patches.
+
+Por outro lado, se você fizer uma única alteração em vários arquivos,
+agrupe essas alterações em um único patch. Assim, uma única mudança
+lógica está contida em um único patch.
+
+O ponto a lembrar é que cada patch deve fazer uma mudança facilmente compreendida
+que possa ser verificada pelos revisores. Cada patch deve ser justificável
+por seus próprios méritos.
+
+Se um patch depender de outro patch para que uma mudança seja
+completa, não tem problema. Simplesmente note **"this patch depends on patch X"**
+na descrição do seu patch.
+
+Ao dividir a sua mudança em uma série de patches, tome um cuidado especial para
+garantir que o kernel compile e seja executado adequadamente após cada patch da
+série. Desenvolvedores que usam o ``git bisect`` para rastrear um problema podem acabar
+dividindo a sua série de patches em qualquer ponto; eles não ficarão gratos se você
+introduzir bugs no meio do processo.
+
+Se você não conseguir condensar o seu conjunto de patches em um conjunto menor
+de patches, então publique, digamos, apenas uns 15 de cada vez e aguarde pela
+revisão e integração.
+
+
+
+Verifique o estilo das suas mudanças
+------------------------------------
+
+Verifique o seu patch quanto a violações básicas de estilo, cujos detalhes podem ser
+encontrados em Documentation/process/coding-style.rst.
+Não fazer isso simplesmente desperdiça
+o tempo dos revisores e fará com que o seu patch seja rejeitado, provavelmente
+sem sequer ser lido.
+
+Uma exceção significativa é quando se move código de um arquivo para
+outro -- neste caso você não deve modificar o código movido no
+mesmo patch que o move. Isso delineia claramente o ato de
+mover o código e as suas alterações. Isso ajuda muito a revisão das
+diferenças reais e permite que as ferramentas rastreiem melhor o histórico do
+próprio código.
+
+Verifique os seus patches com o verificador de estilo de patch antes de os submeter
+(scripts/checkpatch.pl). Note, porém, que o verificador de estilo deve ser
+visto como um guia, e não como um substituto para o julgamento humano. Se o seu
+código parecer melhor com uma violação, provavelmente é melhor deixá-lo como está.
+
+O verificador emite relatórios em três níveis:
+ - ERROR: coisas que muito provavelmente estão erradas
+ - WARNING: coisas que requerem uma revisão cuidadosa
+ - CHECK: coisas que requerem reflexão
+
+Você deve ser capaz de justificar todas as violações que permanecerem no seu
+patch.
+
+Selecione os destinatários do seu patch
+---------------------------------------
+
+Você deve sempre copiar o(s) mantenedor(es) e a(s) lista(s) do subsistema
+apropriado(s) em qualquer patch para o código que eles mantêm; dê uma
+olhada no arquivo MAINTAINERS e no histórico de revisão do código-fonte
+para ver quem são esses mantenedores. O script scripts/get_maintainer.pl
+pode ser muito útil nesta etapa (passe os caminhos para seus patches
+como argumentos para scripts/get_maintainer.pl). Se você não conseguir
+encontrar um mantenedor para o subsistema em que está trabalhando,
+Andrew Morton (akpm@linux-foundation.org) serve como um mantenedor de
+último recurso.
+
+linux-kernel@vger.kernel.org deve ser usado por padrão para todos os
+patches, mas o volume dessa lista fez com que vários desenvolvedores a
+ignorassem. Por favor, não envie spam para listas e pessoas não
+relacionadas.
+
+Muitas listas relacionadas ao kernel estão hospedadas em kernel.org;
+você pode encontrar uma lista delas em https://subspace.kernel.org.
+Existem listas relacionadas ao kernel hospedadas em outros lugares
+também, no entanto.
+
+Linus Torvalds é o árbitro final de todas as mudanças aceitas no
+kernel do Linux. Seu endereço de e-mail é <torvalds@linux-foundation.org>.
+Ele recebe muitos e-mails e, neste momento, muito poucos patches passam
+por Linus diretamente, então, normalmente, você deve fazer o seu melhor
+para -evitar- enviar e-mails para ele.
+
+Se você tiver um patch que corrija um bug de segurança explorável,
+envie esse patch para security@kernel.org. Para bugs severos, um
+curto embargo pode ser considerado para permitir que os distribuidores
+disponibilizem o patch aos usuários; em tais casos, obviamente, o
+patch não deve ser enviado a nenhuma lista pública. Veja também
+Documentation/process/security-bugs.rst.
+
+Patches que corrigem um bug severo em um kernel já lançado devem ser
+direcionados aos mantenedores stable (estáveis), colocando uma linha como esta::
+
+  Cc: stable@vger.kernel.org
+
+na área de sign-off do seu patch (note, NÃO como um destinatário de e-mail).
+Você também deve ler Documentation/process/stable-kernel-rules.rst
+além deste documento.
+
+Se as alterações afetarem as interfaces userland-kernel,
+por favor, envie ao mantenedor das MAN-PAGES (como listado no arquivo MAINTAINERS)
+um patch para as páginas de manual, ou pelo menos uma notificação da alteração,
+para que alguma informação chegue às páginas de manual. Mudanças na API
+do espaço de usuário também devem ser copiadas para linux-api@vger.kernel.org.
+
+
+Sem MIME, sem links, sem compressão, sem anexos. Apenas texto puro
+------------------------------------------------------------------
+
+Linus e outros desenvolvedores do kernel precisam ser capazes de ler e
+comentar as mudanças que você está enviando. É importante que um
+desenvolvedor do kernel seja capaz de "citar" suas mudanças, usando
+ferramentas de e-mail padrão, para que eles possam comentar em partes
+específicas do seu código.
+
+Por esse motivo, todos os patches devem ser enviados por e-mail "inline". A
+maneira mais fácil de fazer isso é com ``git send-email``, que é
+fortemente recomendado. Um tutorial interativo para ``git send-email``
+está disponível em https://git-send-email.io.
+
+Se você optar por não usar ``git send-email``:
+
+.. warning::
+
+  Tenha cuidado com a quebra de linha do seu editor corrompendo seu patch,
+  se você optar por recortar e colar o seu patch.
+
+Não anexe o patch como um anexo MIME, comprimido ou não.
+Muitos aplicativos populares de e-mail nem sempre transmitirão um
+anexo MIME como texto puro, tornando impossível comentar o seu
+código. Um anexo MIME também leva um pouco mais de tempo para Linus
+processar, diminuindo a probabilidade da sua alteração anexada em MIME
+ser aceita.
+
+Exceção: Se o seu cliente de e-mail estiver danificando os patches,
+alguém pode pedir que você os reenvie usando MIME.
+
+Veja Documentation/process/email-clients.rst para dicas sobre como
+configurar seu cliente de e-mail para que ele envie seus patches intocados.
+
+Responda aos comentários de revisão
+-----------------------------------
+
+Seu patch quase certamente receberá comentários dos revisores sobre maneiras
+pelas quais o patch pode ser melhorado, na forma de uma resposta ao seu
+e-mail. Você deve responder a esses comentários; ignorar revisores é uma
+boa maneira de ser ignorado em troca. Você pode simplesmente responder aos
+e-mails deles para responder aos seus comentários. Comentários de revisão
+ou perguntas que não levam a uma alteração no código devem quase certamente
+resultar em um comentário ou entrada no changelog para que o próximo
+revisor entenda melhor o que está acontecendo.
+
+Certifique-se de dizer aos revisores quais alterações você está fazendo e
+de agradecê-los pelo tempo dedicado. A revisão de código é um processo
+cansativo e demorado, e os revisores às vezes ficam mal-humorados. Mesmo
+nesse caso, no entanto, responda educadamente e resolva os problemas que
+eles apontaram. Ao enviar uma próxima versão, adicione um ``changelog do patch``
+à carta de apresentação (cover letter) ou aos patches individuais,
+explicando a diferença em relação ao envio anterior (veja
+:ref:`pt_BR_the_canonical_patch_format`).
+Notifique as pessoas que comentaram no seu patch sobre as novas versões
+adicionando-as à lista de CC dos patches.
+
+Veja Documentation/process/email-clients.rst para recomendações sobre
+clientes de e-mail e etiqueta de listas de discussão.
+
+.. _pt_BR_interleaved_replies:
+
+Use respostas intercaladas e aparadas em discussões por e-mail
+--------------------------------------------------------------
+O top-posting (responder no topo) é fortemente desencorajado em
+discussões de desenvolvimento do kernel do Linux. Respostas
+intercaladas (ou "inline") tornam as conversas muito mais fáceis de
+acompanhar. Para mais detalhes, veja:
+https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
+
+Como é frequentemente citado na lista de discussão::
+
+  A: http://en.wikipedia.org/wiki/Top_post
+  Q: Onde encontro informações sobre essa coisa chamada top-posting?
+  A: Porque bagunça a ordem em que as pessoas normalmente leem o texto.
+  Q: Por que o top-posting é algo tão ruim?
+  A: Top-posting.
+  Q: Qual é a coisa mais irritante no e-mail?
+
+Da mesma forma, por favor, apare (corte) todas as citações
+desnecessárias que não são relevantes para a sua resposta. Isso torna
+as respostas mais fáceis de encontrar, e economiza tempo e espaço. Para
+mais detalhes, veja: http://daringfireball.net/2007/07/on_top ::
+
+  A: Não.
+  Q: Devo incluir citações após minha resposta?
+
+.. _pt_BR_resend_reminders:
+
+Não desanime - nem fique impaciente
+-----------------------------------
+
+Depois de ter enviado a sua alteração, seja paciente e espere. Os
+revisores são pessoas ocupadas e podem não chegar ao seu patch
+imediatamente.
+
+Era uma vez, patches costumavam desaparecer no vazio sem comentários,
+mas o processo de desenvolvimento funciona de forma mais suave do que
+isso agora. Você deve receber comentários dentro de algumas semanas
+(normalmente 2-3); se isso não acontecer, certifique-se de que você
+enviou seus patches para o lugar certo. Espere por no mínimo uma
+semana antes de reenviar ou dar um "ping" nos revisores -
+possivelmente mais tempo durante períodos ocupados, como as janelas
+de mesclagem (merge windows).
+
+Também não há problema em reenviar o patch ou a série de patches após
+algumas semanas com a palavra "RESEND" adicionada à linha de Assunto::
+
+   [PATCH Vx RESEND] sub/sys: Resumo condensado do patch
+
+Não adicione "RESEND" quando você estiver enviando uma versão
+modificada do seu patch ou série de patches - "RESEND" se aplica
+apenas ao reenvio de um patch ou série de patches que não foram
+modificados de forma alguma em relação ao envio anterior.
+
+
+Inclua PATCH no Assunto
+-----------------------
+
+Devido ao alto tráfego de e-mails para Linus e para a linux-kernel, é
+uma convenção comum prefixar a sua linha de Assunto com [PATCH]. Isso
+permite que Linus e outros desenvolvedores do kernel distingam
+mais facilmente os patches de outras discussões por e-mail.
+
+O ``git send-email`` fará isso por você automaticamente.
+
+
+Assine seu trabalho - o Certificado de Origem do Desenvolvedor
+--------------------------------------------------------------
+
+Para melhorar o rastreamento de quem fez o que, especialmente com patches
+que podem percolar até o seu local de descanso final no kernel através de
+várias camadas de mantenedores, nós introduzimos um procedimento de
+"sign-off" nos patches que estão sendo enviados por e-mail.
+
+O sign-off é uma linha simples no final da explicação do patch, que
+certifica que você o escreveu ou que de outra forma tem o direito de
+repassá-lo como um patch de código aberto. As regras são bem simples:
+se você pode certificar o seguinte::
+
+        Certificado de Origem do Desenvolvedor 1.1
+
+        Ao fazer uma contribuição para este projeto, eu certifico que:
+
+        (a) A contribuição foi criada no todo ou em parte por mim e eu
+            tenho o direito de enviá-la sob a licença de código aberto
+            indicada no arquivo; ou
+
+        (b) A contribuição baseia-se em trabalho anterior que, até onde eu
+            sei, é coberto por uma licença de código aberto apropriada
+            e eu tenho o direito, sob essa licença, de enviar esse
+            trabalho com modificações, tenham sido criadas no todo ou
+            em parte por mim, sob a mesma licença de código aberto (a menos que eu
+            tenha permissão para enviar sob uma licença diferente), conforme
+            indicado no arquivo; ou
+
+        (c) A contribuição foi fornecida diretamente a mim por alguma outra
+            pessoa que certificou (a), (b) ou (c) e eu não a modifiquei.
+
+        (d) Eu entendo e concordo que este projeto e a contribuição
+            são públicos e que um registro da contribuição (incluindo todas
+            as informações pessoais que eu envio com ela, incluindo meu
+            sign-off) é mantido indefinidamente e pode ser redistribuído de forma
+            consistente com este projeto ou com a(s) licença(s) de código
+            aberto envolvida(s).
+
+então você apenas adiciona uma linha dizendo::
+
+	Signed-off-by: Random J Developer <random@developer.example.org>
+
+usando uma identidade conhecida (desculpe, sem contribuições anônimas.)
+Isso será feito para você automaticamente se você usar o ``git commit -s``.
+As reversões também devem incluir "Signed-off-by". O ``git revert -s``
+faz isso por você.
+
+Algumas pessoas também colocam tags extras no final. Elas serão
+apenas ignoradas por enquanto, mas você pode fazer isso para marcar
+procedimentos internos da empresa ou apenas para apontar algum
+detalhe especial sobre o sign-off.
+
+Quaisquer outros SoBs (Signed-off-by:'s) seguindo o SoB do autor
+são de pessoas que manusearam e transportaram o patch, mas não
+estiveram envolvidas no seu desenvolvimento. As cadeias de SoB devem
+refletir a rota **real** que um patch percorreu à medida que foi
+propagado aos mantenedores e, finalmente, para Linus, com a primeira
+entrada de SoB sinalizando a autoria principal de um único autor.
+
+
+Quando usar Acked-by:, Cc: e Co-developed-by:
+---------------------------------------------
+
+A tag Signed-off-by: indica que o signatário esteve envolvido no
+desenvolvimento do patch, ou que ele/ela estava no caminho de
+entrega do patch.
+
+Se uma pessoa não esteve diretamente envolvida na preparação ou manuseio de um
+patch, mas deseja manifestar e registrar sua aprovação, ela pode
+pedir para ter uma linha Acked-by: adicionada ao changelog do patch.
+
+Acked-by: destina-se a ser usado por aqueles responsáveis ou envolvidos com o
+código afetado de uma forma ou de outra. Mais comumente, o mantenedor quando esse
+mantenedor não contribuiu nem encaminhou o patch.
+
+Acked-by: também pode ser usado por outras partes interessadas, como pessoas com conhecimento de
+domínio (por exemplo, o autor original do código sendo modificado), revisores
+do lado do espaço de usuário para um patch uAPI do kernel ou usuários-chave de um recurso. Opcionalmente,
+nestes casos, pode ser útil adicionar um "# Sufixo" para esclarecer seu significado::
+
+	Acked-by: The Stakeholder <stakeholder@example.org> # As primary user
+
+Acked-by: não é tão formal quanto Signed-off-by:. É um registro de que o avaliador
+pelo menos revisou o patch e indicou aceitação. Por isso, os responsáveis pela fusão de
+patches às vezes converterão manualmente um "sim, parece bom para mim" de um avaliador
+em um Acked-by: (mas note que geralmente é melhor pedir um
+ack explícito).
+
+Acked-by: também é menos formal do que Reviewed-by:. Por exemplo, mantenedores podem
+usá-lo para sinalizar que estão de acordo com a inclusão de um patch, mas podem não tê-lo
+revisado tão minuciosamente como se um Reviewed-by: fosse fornecido. Da mesma forma, um
+usuário-chave pode não ter realizado uma revisão técnica do patch, mas ainda assim estar
+satisfeito com a abordagem geral, o recurso ou a interface voltada para o usuário.
+
+Acked-by: não indica necessariamente o reconhecimento de todo o patch.
+Por exemplo, se um patch afeta vários subsistemas e tem um Acked-by: de
+um mantenedor de subsistema, isso geralmente indica o reconhecimento apenas
+da parte que afeta o código desse mantenedor. O bom senso deve ser usado aqui.
+Em caso de dúvida, as pessoas devem consultar a discussão original nos arquivos da
+lista de discussão. Um "# Sufixo" também pode ser usado neste caso para esclarecer.
+
+Se uma pessoa teve a oportunidade de comentar em um patch, mas não
+forneceu tais comentários, você pode opcionalmente adicionar uma tag ``Cc:`` ao patch.
+Esta tag documenta que partes potencialmente interessadas foram incluídas na
+discussão. Note que esta é uma de apenas três tags que você pode usar
+sem a permissão explícita da pessoa nomeada (veja 'Marcar pessoas requer
+permissão' abaixo para detalhes).
+
+Co-developed-by: afirma que o patch foi co-criado por múltiplos desenvolvedores;
+é usado para dar atribuição a coautores (além do autor
+atribuído pela tag From:) quando várias pessoas trabalham em um único patch. Como
+Co-developed-by: denota autoria, cada Co-developed-by: deve ser imediatamente
+seguido por um Signed-off-by: do coautor associado. O procedimento padrão de assinatura
+se aplica, ou seja, a ordem das tags Signed-off-by: deve refletir a
+história cronológica do patch na medida do possível, independentemente se
+o autor for atribuído via From: ou Co-developed-by:. Notavelmente, o último
+Signed-off-by: deve ser sempre o do desenvolvedor que está enviando o patch.
+
+Note que a tag From: é opcional quando o autor no From: também é a pessoa (e
+e-mail) listada na linha From: do cabeçalho do e-mail.
+
+Exemplo de um patch enviado pelo autor do 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>
+
+Exemplo de um patch enviado por um autor do 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>
+
+
+Usando Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: e Fixes:
+---------------------------------------------------------------------
+
+A tag Reported-by dá crédito às pessoas que encontram bugs e os relatam e
+espera-se que isso as inspire a nos ajudar novamente no futuro. A tag destina-se a
+bugs; por favor, não a use para dar crédito a solicitações de recursos. A tag deve ser
+seguida por uma tag Closes: apontando para o relato, a menos que o relato não
+esteja disponível na web. A tag Link: pode ser usada em vez de Closes: se o patch
+corrigir uma parte do(s) problema(s) sendo relatado(s). Note que a tag Reported-by é
+uma de apenas três tags que você pode usar sem a permissão explícita da
+pessoa nomeada (veja 'Marcar pessoas requer permissão' abaixo para detalhes).
+
+Uma tag Tested-by: indica que o patch foi testado com sucesso (em
+algum ambiente) pela pessoa nomeada. Esta tag informa aos mantenedores que
+algum teste foi realizado, fornece um meio para localizar testadores para
+patches futuros e garante crédito para os testadores.
+
+Reviewed-by:, por sua vez, indica que o patch foi revisado e considerado
+aceitável de acordo com a Declaração do Revisor::
+
+	Declaração de supervisão do revisor
+
+	Ao oferecer minha tag Reviewed-by:, eu declaro que:
+
+	 (a) Eu realizei uma revisão técnica deste patch para
+	     avaliar sua adequação e prontidão para inclusão no
+	     kernel mainline.
+
+	 (b) Quaisquer problemas, preocupações ou perguntas relacionadas ao patch
+	     foram comunicadas de volta ao remetente. Eu estou satisfeito
+	     com a resposta do remetente aos meus comentários.
+
+	 (c) Embora possa haver coisas que poderiam ser melhoradas com este
+	     envio, eu acredito que é, neste momento, (1) uma
+	     modificação que vale a pena para o kernel, e (2) livre de problemas
+	     conhecidos que argumentariam contra sua inclusão.
+
+	 (d) Embora eu tenha revisado o patch e acredite que seja sólido, eu
+	     não faço (a menos que explicitamente declarado em outro lugar)
+	     garantias de que alcançará seu propósito
+	     declarado ou funcionará adequadamente em qualquer situação.
+
+Uma tag Reviewed-by é uma declaração de opinião de que o patch é uma
+modificação apropriada do kernel sem nenhum problema técnico sério
+restante. Qualquer revisor interessado (que tenha feito o trabalho e seja uma
+pessoa com identidade conhecida) pode oferecer uma tag Reviewed-by para um patch. Esta tag
+serve para dar crédito aos revisores e para informar os mantenedores do grau de
+revisão que foi feito no patch. Tags Reviewed-by:, quando fornecidas por
+revisores conhecidos por entender a área de assunto e realizar revisões completas,
+normalmente aumentarão a probabilidade de seu patch entrar no kernel.
+
+Ambas as tags Tested-by e Reviewed-by, uma vez recebidas na lista de discussão do testador
+ou revisor, devem ser adicionadas pelo autor aos patches aplicáveis ao enviar as
+próximas versões. No entanto, se o patch mudou substancialmente na versão
+seguinte, essas tags podem não ser mais aplicáveis e, portanto, devem ser removidas.
+Normalmente, a remoção das tags Acked-by, Tested-by ou Reviewed-by de alguém deve ser
+mencionada no changelog do patch com uma explicação (após o separador '---').
+
+Uma tag Suggested-by: indica que a ideia do patch foi sugerida pela pessoa
+nomeada e garante crédito à pessoa pela ideia: se creditarmos diligentemente
+nossos relatores de ideias, eles serão, com sorte, inspirados a nos ajudar novamente no
+futuro. Note que esta é uma de apenas três tags que você pode usar sem
+permissão explícita da pessoa nomeada (veja 'Marcar pessoas requer
+permissão' abaixo para detalhes).
+
+Uma tag Fixes: indica que o patch corrige um bug em um commit anterior. Ela
+é usada para facilitar a determinação de onde um problema se originou, o que pode ajudar
+na revisão da correção de um bug. Esta tag também auxilia a equipe do kernel estável a determinar
+quais versões do kernel estável devem receber sua correção. Este é o método preferido
+para indicar um bug corrigido pelo patch. Veja :ref:`pt_BR_describe_changes`
+para mais detalhes.
+
+Nota: Anexar uma tag Fixes: não subverte o processo de regras do kernel
+estável, nem o requisito de enviar em Cc: para stable@vger.kernel.org em todos os patches
+candidatos estáveis. Para mais informações, por favor, leia
+Documentation/process/stable-kernel-rules.rst.
+
+Por fim, embora fornecer tags seja bem-vindo e tipicamente muito apreciado, por favor
+note que os signatários (ou seja, remetentes e mantenedores) podem usar sua discrição ao
+aplicar as tags oferecidas.
+
+
+Marcar pessoas requer permissão
+-------------------------------
+
+Tenha cuidado ao adicionar as tags mencionadas acima aos seus patches, pois todas
+exceto Cc:, Reported-by: e Suggested-by: precisam de permissão explícita da
+pessoa nomeada. Para essas três, a permissão implícita é suficiente se a pessoa
+contribuiu para o kernel Linux usando esse nome e endereço de e-mail de acordo
+com os arquivos do lore ou o histórico de commits -- e no caso de Reported-by:
+e Suggested-by: tenha feito o relato ou sugestão em público. Note que o
+bugzilla.kernel.org é um local público nesse sentido, mas os endereços de e-mail
+usados lá são privados; portanto, não os exponha em tags, a menos que a pessoa
+os tenha usado em contribuições anteriores.
+
+Usando Assisted-by:
+-------------------
+
+Se você usou qualquer tipo de ferramenta avançada de codificação na criação do seu patch,
+você precisa reconhecer esse uso adicionando uma tag Assisted-by. A falha em
+fazer isso pode impedir a aceitação do seu trabalho. Por favor, veja
+Documentation/process/coding-assistants.rst para detalhes sobre o
+reconhecimento de assistentes de codificação.
+
+
+.. _pt_BR_the_canonical_patch_format:
+
+O formato canônico do patch
+---------------------------
+
+Esta seção descreve como o próprio patch deve ser formatado. Note
+que, se você tiver seus patches armazenados em um repositório ``git``, a formatação
+adequada do patch pode ser obtida com ``git format-patch``. As ferramentas não podem criar
+o texto necessário, no entanto, portanto, leia as instruções abaixo de qualquer maneira.
+
+Linha de Assunto
+^^^^^^^^^^^^^^^^
+
+A linha de assunto canônica do patch é::
+
+    Assunto: [PATCH 001/123] subsistema: frase de resumo
+
+O corpo canônico da mensagem do patch contém o seguinte:
+
+  - Uma linha ``from`` especificando o autor do patch, seguida por uma linha
+    vazia (necessário apenas se a pessoa enviando o patch não for o autor).
+
+  - O corpo da explicação, com quebra de linha em 75 colunas, que será
+    copiado para o changelog permanente para descrever este patch.
+
+  - Uma linha vazia.
+
+  - As linhas ``Signed-off-by:``, descritas acima, que também
+    irão para o changelog.
+
+  - Uma linha de marcador contendo simplesmente ``---``.
+
+  - Quaisquer comentários adicionais não adequados para o changelog.
+
+  - O próprio patch (saída do ``diff``).
+
+O formato da linha de Assunto torna muito fácil classificar os e-mails
+alfabeticamente pela linha de assunto - praticamente qualquer leitor de e-mail
+suportará isso - pois, como o número de sequência é preenchido com zeros,
+a classificação numérica e alfabética é a mesma.
+
+O ``subsystem`` no Assunto do e-mail deve identificar qual
+área ou subsistema do kernel está recebendo o patch.
+
+A ``frase de resumo`` no Assunto do e-mail deve descrever de forma concisa
+o patch que esse e-mail contém. A ``frase de resumo`` não deve ser um nome de arquivo.
+Não use a mesma ``frase de resumo`` para cada patch em uma série de patches inteira (onde uma ``série
+de patches`` é uma sequência ordenada de múltiplos patches relacionados).
+
+Tenha em mente que a ``frase de resumo`` do seu e-mail se torna um
+identificador globalmente único para aquele patch. Ela se propaga por todo o caminho
+até o changelog do ``git``. A ``frase de resumo`` pode ser usada posteriormente em
+discussões de desenvolvedores que se referem ao patch. As pessoas vão querer
+pesquisar no Google pela ``frase de resumo`` para ler a discussão sobre esse
+patch. Também será a única coisa que as pessoas poderão ver rapidamente
+quando, dois ou três meses depois, estiverem passando por talvez
+milhares de patches usando ferramentas como ``gitk`` ou ``git log
+--oneline``.
+
+Por essas razões, o ``resumo`` não deve ter mais de 70-75
+caracteres, e deve descrever tanto o que o patch altera, quanto
+por que o patch pode ser necessário. É um desafio ser
+sucinto e descritivo, mas é isso que um resumo bem escrito
+deve fazer.
+
+A ``frase de resumo`` pode ser prefixada por tags delimitadas por colchetes
+retos: "Assunto: [PATCH <tag>...] <frase de resumo>". As tags não
+são consideradas parte da frase de resumo, mas descrevem como o patch
+deve ser tratado. Tags comuns podem incluir um descritor de versão se
+as múltiplas versões do patch tiverem sido enviadas em resposta a
+comentários (ou seja, "v1, v2, v3"), ou "RFC" para indicar um pedido de
+comentários.
+
+Se houver quatro patches em uma série de patches, os patches individuais podem
+ser numerados assim: 1/4, 2/4, 3/4, 4/4. Isso garante que os desenvolvedores
+entendam a ordem na qual os patches devem ser aplicados e que
+eles tenham revisado ou aplicado todos os patches na série de patches.
+
+Aqui estão alguns bons exemplos de Assuntos::
+
+    Subject: [PATCH 2/5] ext2: improve scalability of bitmap searching
+    Subject: [PATCH v2 01/27] x86: fix eflags tracking
+    Subject: [PATCH v2] sub/sys: Condensed patch summary
+    Subject: [PATCH v2 M/N] sub/sys: Condensed patch summary
+
+Linha From
+^^^^^^^^^^
+
+A linha ``from`` deve ser a primeira linha no corpo da mensagem,
+e tem a forma:
+
+        From: Patch Author <author@example.com>
+
+A linha ``from`` especifica quem será creditado como o autor do
+patch no changelog permanente. Se a linha ``from`` estiver faltando,
+então a linha ``From:`` do cabeçalho do e-mail será usada para determinar
+o autor do patch no changelog.
+
+O autor pode indicar sua afiliação ou o patrocinador do trabalho
+adicionando o nome de uma organização às linhas ``from`` e ``SoB``,
+por exemplo:
+
+	From: Patch Author (Company) <author@example.com>
+
+Corpo da Explicação
+^^^^^^^^^^^^^^^^^^^
+
+O corpo da explicação será commitado no changelog
+permanente da fonte, então deve fazer sentido para um leitor competente que já
+esqueceu há muito tempo os detalhes imediatos da discussão que podem ter levado a
+este patch. Incluir sintomas da falha que o patch aborda
+(mensagens de log do kernel, mensagens oops, etc.) é especialmente útil para
+pessoas que possam estar pesquisando nas mensagens de commit procurando pelo patch
+aplicável. O texto deve ser escrito com detalhes suficientes para que, quando lido
+semanas, meses ou até anos depois, possa dar ao leitor os detalhes
+necessários para compreender o raciocínio do **por que** o patch foi criado.
+
+Se um patch corrige uma falha de compilação, pode não ser necessário incluir
+_todas_ as falhas de compilação; apenas o suficiente para que seja provável que
+alguém pesquisando pelo patch possa encontrá-lo. Como na ``frase de resumo``,
+é importante ser tanto sucinto quanto descritivo.
+
+.. _pt_BR_backtraces:
+
+Backtraces em mensagens de commit
+"""""""""""""""""""""""""""""""""
+
+Backtraces ajudam a documentar a cadeia de chamadas que leva a um problema. No entanto,
+nem todos os backtraces são úteis. Por exemplo, as cadeias de chamadas iniciais de boot são
+únicas e óbvias. Copiar a saída dmesg completa verbatim, no entanto,
+adiciona informações que distraem, como timestamps, listas de módulos, dumps de
+registradores e pilhas.
+
+Portanto, os backtraces mais úteis devem destilar as informações
+relevantes do dump, o que facilita o foco no problema
+real. Aqui está um exemplo de um backtrace bem aparado::
+
+  unchecked MSR access error: WRMSR to 0xd51 (tried to write 0x0000000000000064)
+  at rIP: 0xffffffffae059994 (native_write_msr+0x4/0x20)
+  Call Trace:
+  mba_wrmsr
+  update_domains
+  rdtgroup_mkdir
+
+Comentários
+^^^^^^^^^^^
+
+A linha marcadora ``---`` serve ao propósito essencial de marcar para
+as ferramentas de manipulação de patches onde a mensagem do changelog termina.
+
+Um bom uso para os comentários adicionais após o marcador ``---`` é
+para um ``diffstat``, para mostrar quais arquivos mudaram, e o número de
+linhas inseridas e excluídas por arquivo. Um ``diffstat`` é especialmente útil
+em patches maiores. Se você for incluir um ``diffstat`` após o
+marcador ``---``, por favor, use as opções do ``diffstat`` ``-p 1 -w 70`` para que
+os nomes dos arquivos sejam listados a partir do topo da árvore de código-fonte do kernel e não
+usem muito espaço horizontal (cabem facilmente em 80 colunas, talvez com algum
+recuo). (o ``git`` gera diffstats apropriados por padrão.)
+
+Outros comentários relevantes apenas para o momento ou para o mantenedor, não
+adequados para o changelog permanente, também devem ir aqui. Um bom
+exemplo de tais comentários podem ser ``changelogs do patch`` que descrevem
+o que mudou entre as versões v1 e v2 do patch.
+
+Por favor, coloque esta informação **após** a linha ``---`` que separa
+o changelog do restante do patch. A informação da versão não
+faz parte do changelog que é commitado na árvore git. É
+informação adicional para os revisores. Se for colocada acima das
+tags de commit, precisará de interação manual para removê-la. Se estiver abaixo
+da linha separadora, ela é automaticamente removida ao aplicar o
+patch. Se disponíveis, adicionar links para as versões anteriores do patch (por exemplo,
+link do arquivo lore.kernel.org) é recomendado para ajudar os revisores::
+
+  <commit message>
+  ...
+  Signed-off-by: Author <author@mail>
+  ---
+  V2 -> V3: Removed redundant helper function
+  V1 -> V2: Cleaned up coding style and addressed review comments
+
+  v2: https://lore.kernel.org/bar
+  v1: https://lore.kernel.org/foo
+
+  path/to/file | 5+++--
+  ...
+
+Veja mais detalhes sobre o formato de patch adequado nas seguintes
+referências.
+
+
+Cabeçalhos In-Reply-To explícitos
+---------------------------------
+
+Pode ser útil adicionar manualmente cabeçalhos In-Reply-To: a um patch
+(por exemplo, ao usar ``git send-email``) para associar o patch com
+discussões relevantes anteriores, por exemplo, para vincular uma correção de bug ao e-mail com
+o relatório do bug. No entanto, para uma série de múltiplos patches, geralmente é
+melhor evitar usar In-Reply-To: para vincular a versões mais antigas da
+série. Desta forma, múltiplas versões do patch não se tornam uma
+floresta incontrolável de referências nos clientes de e-mail. Se um link for
+útil, você pode usar o redirecionador https://lore.kernel.org/ (por exemplo, no
+texto do e-mail de capa) para vincular a uma versão anterior da série de patches.
+
+
+Informações sobre a árvore base
+-------------------------------
+
+Quando outros desenvolvedores recebem seus patches e iniciam o processo de revisão,
+é absolutamente necessário que eles saibam qual é o commit/branch
+base no qual seu trabalho se aplica, considerando a enorme quantidade de
+árvores de mantenedores presentes hoje em dia. Note novamente a entrada **T:** no
+arquivo MAINTAINERS explicado acima.
+
+Isso é ainda mais importante para processos automatizados de CI que tentam
+executar uma série de testes a fim de estabelecer a qualidade da sua
+submissão antes que o mantenedor inicie a revisão.
+
+Se você estiver usando ``git format-patch`` para gerar seus patches, você pode
+incluir automaticamente as informações da árvore base em sua submissão ao
+usar a flag ``--base``. A maneira mais fácil e conveniente de usar
+esta opção é com branches de tópicos (topical branches)::
+
+    $ git checkout -t -b my-topical-branch master
+    Branch 'my-topical-branch' set up to track local branch 'master'.
+    Switched to a new branch 'my-topical-branch'
+
+    [perform your edits and commits]
+
+    $ git format-patch --base=auto --cover-letter -o outgoing/ master
+    outgoing/0000-cover-letter.patch
+    outgoing/0001-First-Commit.patch
+    outgoing/...
+
+Quando você abrir ``outgoing/0000-cover-letter.patch`` para edição, você
+notará que ele terá o trailer ``base-commit:`` bem no
+final, o qual fornece ao revisor e às ferramentas de CI informações suficientes
+para realizar o ``git am`` adequadamente sem se preocupar com conflitos::
+
+    $ git checkout -b patch-review [base-commit-id]
+    Switched to a new branch 'patch-review'
+    $ git am patches.mbox
+    Applying: First Commit
+    Applying: ...
+
+Por favor, veja ``man git-format-patch`` para mais informações sobre esta
+opção.
+
+.. note::
+
+    A funcionalidade ``--base`` foi introduzida no git versão 2.9.0.
+
+Se você não estiver usando git para formatar seus patches, você ainda pode incluir
+o mesmo trailer ``base-commit`` para indicar o hash do commit da árvore
+na qual seu trabalho se baseia. Você deve adicioná-lo na cover
+letter (carta de apresentação) ou no primeiro patch da série e ele deve ser colocado
+abaixo da linha ``---`` ou bem no final de todo o outro
+conteúdo, logo antes da sua assinatura de e-mail.
+
+Certifique-se de que o commit base está em uma árvore oficial de mantenedor/mainline
+e não em alguma árvore interna acessível apenas por você - caso contrário seria
+inútil.
+
+Ferramentas
+-----------
+
+Muitos dos aspectos técnicos deste processo podem ser automatizados usando
+b4, documentado em <https://b4.docs.kernel.org/en/latest/>. Isso pode
+ajudar com coisas como rastreamento de dependências, execução do checkpatch e
+com a formatação e o envio de e-mails.
+
+Referências
+-----------
+
+Andrew Morton, "The perfect patch" (tpp).
+  <https://www.ozlabs.org/~akpm/stuff/tpp.txt>
+
+Jeff Garzik, "Linux kernel patch submission format".
+  <https://web.archive.org/web/20180829112450/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>
+
+Kernel Documentation/process/coding-style.rst
+
+Linus Torvalds's mail on the canonical patch format:
+  <https://lore.kernel.org/r/Pine.LNX.4.58.0504071023190.28951@ppc970.osdl.org>
+
+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/pt_BR/process/volatile-considered-harmful.rst b/Documentation/translations/pt_BR/process/volatile-considered-harmful.rst
new file mode 100644
index 000000000000..b8774c0bae77
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/volatile-considered-harmful.rst
@@ -0,0 +1,130 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Por que a classe de tipo "volatile" não deve ser usada
+--------------------------------------------------------
+
+Programadores C frequentemente interpretam volatile como uma indicação de
+que uma variável pode ser alterada fora da thread de execução atual; como
+resultado, às vezes são tentados a usá-la no código do kernel quando
+estruturas de dados compartilhadas estão sendo utilizadas. Em outras
+palavras, há quem trate tipos volatile como uma espécie de variável
+atômica simplificada, mas não são. O uso de volatile no código do
+kernel quase nunca é correto; este documento explica o porquê.
+
+O ponto-chave a entender sobre volatile é que seu propósito é suprimir
+otimizações, o que quase nunca é o que realmente se deseja fazer. No kernel,
+é necessário proteger estruturas de dados compartilhadas contra acessos
+concorrentes indesejados, o que é uma tarefa bastante diferente. O processo
+de proteção contra concorrência indesejada também evita, de forma mais
+eficiente, quase todos os problemas relacionados a otimizações.
+
+Assim como volatile, as primitivas do kernel que tornam seguro o acesso
+concorrente a dados (spinlocks, mutexes, barreiras de memória etc.) são
+projetadas para evitar otimizações indesejadas. Se forem usadas
+corretamente, também não haverá necessidade de usar volatile. Se
+volatile ainda for necessário, quase certamente há algum bug no código.
+Em código de kernel corretamente escrito, volatile só serve para deixar
+as coisas mais lentas.
+
+Considere um bloco típico de código do kernel::
+
+    spin_lock(&the_lock);
+    do_something_on(&shared_data);
+    do_something_else_with(&shared_data);
+    spin_unlock(&the_lock);
+
+Se todo o código seguir as regras de bloqueio, o valor de shared_data não
+poderá mudar inesperadamente enquanto the_lock estiver mantido. Qualquer
+outro código que queira manipular esses dados estará aguardando o bloqueio.
+As primitivas de spinlock atuam como barreiras de memória (são escritas
+explicitamente para isso), o que significa que os acessos aos dados não
+serão otimizados de forma a atravessar essas barreiras. Assim, o compilador
+até pode achar que sabe qual será o valor de shared_data, mas a chamada a
+spin_lock(), por atuar como barreira de memória, o forçará a esquecer tudo
+o que sabia. Não haverá problemas de otimização nos acessos a esses dados.
+
+Se shared_data fosse declarada volatile, o bloqueio ainda seria
+necessário. No entanto, o compilador também seria impedido de otimizar o
+acesso a shared_data _dentro_ da seção crítica, justamente quando sabemos
+que ninguém mais pode estar manipulando esses dados. Enquanto o bloqueio
+estiver mantido, shared_data não é volatile. Ao lidar com dados
+compartilhados, um bloqueio adequado torna volatile desnecessário e
+potencialmente prejudicial.
+
+A classe de armazenamento volatile foi originalmente concebida para
+registradores de E/S mapeados em memória. No kernel, os acessos a esses
+registradores também devem ser protegidos por bloqueios, mas também não se
+deseja que o compilador "otimize" esses acessos dentro de uma seção crítica.
+Contudo, no kernel, os acessos à memória de E/S são sempre feitos por meio de
+funções de acesso; acessar diretamente a memória de E/S via ponteiros é
+desencorajado e não funciona em todas as arquiteturas. Essas funções de
+acesso são implementadas de modo a impedir otimizações indesejadas e,
+portanto, mais uma vez, volatile é desnecessário.
+
+Outra situação em que se pode ser tentado a usar volatile é quando o
+processador fica em espera ocupada pelo valor de uma variável. A forma
+correta de realizar essa espera ocupada é::
+
+    while (my_variable != what_i_want)
+        cpu_relax();
+
+A chamada a cpu_relax() pode reduzir o consumo de energia da CPU ou ceder
+recursos a um processador lógico gêmeo hyperthreaded; ela também atua
+como barreira para o compilador e, portanto, mais uma vez, volatile é
+desnecessário. Naturalmente, a espera ocupada já é, por si só, uma prática
+geralmente antissocial.
+
+Ainda existem algumas situações raras em que volatile faz sentido no
+kernel:
+
+  - As funções de acesso mencionadas acima podem usar volatile em
+    arquiteturas nas quais o acesso direto à memória de E/S funciona.
+    Essencialmente, cada chamada a uma função de acesso torna-se uma
+    pequena seção crítica por si só e garante que o acesso ocorra conforme
+    esperado pelo programador.
+  - Código assembly inline que modifica memória, mas não tem outros
+    efeitos colaterais visíveis, corre o risco de ser removido pelo GCC.
+    Adicionar a palavra-chave volatile às instruções asm impede essa
+    remoção.
+  - A variável jiffies é especial, pois pode ter um valor diferente a cada
+    vez que é referenciada, mas pode ser lida sem qualquer bloqueio
+    especial. Portanto, jiffies pode ser volatile, mas a adição de
+    outras variáveis desse tipo é fortemente desencorajada. Nesse
+    sentido, jiffies é considerada um problema de "legado idiota" (nas
+    palavras de Linus); corrigi-la daria mais trabalho do que valeria a
+    pena.
+  - Ponteiros para estruturas de dados em memória coerente que possam ser
+    modificadas por dispositivos de E/S podem, às vezes, ser
+    legitimamente volatile. Um buffer circular usado por um adaptador
+    de rede, no qual esse adaptador altera ponteiros para indicar quais
+    descritores já foram processados, é um exemplo desse tipo de
+    situação.
+
+Na maior parte do código, nenhuma das justificativas acima para o uso de
+volatile se aplica. Como resultado, o uso de volatile provavelmente
+será considerado um bug e fará com que o código seja submetido a uma análise
+mais rigorosa. Desenvolvedores que se sintam tentados a usar volatile devem
+dar um passo atrás e pensar no que realmente estão tentando alcançar.
+
+Patches para remover variáveis volatile são, em geral, bem-vindos, desde
+que venham acompanhados de uma justificativa que demonstre que as questões
+de concorrência foram devidamente analisadas.
+
+
+Referências
+===========
+
+[1] https://lwn.net/Articles/233481/
+
+[2] https://lwn.net/Articles/233482/
+
+Créditos
+========
+
+Motivação original e pesquisa por Randy Dunlap
+
+Escrito por Jonathan Corbet
+
+Melhorias a partir de comentários de Satyam Sharma, Johannes Stezenbach,
+Jesper Juhl, Heikki Orsila, H. Peter Anvin, Philipp Hahn e Stefan
+Richter.
diff --git a/Documentation/translations/zh_CN/admin-guide/README.rst b/Documentation/translations/zh_CN/admin-guide/README.rst
index 7c2ffe7e87c7..ee6dd3782f4a 100644
--- a/Documentation/translations/zh_CN/admin-guide/README.rst
+++ b/Documentation/translations/zh_CN/admin-guide/README.rst
@@ -83,7 +83,7 @@ Linux内核6.x版本 <http://kernel.org/>
    补丁，则不应先应用6.0.1和6.0.2的补丁。类似地，如果您运行的是6.0.2内核，
    并且希望跳转到6.0.3，那么在应用6.0.3补丁之前，必须首先撤销6.0.2补丁
    （即patch -R）。更多关于这方面的内容，请阅读
-   :ref:`Documentation/process/applying-patches.rst <applying_patches>` 。
+   Documentation/translations/zh_CN/process/applying-patches.rst 。
 
    或者，脚本 patch-kernel 可以用来自动化这个过程。它能确定当前内核版本并
    应用找到的所有补丁::
diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst
index 6f8676a50b38..77bbfa7c25dc 100644
--- a/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst
+++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst
@@ -9,12 +9,12 @@
 
 :校译:
 
-============
-监测数据访问
-============
+========================================
+DAMON：数据访问监测和访问感知系统操作
+========================================
 
-:doc:`DAMON </mm/damon/index>` 允许轻量级的数据访问监测。使用DAMON，
-用户可以分析他们系统的内存访问模式，并优化它们。
+:doc:`DAMON <../../../mm/damon/index>` 是一个 Linux 内核子系统，用于高效的
+数据访问监测和访问感知系统操作。
 
 .. toctree::
    :maxdepth: 2
@@ -23,7 +23,4 @@
    usage
    reclaim
    lru_sort
-
-
-
-
+   stat
diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/lru_sort.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/lru_sort.rst
index 03d33c710604..6af0dd59ef5d 100644
--- a/Documentation/translations/zh_CN/admin-guide/mm/damon/lru_sort.rst
+++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/lru_sort.rst
@@ -48,7 +48,7 @@ DAMON_LRU_SORT使用DAMON寻找热页（范围内的页面访问频率高于用�
 
 为了让系统管理员打开或者关闭并且调节指定的系统，DAMON_LRU_SORT设计了模块参数。
 这意味着，你可以添加 ``damon_lru_sort.<parameter>=<value>`` 到内核的启动命令行
-参数，或者在 ``/sys/modules/damon_lru_sort/parameters/<parameter>`` 写入正确的
+参数，或者在 ``/sys/module/damon_lru_sort/parameters/<parameter>`` 写入正确的
 值。
 
 下边是每个参数的描述
@@ -71,6 +71,41 @@ commit_inputs
 ，DAMON_LRU_SORT会再次读取除了 ``enabled`` 之外的参数。读取完成后，这个参数会被
 设置为 ``N`` 。如果在读取时发现有无效参数，DAMON_LRU_SORT会被关闭。
 
+一旦向该参数写入 ``Y``，用户在再次读取 ``commit_inputs`` 返回 ``N`` 之前，
+不得写入任何参数。如果用户违反该规则，内核可能表现出未定义行为。
+
+active_mem_bp
+-------------
+
+期望的活跃内存与[非]活跃内存比率，单位为 bp（1/10,000）。
+
+在保持其他配额设置的上限的同时，DAMON_LRU_SORT 会自动增减配额的有效水平，
+目标是让热/冷内存的 LRU [降低]优先级处理产生该活跃内存与[非]活跃内存比率。
+值为零表示禁用该自动调优功能。
+
+默认禁用。
+
+autotune_monitoring_intervals
+-----------------------------
+
+如果该参数设置为 ``Y``，DAMON_LRU_SORT 会自动调优 DAMON 的采样和聚集间隔。
+自动调优的目标是在每个 DAMON 快照中捕获有意义数量的访问事件，同时将采样
+间隔限制在最小 5 毫秒、最大 10 秒。将其设置为 ``N`` 会禁用自动调优。
+
+默认禁用。
+
+filter_young_pages
+------------------
+
+相应地为 LRU [降低]优先级处理过滤[非]年轻页。
+
+如果设置该参数，则在每次 LRU [降低]优先级处理操作前再次检查页级访问
+（年轻性）。如果该页自上次检查以来未被访问（不年轻），则跳过 LRU 提高
+优先级操作。如果该页自上次检查以来已被访问（年轻），则跳过 LRU 降低优先级
+操作。当该参数分别设置为 ``Y`` 或 ``N`` 时，会启用或禁用该功能。
+
+默认禁用。
+
 hot_thres_access_freq
 ---------------------
 
@@ -163,6 +198,8 @@ min_nr_regions
 对冷内存区域监测的最小数量。这个值可以作为监测质量的下限。不过，这个值设置的过
 大会增加开销。更多细节请参考DAMON文档 (:doc:`usage`) 。默认值为10。
 
+请注意，该值必须为 3 或更高。该下限的理由请参考设计文档的 :ref:`监测 <damon_design_monitoring_zh_CN>` 章节。
+
 max_nr_regions
 --------------
 
@@ -176,14 +213,34 @@ monitor_region_start
 
 目标内存区域的起始物理地址。
 
-DAMON_LRU_SORT要处理的目标内存区域的起始物理地址。默认，使用系统最大内存。
+DAMON_LRU_SORT要处理的目标内存区域的起始物理地址。默认，使用系统的整个物理内存。
 
 monitor_region_end
 ------------------
 
 目标内存区域的结束物理地址。
 
-DAMON_LRU_SORT要处理的目标内存区域的结束物理地址。默认，使用系统最大内存。
+DAMON_LRU_SORT要处理的目标内存区域的结束物理地址。默认，使用系统的整个物理内存。
+
+addr_unit
+---------
+
+内存地址和字节数的缩放因子。
+
+该参数用于设置和获取 DAMON_RECLAIM 的 DAMON 实例的 :ref:`地址单位 <damon_design_addr_unit_zh_CN>` 参数。
+
+``monitor_region_start`` 和 ``monitor_region_end`` 应以该单位提供。例如，
+假设 ``addr_unit``、``monitor_region_start`` 和 ``monitor_region_end``
+分别设置为 ``1024``、``0`` 和 ``10``。那么 DAMON_LRU_SORT 将处理从地址零
+开始、长度为 10 KiB 的物理地址范围（以字节表示为
+``[0 * 1024, 10 * 1024)``）。
+
+带有 ``bytes_`` 前缀的统计参数也使用该单位。例如，假设 ``addr_unit``、
+``bytes_lru_sort_tried_hot_regions`` 和 ``bytes_lru_sorted_hot_regions`` 的值
+分别为 ``1024``、``42`` 和 ``32``。那么这表示 DAMON_LRU_SORT 尝试对
+42 KiB 热内存进行 LRU 排序，并总共成功对其中 32 KiB 内存进行了 LRU 排序。
+
+如果不确定，只使用默认值（``1``）并忘记这个参数即可。
 
 kdamond_pid
 -----------
@@ -252,7 +309,7 @@ LRU的优先级的提升，同时降低那些超过120秒无人访问的内存�
 进展且空闲内存低于20%，再次让DAMON_LRU_SORT停止工作，以此回退到以LRU链表为基础
 以页面为单位的内存回收上。 ::
 
-    # cd /sys/modules/damon_lru_sort/parameters
+    # cd /sys/module/damon_lru_sort/parameters
     # echo 500 > hot_thres_access_freq
     # echo 120000000 > cold_min_age
     # echo 10 > quota_ms
@@ -261,3 +318,6 @@ LRU的优先级的提升，同时降低那些超过120秒无人访问的内存�
     # echo 400 > wmarks_mid
     # echo 200 > wmarks_low
     # echo Y > enabled
+
+请注意，该模块（damon_lru_sort）不能与其他基于 DAMON 的专用模块同时运行。
+更多细节请参考 :ref:`DAMON 设计文档的专用模块互斥性 <damon_design_special_purpose_modules_exclusivity_zh_CN>`。
diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst
index d14ba32f7788..1e9375947295 100644
--- a/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst
+++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst
@@ -58,6 +58,19 @@ enabled
 DAMON_RECLAIM。注意，由于基于水位的激活条件，DAMON_RECLAIM不能进行真正的监测和回收。
 这一点请参考下面关于水位参数的描述。
 
+commit_inputs
+-------------
+
+让 DAMON_RECLAIM 再次读取除 ``enabled`` 外的输入参数。
+
+DAMON_RECLAIM 运行期间更新的输入参数默认不会应用。一旦该参数被设置为
+``Y``，DAMON_RECLAIM 会再次读取除 ``enabled`` 外的参数值。重新读取完成后，
+该参数会被设置为 ``N``。如果重新读取时发现无效参数，DAMON_RECLAIM 会被
+禁用。
+
+一旦向该参数写入 ``Y``，用户在再次读取 ``commit_inputs`` 返回 ``N`` 之前，
+不得写入任何参数。如果用户违反该规则，内核可能表现出未定义行为。
+
 min_age
 -------
 
@@ -68,6 +81,15 @@ min_age
 
 默认为120秒。
 
+autotune_monitoring_intervals
+-----------------------------
+
+如果该参数设置为 ``Y``，DAMON_RECLAIM 会自动调优 DAMON 的采样和聚集间隔。
+自动调优的目标是在每个 DAMON 快照中捕获有意义数量的访问事件，同时将采样
+间隔限制在最小 5 毫秒、最大 10 秒。将其设置为 ``N`` 会禁用自动调优。
+
+默认禁用。
+
 quota_ms
 --------
 
@@ -98,6 +120,29 @@ quota_reset_interval_ms
 
 默认为1秒。
 
+quota_mem_pressure_us
+---------------------
+
+期望的内存压力停滞时间水平，单位为微秒。
+
+在保持其他配额设置的上限的同时，DAMON_RECLAIM 会自动增减配额的有效水平，
+目标是产生该水平的内存压力。系统范围的 ``some`` 内存 PSI 会按每个配额重置
+间隔（``quota_reset_interval_ms``）以微秒为单位收集，并与该值比较，以判断
+目标是否满足。值为零表示禁用该自动调优功能。
+
+默认禁用。
+
+quota_autotune_feedback
+-----------------------
+
+用户可指定的有效配额自动调优反馈。
+
+在保持其他配额设置的上限的同时，DAMON_RECLAIM 会自动增减配额的有效水平，
+目标是从用户接收到值为 ``10,000`` 的反馈。DAMON_RECLAIM 假定反馈值和配额
+成正比。值为零表示禁用该自动调优功能。
+
+默认禁用。
+
 wmarks_interval
 ---------------
 
@@ -149,6 +194,8 @@ min_nr_regions
 DAMON用于冷内存监测的最小监测区域数。这可以用来设置监测质量的下限。但是，设
 置的太高可能会导致监测开销的增加。更多细节请参考DAMON文档 (:doc:`usage`) 。
 
+请注意，该值必须为 3 或更高。该下限的理由请参考设计文档的 :ref:`监测 <damon_design_monitoring_zh_CN>` 章节。
+
 max_nr_regions
 --------------
 
@@ -163,7 +210,7 @@ monitor_region_start
 目标内存区域的物理地址起点。
 
 DAMON_RECLAIM将对其进行工作的内存区域的起始物理地址。也就是说，DAMON_RECLAIM
-将在这个区域中找到冷的内存区域并进行回收。默认情况下，该区域使用最大系统内存区。
+将在这个区域中找到冷的内存区域并进行回收。默认情况下，该区域使用系统的整个物理内存。
 
 monitor_region_end
 ------------------
@@ -171,7 +218,35 @@ monitor_region_end
 目标内存区域的结束物理地址。
 
 DAMON_RECLAIM将对其进行工作的内存区域的末端物理地址。也就是说，DAMON_RECLAIM将
-在这个区域内找到冷的内存区域并进行回收。默认情况下，该区域使用最大系统内存区。
+在这个区域内找到冷的内存区域并进行回收。默认情况下，该区域使用系统的整个物理内存。
+
+addr_unit
+---------
+
+内存地址和字节数的缩放因子。
+
+该参数用于设置和获取 DAMON_RECLAIM 的 DAMON 实例的 :ref:`地址单位 <damon_design_addr_unit_zh_CN>` 参数。
+
+``monitor_region_start`` 和 ``monitor_region_end`` 应以该单位提供。例如，
+假设 ``addr_unit``、``monitor_region_start`` 和 ``monitor_region_end``
+分别设置为 ``1024``、``0`` 和 ``10``。那么 DAMON_RECLAIM 将处理从地址零
+开始、长度为 10 KiB 的物理地址范围（以字节表示为
+``[0 * 1024, 10 * 1024)``）。
+
+``bytes_reclaim_tried_regions`` 和 ``bytes_reclaimed_regions`` 也使用该单位。
+例如，假设 ``addr_unit``、``bytes_reclaim_tried_regions`` 和
+``bytes_reclaimed_regions`` 的值分别为 ``1024``、``42`` 和 ``32``。那么这
+表示 DAMON_RECLAIM 总共尝试回收 42 KiB 内存，并成功回收了 32 KiB 内存。
+
+如果不确定，只使用默认值（``1``）并忘记这个参数即可。
+
+skip_anon
+---------
+
+跳过匿名页回收。
+
+如果该参数设置为 ``Y``，DAMON_RECLAIM 不会回收匿名页。默认值为 ``N``。
+
 
 kdamond_pid
 -----------
@@ -223,6 +298,9 @@ DAMON_RECLAIM再次什么都不做，这样我们就可以退回到基于LRU列�
     # echo 200 > wmarks_low
     # echo Y > enabled
 
+请注意，该模块（damon_reclaim）不能与其他基于 DAMON 的专用模块同时运行。
+更多细节请参考 :ref:`DAMON 设计文档的专用模块互斥性 <damon_design_special_purpose_modules_exclusivity_zh_CN>`。
+
 .. [1] https://research.google/pubs/pub48551/
 .. [2] https://lwn.net/Articles/787611/
 .. [3] https://www.kernel.org/doc/html/latest/mm/free_page_reporting.html
diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/start.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/start.rst
index cff7b6f98c59..1a7f3382dd15 100644
--- a/Documentation/translations/zh_CN/admin-guide/mm/damon/start.rst
+++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/start.rst
@@ -35,18 +35,63 @@ https://github.com/damonitor/damo找到。下面的例子假设DAMO在你的$PAT
 这并不是强制性的。
 
 因为DAMO使用了DAMON的sysfs接口（详情请参考:doc:`usage`），你应该确保
-:doc:`sysfs </filesystems/sysfs>` 被挂载。
+``sysfs`` 被挂载。
+
+
+拍摄数据访问模式快照
+====================
+
+下面的命令展示程序在执行时刻的内存访问模式。::
+
+    $ git clone https://github.com/sjp38/masim; cd masim; make
+    $ sudo damo start "./masim ./configs/stairs.cfg --quiet"
+    $ sudo damo report access
+    heatmap: 641111111000000000000000000000000000000000000000000000[...]33333333333333335557984444[...]7
+    # min/max temperatures: -1,840,000,000, 370,010,000, column size: 3.925 MiB
+    0   addr 86.182 TiB   size 8.000 KiB   access 0 %   age 14.900 s
+    1   addr 86.182 TiB   size 8.000 KiB   access 60 %  age 0 ns
+    2   addr 86.182 TiB   size 3.422 MiB   access 0 %   age 4.100 s
+    3   addr 86.182 TiB   size 2.004 MiB   access 95 %  age 2.200 s
+    4   addr 86.182 TiB   size 29.688 MiB  access 0 %   age 14.100 s
+    5   addr 86.182 TiB   size 29.516 MiB  access 0 %   age 16.700 s
+    6   addr 86.182 TiB   size 29.633 MiB  access 0 %   age 17.900 s
+    7   addr 86.182 TiB   size 117.652 MiB access 0 %   age 18.400 s
+    8   addr 126.990 TiB  size 62.332 MiB  access 0 %   age 9.500 s
+    9   addr 126.990 TiB  size 13.980 MiB  access 0 %   age 5.200 s
+    10  addr 126.990 TiB  size 9.539 MiB   access 100 % age 3.700 s
+    11  addr 126.990 TiB  size 16.098 MiB  access 0 %   age 6.400 s
+    12  addr 127.987 TiB  size 132.000 KiB access 0 %   age 2.900 s
+    total size: 314.008 MiB
+    $ sudo damo stop
+
+上面示例的第一条命令下载并构建一个名为 ``masim`` 的人工内存访问
+生成程序。第二条命令要求 DAMO 用给定命令启动该程序，并让 DAMON
+监测新启动的进程。第三条命令从 DAMON 取回该进程当前被监测访问
+模式的快照，并以人类可读的格式显示该模式。
+
+输出的第一行以单行热图格式显示各区域的相对访问温度（热度）。热图
+中的每一列表示被监测虚拟地址空间上大小相同的区域。列在该行中的
+位置和列上的数字表示该区域的相对位置和访问温度。``[...]`` 表示
+虚拟地址空间中未映射的巨大区域。第二行显示帮助理解热图的附加信息。
+
+从第三行开始，输出的每一行显示进程的哪个虚拟地址范围
+（``addr XX size XX``）被访问得有多频繁（``access XX %``），以及
+持续了多长时间（``age XX``）。例如，大小约为 9.5 MiB 的第十一个
+区域在最近 3.7 秒内被访问得最频繁。最后，第四条命令停止 DAMON。
+
+请注意，DAMON 不仅能监测虚拟地址空间，还能监测包括物理地址空间在内
+的多种地址空间。
+
 
 记录数据访问模式
 ================
 
 下面的命令记录了一个程序的内存访问模式，并将监测结果保存到文件中。 ::
 
-    $ git clone https://github.com/sjp38/masim
-    $ cd masim; make; ./masim ./configs/zigzag.cfg &
+    $ ./masim ./configs/zigzag.cfg &
     $ sudo damo record -o damon.data $(pidof masim)
 
-命令的前两行下载了一个人工内存访问生成器程序并在后台运行。生成器将重复地逐一访问两个
+第一行命令再次运行该人工内存访问生成器程序。生成器将重复地逐一访问两个
 100 MiB大小的内存区域。你可以用你的真实工作负载来代替它。最后一行要求 ``damo`` 将
 访问模式记录在 ``damon.data`` 文件中。
 
@@ -57,7 +102,7 @@ https://github.com/damonitor/damo找到。下面的例子假设DAMO在你的$PAT
 你可以在heatmap中直观地看到这种模式，显示哪个内存区域（X轴）何时被访问（Y轴）以及访
 问的频率（数字）。::
 
-    $ sudo damo report heats --heatmap stdout
+    $ sudo damo report heatmap
     22222222222222222222222222222222222222211111111111111111111111111111111111111100
     44444444444444444444444444444444444444434444444444444444444444444444444444443200
     44444444444444444444444444444444444444433444444444444444444444444444444444444200
@@ -117,8 +162,8 @@ https://github.com/damonitor/damo找到。下面的例子假设DAMO在你的$PAT
 数据访问模式感知的内存管理
 ==========================
 
-以下三个命令使每一个大小>=4K的内存区域在你的工作负载中没有被访问>=60秒，就会被换掉。 ::
+以下命令使每一个大小>=4K的内存区域在你的工作负载中没有被访问>=60秒，就会被换掉。 ::
 
-    $ echo "#min-size max-size min-acc max-acc min-age max-age action" > test_scheme
-    $ echo "4K        max      0       0       60s     max     pageout" >> test_scheme
-    $ damo schemes -c test_scheme <pid of your workload>
+    $ sudo damo start --damos_access_rate 0 0 --damos_sz_region 4K max \
+                      --damos_age 60s max --damos_action pageout \
+                      --target_pid <pid of your workload>
diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/stat.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/stat.rst
new file mode 100644
index 000000000000..129748a5ea1f
--- /dev/null
+++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/stat.rst
@@ -0,0 +1,94 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../../../disclaimer-zh_CN.rst
+
+:Original: Documentation/admin-guide/mm/damon/stat.rst
+
+:翻译:
+
+ Doehyun Baek <doehyunbaek@gmail.com>
+
+====================
+数据访问监测结果统计
+====================
+
+数据访问监测结果统计（DAMON_STAT）是一个静态内核模块，旨在用于简单的
+访问模式监测。它使用 DAMON 监测系统整个物理内存上的访问，并提供简化的
+访问监测结果统计，即空闲时间百分位数和估计的内存带宽。
+
+.. _damon_stat_monitoring_accuracy_overhead_zh_CN:
+
+监测精度和开销
+==============
+
+DAMON_STAT 使用监测间隔
+:ref:`自动调优 <damon_design_monitoring_intervals_autotuning_zh_CN>` 来提高
+精度并最小化开销。它会自动调优间隔，目标是在每个快照中捕获 4 % 的
+可观测访问事件，同时将得到的采样间隔限制在最小 5 毫秒、最大 10 秒。
+在少数生产服务器系统上，它的结果是只消耗 0.x % 的单个 CPU 时间，同时
+捕获质量合理的访问模式。调优得到的间隔可以通过
+``aggr_interval_us`` :ref:`参数 <damon_stat_aggr_interval_us_zh_CN>` 获取。
+
+接口：模块参数
+==============
+
+要使用这个功能，首先应确保你的系统运行在构建时启用了
+``CONFIG_DAMON_STAT=y`` 的内核上。通过将
+``CONFIG_DAMON_STAT_ENABLED_DEFAULT`` 设置为 true，可以在构建时默认
+启用该功能。
+
+为了让系统管理员在启动时和/或运行时启用或禁用它，并读取监测结果，
+DAMON_STAT 提供了模块参数。下面的章节描述这些参数。
+
+enabled
+-------
+
+启用或禁用 DAMON_STAT。
+
+你可以将该参数的值设置为 ``Y`` 来启用 DAMON_STAT。设置为 ``N`` 会
+禁用 DAMON_STAT。默认值由 ``CONFIG_DAMON_STAT_ENABLED_DEFAULT`` 构建
+配置选项设置。
+
+请注意，该模块（damon_stat）不能与其他基于 DAMON 的专用模块同时运行。
+更多细节请参考 :ref:`DAMON 设计文档的专用模块互斥性 <damon_design_special_purpose_modules_exclusivity_zh_CN>`。
+
+.. _damon_stat_aggr_interval_us_zh_CN:
+
+aggr_interval_us
+----------------
+
+自动调优后的聚集时间间隔，单位是微秒。
+
+用户可以读取 DAMON_STAT 使用的 DAMON 实例的聚集间隔。它会被
+:ref:`自动调优 <damon_stat_monitoring_accuracy_overhead_zh_CN>`，因此该值
+会动态变化。
+
+estimated_memory_bandwidth
+--------------------------
+
+系统的估计内存带宽消耗（字节/秒）。
+
+DAMON_STAT 读取当前 DAMON 结果快照上的观测访问事件，并将其转换为以
+字节/秒为单位的内存带宽消耗估计。得到的指标通过这个只读参数向用户
+公开。由于 DAMON 使用采样，所以这只是访问强度的估计，而不是精确的
+内存带宽。
+
+memory_idle_ms_percentiles
+--------------------------
+
+系统的逐字节空闲时间（毫秒）百分位数。
+
+DAMON_STAT 基于当前 DAMON 结果快照，计算内存中每个字节到现在为止未被
+访问的时间（空闲时间）。对于访问频率（nr_accesses）大于零的区域，当前
+访问频率水平保持的时间乘以 ``-1``，就是该区域每个字节的空闲时间。如果
+某个区域的访问频率（nr_accesses）为零，则该区域保持零访问频率的时间
+（age）就是该区域每个字节的空闲时间。然后，DAMON_STAT 通过这个只读参数
+公开空闲时间值的百分位数。读取该参数会返回 101 个以毫秒为单位、用逗号
+分隔的空闲时间值。每个值分别表示第 0、第 1、第 2、第 3、……、第 99 和
+第 100 百分位的空闲时间。
+
+kdamond_pid
+-----------
+
+DAMON 线程的 PID。
+
+如果 DAMON_STAT 已启用，这将成为工作线程的 PID。否则为 -1。
diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst
index 9d7cb51be493..f2fe1c8025fa 100644
--- a/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst
+++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst
@@ -15,22 +15,27 @@
 
 DAMON 为不同的用户提供了下面这些接口。
 
+- *专用 DAMON 模块。*
+  :ref:`这 <damon_modules_special_purpose_zh_CN>` 是为那些正在构建、发布和/或管理
+  带有专用 DAMON 用法的内核的人准备的。使用它，用户可以在构建、启动或运行时，
+  以简单的方式为给定目的使用 DAMON 的主要功能。
 - *DAMON用户空间工具。*
   `这 <https://github.com/damonitor/damo>`_ 为有这特权的人， 如系统管理员，希望有一个刚好
   可以工作的人性化界面。
   使用它，用户可以以人性化的方式使用DAMON的主要功能。不过，它可能不会为特殊情况进行高度调整。
-  它同时支持虚拟和物理地址空间的监测。更多细节，请参考它的 `使用文档
+  更多细节，请参考它的 `使用文档
   <https://github.com/damonitor/damo/blob/next/USAGE.md>`_。
 - *sysfs接口。*
-  :ref:`这 <sysfs_interface>` 是为那些希望更高级的使用DAMON的特权用户空间程序员准备的。
+  :ref:`这 <sysfs_interface_zh_CN>` 是为那些希望更高级的使用DAMON的特权用户空间程序员准备的。
   使用它，用户可以通过读取和写入特殊的sysfs文件来使用DAMON的主要功能。因此，你可以编写和使
   用你个性化的DAMON sysfs包装程序，代替你读/写sysfs文件。  `DAMON用户空间工具
-  <https://github.com/damonitor/damo>`_ 就是这种程序的一个例子  它同时支持虚拟和物理地址
-  空间的监测。
+  <https://github.com/damonitor/damo>`_ 就是这种程序的一个例子。
 - *内核空间编程接口。*
-  :doc:`这 </mm/damon/api>` 这是为内核空间程序员准备的。使用它，用户可以通过为你编写内
+  :doc:`这 <../../../mm/damon/api>` 这是为内核空间程序员准备的。使用它，用户可以通过为你编写内
   核空间的DAMON应用程序，最灵活有效地利用DAMON的每一个功能。你甚至可以为各种地址空间扩展DAMON。
-  详细情况请参考接口 :doc:`文件 </mm/damon/api>`。
+  详细情况请参考接口 :doc:`文件 <../../../mm/damon/api>`。
+
+.. _sysfs_interface_zh_CN:
 
 sysfs接口
 =========
@@ -51,39 +56,61 @@ DAMON的sysfs接口是在定义 ``CONFIG_DAMON_SYSFS`` 时建立的。它在其s
 ------------
 
 DAMON sysfs接口的文件层次结构如下图所示。在下图中，父子关系用缩进表示，每个目录有
-``/`` 后缀，每个目录中的文件用逗号（","）分开。 ::
-
-    /sys/kernel/mm/damon/admin
-    │ kdamonds/nr_kdamonds
-    │ │ 0/state,pid
-    │ │ │ contexts/nr_contexts
-    │ │ │ │ 0/operations
-    │ │ │ │ │ monitoring_attrs/
+``/`` 后缀，每个目录中的文件用逗号（","）分开。
+
+.. parsed-literal::
+
+    :ref:`/sys/kernel/mm/damon <sysfs_root_zh_CN>`/admin
+    │ :ref:`kdamonds <sysfs_kdamonds_zh_CN>`/nr_kdamonds
+    │ │ :ref:`0 <sysfs_kdamond_zh_CN>`/state,pid,refresh_ms
+    │ │ │ :ref:`contexts <sysfs_contexts_zh_CN>`/nr_contexts
+    │ │ │ │ :ref:`0 <sysfs_context_zh_CN>`/avail_operations,operations,addr_unit,
+    │ │ │ │   pause
+    │ │ │ │ │ :ref:`monitoring_attrs <sysfs_monitoring_attrs_zh_CN>`/
     │ │ │ │ │ │ intervals/sample_us,aggr_us,update_us
+    │ │ │ │ │ │ │ intervals_goal/access_bp,aggrs,min_sample_us,max_sample_us
     │ │ │ │ │ │ nr_regions/min,max
-    │ │ │ │ │ targets/nr_targets
-    │ │ │ │ │ │ 0/pid_target
-    │ │ │ │ │ │ │ regions/nr_regions
-    │ │ │ │ │ │ │ │ 0/start,end
+    │ │ │ │ │ │ :ref:`probes <damon_usage_sysfs_probes_zh_CN>`/nr_probes
+    │ │ │ │ │ │ │ 0/filters/nr_filters
+    │ │ │ │ │ │ │ │ 0/type,matching,allow,path
+    │ │ │ │ │ │ │ │ ...
+    │ │ │ │ │ │ │ ...
+    │ │ │ │ │ :ref:`targets <sysfs_targets_zh_CN>`/nr_targets
+    │ │ │ │ │ │ :ref:`0 <sysfs_target_zh_CN>`/pid_target,obsolete_target
+    │ │ │ │ │ │ │ :ref:`regions <sysfs_regions_zh_CN>`/nr_regions
+    │ │ │ │ │ │ │ │ :ref:`0 <sysfs_region_zh_CN>`/start,end
     │ │ │ │ │ │ │ │ ...
     │ │ │ │ │ │ ...
-    │ │ │ │ │ schemes/nr_schemes
-    │ │ │ │ │ │ 0/action
-    │ │ │ │ │ │ │ access_pattern/
+    │ │ │ │ │ :ref:`schemes <sysfs_schemes_zh_CN>`/nr_schemes
+    │ │ │ │ │ │ :ref:`0 <sysfs_scheme_zh_CN>`/action,target_nid,apply_interval_us
+    │ │ │ │ │ │ │ :ref:`access_pattern <sysfs_access_pattern_zh_CN>`/
     │ │ │ │ │ │ │ │ sz/min,max
     │ │ │ │ │ │ │ │ nr_accesses/min,max
     │ │ │ │ │ │ │ │ age/min,max
-    │ │ │ │ │ │ │ quotas/ms,bytes,reset_interval_ms
+    │ │ │ │ │ │ │ :ref:`quotas <sysfs_quotas_zh_CN>`/ms,bytes,reset_interval_ms,
+    │ │ │ │ │ │ │     effective_bytes,goal_tuner,
+    │ │ │ │ │ │ │     fail_charge_num,fail_charge_denom
     │ │ │ │ │ │ │ │ weights/sz_permil,nr_accesses_permil,age_permil
-    │ │ │ │ │ │ │ watermarks/metric,interval_us,high,mid,low
-    │ │ │ │ │ │ │ stats/nr_tried,sz_tried,nr_applied,sz_applied,qt_exceeds
-    │ │ │ │ │ │ │ tried_regions/
-    │ │ │ │ │ │ │ │ 0/start,end,nr_accesses,age
+    │ │ │ │ │ │ │ │ :ref:`goals <sysfs_schemes_quota_goals_zh_CN>`/nr_goals
+    │ │ │ │ │ │ │ │ │ 0/target_metric,target_value,current_value,nid,path
+    │ │ │ │ │ │ │ :ref:`watermarks <sysfs_watermarks_zh_CN>`/metric,interval_us,high,mid,low
+    │ │ │ │ │ │ │ :ref:`{core_,ops_,}filters <sysfs_filters_zh_CN>`/nr_filters
+    │ │ │ │ │ │ │ │ 0/type,matching,allow,memcg_path,addr_start,addr_end,damon_target_idx,min,max
+    │ │ │ │ │ │ │ :ref:`dests <damon_sysfs_dests_zh_CN>`/nr_dests
+    │ │ │ │ │ │ │ │ 0/id,weight
+    │ │ │ │ │ │ │ :ref:`stats <sysfs_schemes_stats_zh_CN>`/nr_tried,sz_tried,nr_applied,sz_applied,sz_ops_filter_passed,qt_exceeds,nr_snapshots,max_nr_snapshots
+    │ │ │ │ │ │ │ :ref:`tried_regions <sysfs_schemes_tried_regions_zh_CN>`/total_bytes
+    │ │ │ │ │ │ │ │ 0/start,end,nr_accesses,age,sz_filter_passed
+    │ │ │ │ │ │ │ │ │ probes
+    │ │ │ │ │ │ │ │ │ │ 0/hits
+    │ │ │ │ │ │ │ │ │ │ ...
     │ │ │ │ │ │ │ │ ...
     │ │ │ │ │ │ ...
     │ │ │ │ ...
     │ │ ...
 
+.. _sysfs_root_zh_CN:
+
 根
 --
 
@@ -91,58 +118,100 @@ DAMON sysfs接口的根是 ``<sysfs>/kernel/mm/damon/`` ，它有一个名为 ``
 目录。该目录包含特权用户空间程序控制DAMON的文件。拥有根权限的用户空间工具或deamons可以
 使用这个目录。
 
+.. _sysfs_kdamonds_zh_CN:
+
 kdamonds/
 ---------
 
-与监测相关的信息包括请求规格和结果被称为DAMON上下文。DAMON用一个叫做kdamond的内核线程
-执行每个上下文，多个kdamonds可以并行运行。
-
-在 ``admin`` 目录下，有一个目录，即``kdamonds``，它有控制kdamonds的文件存在。在开始
+在 ``admin`` 目录下，有一个目录，即``kdamonds``，它有控制kdamonds的文件存在（更多
+细节请参考 :ref:`设计 <damon_design_execution_model_and_data_structures_zh_CN>`）。在开始
 时，这个目录只有一个文件，``nr_kdamonds``。向该文件写入一个数字（``N``），就会创建名为
 ``0`` 到 ``N-1`` 的子目录数量。每个目录代表每个kdamond。
 
+.. _sysfs_kdamond_zh_CN:
+
 kdamonds/<N>/
 -------------
 
-在每个kdamond目录中，存在两个文件（``state`` 和 ``pid`` ）和一个目录( ``contexts`` )。
+在每个kdamond目录中，存在三个文件（``state`` 、 ``pid`` 和 ``refresh_ms`` ）和一个目录( ``contexts`` )。
 
 读取 ``state`` 时，如果kdamond当前正在运行，则返回 ``on`` ，如果没有运行则返回 ``off`` 。
-写入 ``on`` 或 ``off`` 使kdamond处于状态。向 ``state`` 文件写 ``update_schemes_stats`` ，
-更新kdamond的每个基于DAMON的操作方案的统计文件的内容。关于统计信息的细节，请参考
-:ref:`stats section <sysfs_schemes_stats>`. 将 ``update_schemes_tried_regions`` 写到
-``state`` 文件，为kdamond的每个基于DAMON的操作方案，更新基于DAMON的操作方案动作的尝试区域目录。
-将`clear_schemes_tried_regions`写入`state`文件，清除kdamond的每个基于DAMON的操作方案的动作
-尝试区域目录。 关于基于DAMON的操作方案动作尝试区域目录的细节，请参考:ref:tried_regions 部分
-<sysfs_schemes_tried_regions>`。
+
+用户可以向 ``state`` 文件写入以下kdamond命令。
+
+- ``on``：开始运行。
+- ``off``：停止运行。
+- ``commit``：再次读取除 ``state`` 文件之外的 sysfs 文件中的用户输入。
+  如果没有指定目标区域，也会忽略监测 :ref:`目标区域 <sysfs_regions_zh_CN>`
+  输入。
+- ``update_tuned_intervals``：用自动调优后的 ``sampling interval`` 和
+  ``aggregation interval`` 更新该 kdamond 的 ``sample_us`` 和
+  ``aggr_us`` 文件内容。更多细节请参考 :ref:`intervals_goal 章节
+  <damon_usage_sysfs_monitoring_intervals_goal_zh_CN>`。
+- ``commit_schemes_quota_goals``：读取基于 DAMON 的操作方案的
+  :ref:`配额目标 <sysfs_schemes_quota_goals_zh_CN>`。
+- ``update_schemes_stats``：更新该 kdamond 的每个基于 DAMON 的操作方案的
+  统计文件内容。关于统计信息的细节，请参考 :ref:`stats 章节
+  <sysfs_schemes_stats_zh_CN>`。
+- ``update_schemes_tried_regions``：为该 kdamond 的每个基于 DAMON 的
+  操作方案，更新基于 DAMON 的操作方案动作尝试区域目录。关于基于 DAMON
+  的操作方案动作尝试区域目录的细节，请参考 :ref:`tried_regions 章节
+  <sysfs_schemes_tried_regions_zh_CN>`。
+- ``update_schemes_tried_bytes``：只更新 ``.../tried_regions/total_bytes``
+  文件。
+- ``clear_schemes_tried_regions``：为该 kdamond 的每个基于 DAMON 的
+  操作方案，清除基于 DAMON 的操作方案动作尝试区域目录。
+- ``update_schemes_effective_quotas``：更新该 kdamond 的每个基于 DAMON
+  的操作方案的 ``effective_bytes`` 文件内容。更多细节请参考
+  :ref:`quotas 目录 <sysfs_quotas_zh_CN>`。
 
 如果状态为 ``on``，读取 ``pid`` 显示kdamond线程的pid。
 
+用户可以要求内核周期性地更新显示自动调优参数和 DAMOS 统计信息的文件，
+而不是手动向 ``state`` 文件写入 ``update_tuned_intervals`` 这类关键字。
+为此，用户应将所需的更新时间间隔（毫秒）写入 ``refresh_ms`` 文件。如果
+该间隔为零，则禁用周期性更新。读取该文件会显示当前设置的时间间隔。
+
 ``contexts`` 目录包含控制这个kdamond要执行的监测上下文的文件。
 
+.. _sysfs_contexts_zh_CN:
+
 kdamonds/<N>/contexts/
 ----------------------
 
 在开始时，这个目录只有一个文件，即 ``nr_contexts`` 。向该文件写入一个数字( ``N`` )，就会创
-建名为``0`` 到 ``N-1`` 的子目录数量。每个目录代表每个监测背景。目前，每个kdamond只支持
+建名为``0`` 到 ``N-1`` 的子目录数量。每个目录代表每个监测上下文（更多细节请参考
+:ref:`设计 <damon_design_execution_model_and_data_structures_zh_CN>`）。目前，每个kdamond只支持
 一个上下文，所以只有 ``0`` 或 ``1`` 可以被写入文件。
 
+.. _sysfs_context_zh_CN:
+
 contexts/<N>/
 -------------
 
-在每个上下文目录中，存在一个文件(``operations``)和三个目录(``monitoring_attrs``,
+在每个上下文目录中，存在四个文件(``avail_operations``、``operations``、
+``addr_unit`` 和 ``pause``)和三个目录(``monitoring_attrs``,
 ``targets``, 和 ``schemes``)。
 
-DAMON支持多种类型的监测操作，包括对虚拟地址空间和物理地址空间的监测。你可以通过向文件
-中写入以下关键词之一，并从文件中读取，来设置和获取DAMON将为上下文使用何种类型的监测操作。
+DAMON支持多种 :ref:`监测操作 <damon_design_configurable_operations_set_zh_CN>` 类型，
+包括对虚拟地址空间和物理地址空间的监测。你可以通过读取 ``avail_operations`` 文件，
+获取当前运行内核上可用的监测操作集列表。根据内核配置，该文件会列出不同的可用
+操作集。所有可用操作集及其简要说明请参考 :ref:`设计 <damon_operations_set_zh_CN>`。
+
+你可以通过向 ``operations`` 文件写入 ``avail_operations`` 文件中列出的一个关键词，
+并从 ``operations`` 文件中读取，来设置和获取DAMON将为上下文使用何种类型的监测操作。
+
+``addr_unit`` 文件用于设置和获取该操作集的 :ref:`地址单位 <damon_design_addr_unit_zh_CN>` 参数。
+
+``pause`` 文件用于设置和获取该上下文的 :ref:`暂停请求 <damon_design_execution_model_and_data_structures_zh_CN>` 参数。
 
- - vaddr: 监测特定进程的虚拟地址空间
- - paddr: 监视系统的物理地址空间
+.. _sysfs_monitoring_attrs_zh_CN:
 
 contexts/<N>/monitoring_attrs/
 ------------------------------
 
 用于指定监测属性的文件，包括所需的监测质量和效率，都在 ``monitoring_attrs`` 目录中。
-具体来说，这个目录下有两个目录，即 ``intervals`` 和 ``nr_regions`` 。
+具体来说，这个目录下有三个目录，即 ``intervals``、``nr_regions`` 和 ``probes``。
 
 在 ``intervals`` 目录下，存在DAMON的采样间隔(``sample_us``)、聚集间隔(``aggr_us``)
 和更新间隔(``update_us``)三个文件。你可以通过写入和读出这些文件来设置和获取微秒级的值。
@@ -150,7 +219,44 @@ contexts/<N>/monitoring_attrs/
 在 ``nr_regions`` 目录下，有两个文件分别用于DAMON监测区域的下限和上限（``min`` 和 ``max`` ），
 这两个文件控制着监测的开销。你可以通过向这些文件的写入和读出来设置和获取这些值。
 
-关于间隔和监测区域范围的更多细节，请参考设计文件 (:doc:`/mm/damon/design`)。
+关于间隔和监测区域范围的更多细节，请参考设计文件 (:ref:`设计 <damon_design_monitoring_zh_CN>`)。
+
+.. _damon_usage_sysfs_monitoring_intervals_goal_zh_CN:
+
+contexts/<N>/monitoring_attrs/intervals/intervals_goal/
+-------------------------------------------------------
+
+在 ``intervals`` 目录下，还存在一个用于自动调优 ``sample_us`` 和
+``aggr_us`` 的目录，即 ``intervals_goal`` 目录。在该目录下，存在四个
+用于自动调优控制的文件，即 ``access_bp``、``aggrs``、``min_sample_us``
+和 ``max_sample_us``。关于调优机制的内部实现，请参考该功能的
+:ref:`设计文档 <damon_design_monitoring_intervals_autotuning_zh_CN>`。读取和写入
+``intervals_goal`` 目录下的四个文件，会显示并更新 :ref:`设计文档 <damon_design_monitoring_intervals_autotuning_zh_CN>` 中描述的同名调优参数。调优
+从用户设置的 ``sample_us`` 和 ``aggr_us`` 开始。向 ``state`` 文件写入
+``update_tuned_intervals`` 后，可以从 ``sample_us`` 和 ``aggr_us`` 文件
+读取应用调优后的两个间隔的当前值。
+
+.. _damon_usage_sysfs_probes_zh_CN:
+
+contexts/<N>/monitoring_attrs/probes/
+-------------------------------------
+
+用于注册 :ref:`数据属性监测 <damon_design_data_attrs_monitoring_zh_CN>` 探针的目录。
+
+开始时，该目录只有一个文件 ``nr_probes``。向该文件写入一个数字
+（``N``）会创建数量为该数字的子目录，命名为 ``0`` 到 ``N-1``。每个
+目录表示一个监测探针。
+
+在每个探针目录中，存在一个目录 ``filters``。该目录包含为探针安装过滤器
+的文件，该过滤器用于确定探针的数据属性。
+
+开始时，``filters`` 目录只有一个文件 ``nr_filters``。向该文件写入一个
+数字（``N``）会创建数量为该数字的子目录，命名为 ``0`` 到 ``N-1``。每个
+目录表示一个过滤器，其工作方式类似于 :ref:`DAMOS 过滤器
+<sysfs_filters_zh_CN>`。当过滤器 ``type`` 为 ``memcg`` 时，``path`` 文件
+作为 :ref:`DAMOS 过滤器 <sysfs_filters_zh_CN>` 的 ``memcg_path`` 使用。
+
+.. _sysfs_targets_zh_CN:
 
 contexts/<N>/targets/
 ---------------------
@@ -158,30 +264,43 @@ contexts/<N>/targets/
 在开始时，这个目录只有一个文件 ``nr_targets`` 。向该文件写入一个数字(``N``)，就可以创建
 名为 ``0`` 到 ``N-1`` 的子目录的数量。每个目录代表每个监测目标。
 
+.. _sysfs_target_zh_CN:
+
 targets/<N>/
 ------------
 
-在每个目标目录中，存在一个文件(``pid_target``)和一个目录(``regions``)。
+在每个目标目录中，存在两个文件（``pid_target`` 和 ``obsolete_target``）和一个目录(``regions``)。
 
 如果你把 ``vaddr`` 写到 ``contexts/<N>/operations`` 中，每个目标应该是一个进程。你
 可以通过将进程的pid写到 ``pid_target`` 文件中来指定DAMON的进程。
 
+用户可以通过向 ``obsolete_target`` 文件写入非零值并提交它（向 ``state``
+文件写入 ``commit``），有选择地移除目标数组中间的目标。DAMON 会从内部
+目标数组中移除匹配的目标。用户负责重新构建目标目录，使其正确表示变更后的
+内部目标数组。
+
+
+.. _sysfs_regions_zh_CN:
+
 targets/<N>/regions
 -------------------
 
-当使用 ``vaddr`` 监测操作集时（ ``vaddr`` 被写入 ``contexts/<N>/operations`` 文
-件），DAMON自动设置和更新监测目标区域，这样就可以覆盖目标进程的整个内存映射。然而，用户可
-能希望将初始监测区域设置为特定的地址范围。
+在使用 ``fvaddr`` 或 ``paddr`` 监测操作集时，用户需要设置监测目标地址
+范围。在使用 ``vaddr`` 操作集时，这不是必须的，但用户可以选择将初始
+监测区域设置为特定地址范围。更多细节请参考 :ref:`设计 <damon_design_vaddr_target_regions_construction_zh_CN>`。
 
-相反，当使用 ``paddr`` 监测操作集时，DAMON不会自动设置和更新监测目标区域（ ``paddr``
-被写入 ``contexts/<N>/operations`` 中）。因此，在这种情况下，用户应该自己设置监测目标
-区域。
-
-在这种情况下，用户可以按照自己的意愿明确设置初始监测目标区域，将适当的值写入该目录下的文件。
+对于这类情况，用户可以按照自己的需要，向该目录下的文件写入适当的值，
+显式设置初始监测目标区域。
 
 开始时，这个目录只有一个文件， ``nr_regions`` 。向该文件写入一个数字(``N``)，就可以创
 建名为 ``0`` 到  ``N-1`` 的子目录。每个目录代表每个初始监测目标区域。
 
+如果在线提交新的 DAMON 参数时（向 :ref:`kdamond <sysfs_kdamond_zh_CN>` 的
+``state`` 文件写入 ``commit``）``nr_regions`` 为零，则提交逻辑会忽略
+目标区域。换言之，该目标当前的监测结果会被保留。
+
+.. _sysfs_region_zh_CN:
+
 regions/<N>/
 ------------
 
@@ -190,6 +309,8 @@ regions/<N>/
 
 每个区域不应该与其他区域重叠。 目录“N”的“结束”应等于或小于目录“N+1”的“开始”。
 
+.. _sysfs_schemes_zh_CN:
+
 contexts/<N>/schemes/
 ---------------------
 
@@ -200,99 +321,249 @@ contexts/<N>/schemes/
 在开始时，这个目录只有一个文件，``nr_schemes``。向该文件写入一个数字(``N``)，就可以
 创建名为``0``到``N-1``的子目录的数量。每个目录代表每个基于DAMON的操作方案。
 
+.. _sysfs_scheme_zh_CN:
+
 schemes/<N>/
 ------------
 
-在每个方案目录中，存在五个目录(``access_pattern``、``quotas``、``watermarks``、
-``stats`` 和 ``tried_regions``)和一个文件(``action``)。
+在每个方案目录中，存在九个目录（``access_pattern``、``quotas``、
+``watermarks``、``core_filters``、``ops_filters``、``filters``、
+``dests``、``stats`` 和 ``tried_regions``）以及三个文件（``action``、
+``target_nid`` 和 ``apply_interval_us``）。
 
-``action`` 文件用于设置和获取你想应用于具有特定访问模式的内存区域的动作。可以写入文件
-和从文件中读取的关键词及其含义如下。
+``action`` 文件用于设置和获取方案的 :ref:`动作 <damon_design_damos_action_zh_CN>`。可写入和读取该文件的关键字及其含义，与
+:ref:`设计文档 <damon_design_damos_action_zh_CN>` 中列表的内容相同。
 
- - ``willneed``: 对有 ``MADV_WILLNEED`` 的区域调用 ``madvise()`` 。
- - ``cold``: 对具有 ``MADV_COLD`` 的区域调用 ``madvise()`` 。
- - ``pageout``: 为具有 ``MADV_PAGEOUT`` 的区域调用 ``madvise()`` 。
- - ``hugepage``: 为带有 ``MADV_HUGEPAGE`` 的区域调用 ``madvise()`` 。
- - ``nohugepage``: 为带有 ``MADV_NOHUGEPAGE`` 的区域调用 ``madvise()``。
- - ``lru_prio``: 在其LRU列表上对区域进行优先排序。
- - ``lru_deprio``: 对区域的LRU列表进行降低优先处理。
- - ``stat``: 什么都不做，只计算统计数据
+``target_nid`` 文件用于设置迁移目标节点，只有当 ``action`` 为
+``migrate_hot`` 或 ``migrate_cold`` 时才有意义。
+
+``apply_interval_us`` 文件用于以微秒为单位设置和获取方案的
+:ref:`apply_interval <damon_design_damos_zh_CN>`。
+
+.. _sysfs_access_pattern_zh_CN:
 
 schemes/<N>/access_pattern/
 ---------------------------
 
-每个基于DAMON的操作方案的目标访问模式由三个范围构成，包括以字节为单位的区域大小、每个
-聚合区间的监测访问次数和区域年龄的聚合区间数。
+用于给定基于 DAMON 的操作方案的目标访问 :ref:`模式
+<damon_design_damos_access_pattern_zh_CN>` 的目录。
 
 在 ``access_pattern`` 目录下，存在三个目录（ ``sz``, ``nr_accesses``, 和 ``age`` ），
 每个目录有两个文件（``min`` 和 ``max`` ）。你可以通过向  ``sz``, ``nr_accesses``, 和
 ``age``  目录下的 ``min`` 和 ``max`` 文件分别写入和读取来设置和获取给定方案的访问模式。
+请注意，``min`` 和 ``max`` 形成闭区间。
+
+.. _sysfs_quotas_zh_CN:
 
 schemes/<N>/quotas/
 -------------------
 
-每个 ``动作`` 的最佳 ``目标访问模式`` 取决于工作负载，所以不容易找到。更糟糕的是，将某些动作
-的方案设置得过于激进会造成严重的开销。为了避免这种开销，用户可以为每个方案限制时间和大小配额。
-具体来说，用户可以要求DAMON尽量只使用特定的时间（``时间配额``）来应用动作，并且在给定的时间间
-隔（``重置间隔``）内，只对具有目标访问模式的内存区域应用动作，而不使用特定数量（``大小配额``）。
+用于给定基于 DAMON 的操作方案的 :ref:`配额 <damon_design_damos_quotas_zh_CN>` 的目录。
+
+在 ``quotas`` 目录下，存在七个文件（``ms``、``bytes``、
+``reset_interval_ms``、``effective_bytes``、``goal_tuner``、
+``fail_charge_num`` 和 ``fail_charge_denom``）以及两个目录（``weights``
+和 ``goals``）。
 
-当预计超过配额限制时，DAMON会根据 ``目标访问模式`` 的大小、访问频率和年龄，对找到的内存区域
-进行优先排序。为了进行个性化的优先排序，用户可以为这三个属性设置权重。
+你可以分别向这三个文件写入值，设置以毫秒为单位的 ``time quota``、以字节
+为单位的 ``size quota`` 以及以毫秒为单位的 ``reset interval``。随后，
+DAMON 会尝试在 ``reset_interval_ms`` 内，只使用最多 ``time quota``
+毫秒把 ``action`` 应用于符合 ``access_pattern`` 的内存区域，并且只将该
+动作应用于最多 ``bytes`` 字节的内存区域。将 ``ms`` 和 ``bytes`` 都设置
+为零会禁用配额限制，除非至少设置了一个 :ref:`目标
+<sysfs_schemes_quota_goals_zh_CN>`。
 
-在 ``quotas`` 目录下，存在三个文件（``ms``, ``bytes``, ``reset_interval_ms``）和一个
-目录(``weights``)，其中有三个文件(``sz_permil``, ``nr_accesses_permil``, 和
-``age_permil``)。
+你可以向 ``goal_tuner`` 文件写入算法名称，设置要使用的基于目标的有效
+配额自动调优算法。读取该文件会返回当前选择的调优算法。关于该功能的背景
+设计以及可选择算法的名称，请参考 :ref:`自动配额调优目标 <damon_design_damos_quotas_auto_tuning_zh_CN>` 的设计文档。关于目标设置，请参考
+:ref:`goals 目录 <sysfs_schemes_quota_goals_zh_CN>`。
 
-你可以设置以毫秒为单位的 ``时间配额`` ，以字节为单位的 ``大小配额`` ，以及以毫秒为单位的 ``重
-置间隔`` ，分别向这三个文件写入数值。你还可以通过向 ``weights`` 目录下的三个文件写入数值来设
-置大小、访问频率和年龄的优先权，单位为千分之一。
+你可以分别向 ``fail_charge_num`` 和 ``fail_charge_denom`` 文件写入该比率的
+分子和分母，设置动作失败内存配额计费比率。读取这些文件会返回当前设置的值。
+关于该比率功能的更多细节，请参考 :ref:`设计 <damon_design_damos_quotas_failed_memory_charging_ratio_zh_CN>`。
+
+时间配额会在内部转换为大小配额。在转换后的大小配额和用户指定的大小配额之间，
+会应用较小者。根据用户指定的 :ref:`目标
+<sysfs_schemes_quota_goals_zh_CN>`，有效大小配额会被进一步调整。读取
+``effective_bytes`` 会返回当前有效大小配额。该文件不会实时更新，所以用户
+应通过向相关 ``kdamonds/<N>/state`` 文件写入特殊关键字
+``update_schemes_effective_quotas``，要求 DAMON sysfs 接口为统计信息更新该
+文件内容。
+
+在 ``weights`` 目录下，存在三个文件（``sz_permil``、
+``nr_accesses_permil`` 和 ``age_permil``）。你可以向 ``weights`` 目录下的
+三个文件写入值，设置大小、访问频率和年龄的 :ref:`优先级权重 <damon_design_damos_quotas_prioritization_zh_CN>`，单位为千分之一。
+
+.. _sysfs_schemes_quota_goals_zh_CN:
+
+schemes/<N>/quotas/goals/
+-------------------------
+
+用于给定基于 DAMON 的操作方案的 :ref:`自动配额调优目标 <damon_design_damos_quotas_auto_tuning_zh_CN>` 的目录。
+
+开始时，该目录只有一个文件 ``nr_goals``。向该文件写入一个数字（``N``）
+会创建数量为该数字的子目录，命名为 ``0`` 到 ``N-1``。每个目录表示一个
+目标和当前达成情况。在多个反馈中，会使用最好的一个。
+
+每个目标目录包含五个文件，即 ``target_metric``、``target_value``、
+``current_value``、``nid`` 和 ``path``。用户可以通过写入和读取每个文件，
+设置和获取 :ref:`设计文档 <damon_design_damos_quotas_auto_tuning_zh_CN>` 中指定的
+配额自动调优目标的五个参数。因为内核不会更新 ``current_value``，所以只有
+当 ``target_metric`` 为 ``user_input`` 时，读取它才有意义。请注意，用户还应
+向 :ref:`kdamond 目录 <sysfs_kdamond_zh_CN>` 的 ``state`` 文件写入
+``commit_schemes_quota_goals``，以便将反馈传递给 DAMON。
+
+.. _sysfs_watermarks_zh_CN:
 
 schemes/<N>/watermarks/
 -----------------------
 
-为了便于根据系统状态激活和停用每个方案，DAMON提供了一个称为水位的功能。该功能接收五个值，称为
-``度量`` 、``间隔`` 、``高`` 、``中`` 、``低`` 。``度量值`` 是指可以测量的系统度量值，如
-自由内存比率。如果系统的度量值 ``高`` 于memoent的高值或 ``低`` 于低值，则该方案被停用。如果
-该值低于 ``中`` ，则该方案被激活。
+用于给定基于 DAMON 的操作方案的 :ref:`水位 <damon_design_damos_watermarks_zh_CN>` 的目录。
+
+在 watermarks 目录下，存在五个文件（``metric``、``interval_us``、``high``、
+``mid`` 和 ``low``），用于设置度量指标、度量指标检查之间的时间间隔以及三个
+水位。你可以分别通过写入和读取这些文件来设置和获取这五个值。
+
+可写入 ``metric`` 文件的关键字及其含义如下。
+
+ - none：忽略水位
+ - free_mem_rate：系统空闲内存率（千分之一）
+
+``interval_us`` 应以微秒为单位写入。
+
+.. _sysfs_filters_zh_CN:
+
+schemes/<N>/{core\_,ops\_,}filters/
+-----------------------------------
+
+用于给定基于 DAMON 的操作方案的 :ref:`过滤器 <damon_design_damos_filters_zh_CN>` 的目录。
+
+``core_filters`` 和 ``ops_filters`` 目录分别用于由 DAMON 核心层和操作集层
+处理的过滤器。``filters`` 目录可用于安装过滤器，而不管它们由哪一层处理。
+``core_filters`` 和 ``ops_filters`` 请求的过滤器会先于 ``filters`` 中的
+过滤器安装。这三个目录具有相同的文件。
+
+使用 ``filters`` 目录会使过滤器求值顺序难以预期。因此，``filters`` 目录
+已被弃用。它仍然可以工作，但计划在不久的将来移除。用户应改用
+``core_filters`` 和 ``ops_filters`` 目录。
+
+开始时，该目录只有一个文件 ``nr_filters``。向该文件写入一个数字（``N``）
+会创建数量为该数字的子目录，命名为 ``0`` 到 ``N-1``。每个目录表示一个
+过滤器。过滤器按数字顺序求值。
+
+每个过滤器目录包含九个文件，即 ``type``、``matching``、``allow``、
+``memcg_path``、``addr_start``、``addr_end``、``min``、``max`` 和
+``damon_target_idx``。你可以向 ``type`` 文件写入过滤器类型。关于可用
+类型名称、它们的含义以及它们由哪一层处理，请参考 :ref:`设计文档 <damon_design_damos_filters_zh_CN>`。
 
-在水位目录下，存在五个文件(``metric``, ``interval_us``,``high``, ``mid``, and ``low``)
-用于设置每个值。你可以通过向这些文件的写入来分别设置和获取这五个值。
+对于 ``memcg`` 类型，你可以向 ``memcg_path`` 文件写入从 cgroups 挂载点
+开始的内存 cgroup 路径，指定感兴趣的内存 cgroup。对于 ``addr`` 类型，
+你可以分别向 ``addr_start`` 和 ``addr_end`` 文件写入范围（左闭右开区间）
+的起始和结束地址。对于 ``hugepage_size`` 类型，你可以分别向 ``min`` 和
+``max`` 文件写入范围（闭区间）的最小和最大大小。对于 ``target`` 类型，
+你可以向 ``damon_target_idx`` 文件写入 DAMON 上下文的监测目标列表中目标的
+索引。
 
-可以写入 ``metric`` 文件的关键词和含义如下。
+你可以向 ``matching`` 文件写入 ``Y`` 或 ``N``，指定过滤器是否用于匹配
+``type`` 的内存。你可以向 ``allow`` 文件写入 ``Y`` 或 ``N``，指定是否允许
+将动作应用于满足 ``type`` 和 ``matching`` 的内存。
 
- - none: 忽略水位
- - free_mem_rate: 系统的自由内存率（千分比）。
+例如，下面的操作将 DAMOS 动作限制为只应用于除 ``/having_care_already`` 之外
+所有内存 cgroup 的非匿名页。::
 
-``interval`` 应以微秒为单位写入。
+    # cd ops_filters/0/
+    # echo 2 > nr_filters
+    # # disallow anonymous pages
+    echo anon > 0/type
+    echo Y > 0/matching
+    echo N > 0/allow
+    # # further filter out all cgroups except one at '/having_care_already'
+    echo memcg > 1/type
+    echo /having_care_already > 1/memcg_path
+    echo Y > 1/matching
+    echo N > 1/allow
+
+更多细节请参考 :ref:`DAMOS 过滤器设计文档 <damon_design_damos_filters_zh_CN>`，
+其中包括不同 ``allow`` 的多个过滤器如何工作、每个过滤器何时受支持，以及
+统计信息上的差异。
+
+.. _damon_sysfs_dests_zh_CN:
+
+schemes/<N>/dests/
+------------------
+
+用于指定给定基于 DAMON 的操作方案动作的目的地的目录。如果给定方案的动作
+不支持多个目的地，则该目录会被忽略。只有 ``DAMOS_MIGRATE_{HOT,COLD}`` 动作
+支持多个目的地。
+
+开始时，该目录只有一个文件 ``nr_dests``。向该文件写入一个数字（``N``）
+会创建数量为该数字的子目录，命名为 ``0`` 到 ``N-1``。每个目录表示一个
+动作目的地。
+
+每个目的地目录包含两个文件，即 ``id`` 和 ``weight``。用户可以向 ``id``
+文件写入目的地标识符，并从中读取它。对于 ``DAMOS_MIGRATE_{HOT,COLD}`` 动作，
+应将迁移目的节点的节点 id 写入 ``id`` 文件。用户可以向 ``weight`` 文件写入
+该目的地在给定目的地中的权重，并从中读取它。权重可以是任意整数。当 DAMOS
+将动作应用于内存区域的每个实体时，它会根据目的地的相对权重选择该动作的
+目的地。
+
+.. _sysfs_schemes_stats_zh_CN:
 
 schemes/<N>/stats/
 ------------------
 
-DAMON统计每个方案被尝试应用的区域的总数量和字节数，每个方案被成功应用的区域的两个数字，以及
-超过配额限制的总数量。这些统计数据可用于在线分析或调整方案。
+DAMON 为每个方案统计信息。这些统计信息可用于方案的在线分析或调优。关于
+这些统计信息的更多细节，请参考 :ref:`设计文档 <damon_design_damos_stat_zh_CN>`。
+
+可以分别通过读取 ``stats`` 目录下的文件（``nr_tried``、``sz_tried``、
+``nr_applied``、``sz_applied``、``sz_ops_filter_passed``、``qt_exceeds``、
+``nr_snapshots`` 和 ``max_nr_snapshots``）来获取这些统计信息。
 
-可以通过读取 ``stats`` 目录下的文件(``nr_tried``, ``sz_tried``, ``nr_applied``,
-``sz_applied``, 和 ``qt_exceeds``)）分别检索这些统计数据。这些文件不是实时更新的，所以
-你应该要求DAMON sysfs接口通过在相关的 ``kdamonds/<N>/state`` 文件中写入一个特殊的关键字
-``update_schemes_stats`` 来更新统计信息的文件内容。
+默认情况下，这些文件不会实时更新。用户应要求 DAMON sysfs 接口使用
+``refresh_ms`` 周期性地更新这些文件，或者向相关 ``kdamonds/<N>/state`` 文件
+写入特殊关键字 ``update_schemes_stats`` 来进行一次性更新。更多细节请参考
+:ref:`kdamond 目录 <sysfs_kdamond_zh_CN>`。
+
+.. _sysfs_schemes_tried_regions_zh_CN:
 
 schemes/<N>/tried_regions/
 --------------------------
 
-当一个特殊的关键字 ``update_schemes_tried_regions`` 被写入相关的 ``kdamonds/<N>/state``
-文件时，DAMON会在这个目录下创建从 ``0`` 开始命名的整数目录。每个目录包含的文件暴露了关于每个
-内存区域的详细信息，在下一个 :ref:`聚集区间 <sysfs_monitoring_attrs>`，相应的方案的 ``动作``
-已经尝试在这个目录下应用。这些信息包括地址范围、``nr_accesses`` 以及区域的 ``年龄`` 。
+该目录初始时有一个文件 ``total_bytes``。
+
+当特殊关键字 ``update_schemes_tried_regions`` 被写入相关
+``kdamonds/<N>/state`` 文件时，DAMON 会更新 ``total_bytes`` 文件，使读取
+它时返回该方案尝试区域的总大小，并在该目录下创建从 ``0`` 开始以整数命名的
+目录。每个目录包含一些文件，暴露该目录下对应方案的 ``action`` 在对应方案的
+下一个 :ref:`应用间隔 <damon_design_damos_zh_CN>` 内尝试应用的每个内存区域的详细
+信息。这些信息包括该区域的地址范围、``nr_accesses`` 和 ``age``。
+
+向相关 ``kdamonds/<N>/state`` 文件写入 ``update_schemes_tried_bytes`` 只会
+更新 ``total_bytes`` 文件，而不会创建子目录。
+
+当另一个特殊关键字 ``clear_schemes_tried_regions`` 被写入相关
+``kdamonds/<N>/state`` 文件时，这些目录会被删除。
+
+该目录的预期用途是调查方案行为，以及类似查询的高效数据访问监测结果获取。
+特别是对于后一种用例，用户可以将 ``action`` 设置为 ``stat``，并将
+``access pattern`` 设置为他们感兴趣、想要查询的模式。
 
-当另一个特殊的关键字 ``clear_schemes_tried_regions`` 被写入相关的 ``kdamonds/<N>/state``
-文件时，这些目录将被删除。
+.. _sysfs_schemes_tried_region_zh_CN:
 
 tried_regions/<N>/
 ------------------
 
-在每个区域目录中，你会发现四个文件(``start``, ``end``, ``nr_accesses``, and ``age``)。
-读取这些文件将显示相应的基于DAMON的操作方案 ``动作`` 试图应用的区域的开始和结束地址、``nr_accesses``
-和 ``年龄`` 。
+在每个区域目录中，你会发现五个文件（``start``、``end``、``nr_accesses``、
+``age`` 和 ``sz_filter_passed``）。读取这些文件将显示相应的基于DAMON的操作方案
+``action`` 试图应用的区域属性。
+
+tried_regions/<N>/probes/
+-------------------------
+
+在每个区域目录中，还存在一个目录（``probes``）。在该目录中，存在命名为
+``0`` 到 ``N-1`` 的子目录。``N`` 是已安装探针的数量。在每个数字命名的
+目录中，存在一个文件（``hits``）。读取该文件会显示该区域的数据属性监测
+探针命中正样本的数量。
 
 用例
 ~~~~
@@ -330,16 +601,46 @@ tried_regions/<N>/
 请注意，我们强烈建议使用用户空间的工具，如 `damo <https://github.com/damonitor/damo>`_ ，
 而不是像上面那样手动读写文件。以上只是一个例子。
 
+.. _tracepoint_zh_CN:
 
-监测结果的监测点
+监测结果的跟踪点
 ================
 
-DAMON通过一个tracepoint ``damon:damon_aggregated`` 提供监测结果.  当监测开启时，你可
-以记录追踪点事件，并使用追踪点支持工具如perf显示结果。比如说::
+用户可以通过 :ref:`tried_regions <sysfs_schemes_tried_regions_zh_CN>` 获取
+监测结果。该接口适合获取快照，但用于完整记录所有监测结果时可能效率不高。
+为此，提供了两个跟踪点，即 ``damon:damon_aggregated`` 和
+``damon:damos_before_apply``。``damon:damon_aggregated`` 提供完整的监测
+结果，而 ``damon:damos_before_apply`` 提供每个基于 DAMON 的操作方案
+（:ref:`DAMOS <damon_design_damos_zh_CN>`）将要应用到的区域的监测结果。因此，
+``damon:damos_before_apply`` 更适合记录 DAMOS 的内部行为，或者基于 DAMOS
+目标访问 :ref:`模式 <damon_design_damos_access_pattern_zh_CN>` 的类似查询的高效
+监测结果记录。
 
-    # echo on > monitor_on_DEPRECATED
+监测开启时，你可以记录跟踪点事件，并使用跟踪点支持工具如 ``perf`` 显示结果。比如说::
+
+    # echo on > kdamonds/0/state
     # perf record -e damon:damon_aggregated &
     # sleep 5
     # kill 9 $(pidof perf)
-    # echo off > monitor_on_DEPRECATED
+    # echo off > kdamonds/0/state
     # perf script
+    kdamond.0 46568 [027] 79357.842179: damon:damon_aggregated: target_id=0 nr_regions=11 122509119488-135708762112: 0 864
+    [...]
+
+``perf script`` 输出的每一行表示一个监测区域。前五个字段与其他跟踪点输出
+一样。第六个字段 ``target_id=X`` 显示该区域的监测目标 id。第七个字段
+``nr_regions=X`` 显示该目标的监测区域总数。第八个字段 ``X-Y:`` 显示
+该区域的起始地址 ``X`` 和结束地址 ``Y``，单位为字节。第九个字段 ``X``
+显示该区域的 ``nr_accesses`` （关于该计数器的更多细节请参考 :ref:`设计 <damon_design_region_based_sampling_zh_CN>`）。最后，第十个字段 ``X`` 显示该区域
+的 ``age`` （关于该计数器的更多细节请参考 :ref:`设计 <damon_design_age_tracking_zh_CN>`）。
+
+如果事件是 ``damon:damos_before_apply``，``perf script`` 输出大致如下::
+
+    kdamond.0 47293 [000] 80801.060214: damon:damos_before_apply: ctx_idx=0 scheme_idx=0 target_idx=0 nr_regions=11 121932607488-135128711168: 0 136
+    [...]
+
+输出的每一行表示在被跟踪的时间点，每个基于 DAMON 的操作方案即将应用到的
+一个监测区域。前五个字段与通常一样。除了 ``damon_aggregated`` 跟踪点的
+输出之外，它还显示方案所属 DAMON 上下文在该上下文的 kdamond 的上下文列表
+中的索引（``ctx_idx=X``），以及该方案在该上下文的方案列表中的索引
+（``scheme_idx=X``）。
diff --git a/Documentation/translations/zh_CN/mm/damon/design.rst b/Documentation/translations/zh_CN/mm/damon/design.rst
index 16e3db34a7dd..b7790bcea9b9 100644
--- a/Documentation/translations/zh_CN/mm/damon/design.rst
+++ b/Documentation/translations/zh_CN/mm/damon/design.rst
@@ -13,35 +13,83 @@
 设计
 ====
 
-可配置的层
-==========
 
-DAMON提供了数据访问监控功能，同时使其准确性和开销可控。基本的访问监控需要依赖于目标地址空间
-并为之优化的基元。另一方面，作为DAMON的核心，准确性和开销的权衡机制是在纯逻辑空间中。DAMON
-将这两部分分离在不同的层中，并定义了它的接口，以允许各种低层次的基元实现与核心逻辑的配置。
+.. _damon_design_execution_model_and_data_structures_zh_CN:
 
-由于这种分离的设计和可配置的接口，用户可以通过配置核心逻辑和适当的低级基元实现来扩展DAMON的
-任何地址空间。如果没有提供合适的，用户可以自己实现基元。
+执行模型和数据结构
+==================
 
-例如，物理内存、虚拟内存、交换空间、那些特定的进程、NUMA节点、文件和支持的内存设备将被支持。
-另外，如果某些架构或设备支持特殊的优化访问检查基元，这些基元将很容易被配置。
+与监测相关的信息，包括监测请求规格和基于 DAMON 的操作方案，都存储在名为
+DAMON ``context`` 的数据结构中。DAMON 使用名为 ``kdamond`` 的内核线程执行
+每个上下文。多个 kdamond 可以并行运行，用于不同类型的监测。
 
+要了解用户空间如何进行配置并启动或停止 DAMON，请参考 :ref:`DAMON sysfs
+接口 <sysfs_interface_zh_CN>` 文档。
 
-特定地址空间基元的参考实现
-==========================
+用户还可以请求暂停和恢复每个上下文的执行。当上下文被暂停时，kdamond 除了应用
+在线参数更新外不做任何事情。
 
-基本访问监测的低级基元被定义为两部分。:
+要了解用户空间如何暂停或恢复每个上下文，请参考 :ref:`DAMON sysfs 上下文
+<sysfs_context_zh_CN>` 使用文档。
 
-1. 确定地址空间的监测目标地址范围
-2. 目标空间中特定地址范围的访问检查。
+总体架构
+========
 
-DAMON目前为物理和虚拟地址空间提供了基元的实现。下面两个小节描述了这些工作的方式。
+DAMON 子系统由三层构成，包括
 
+- :ref:`操作集 <damon_operations_set_zh_CN>`：实现依赖于给定监测目标地址空间
+  和可用软硬件基元集合的 DAMON 基本操作，
+- :ref:`核心 <damon_core_logic_zh_CN>`：在操作集层之上，实现包括监测开销/准确性
+  控制和访问感知系统操作在内的核心逻辑，以及
+- :ref:`模块 <damon_modules_zh_CN>`：在核心层之上，实现用于各种目的、并向用户空间
+  提供接口的内核模块。
+
+
+.. _damon_operations_set_zh_CN:
+
+操作集层
+========
+
+.. _damon_design_configurable_operations_set_zh_CN:
+
+为了进行数据访问监测和其他低层工作，DAMON 需要一组针对给定目标地址空间、
+并依赖于和优化于该地址空间的特定操作实现。例如，下面两个用于访问监测的操作
+依赖于地址空间。
+
+1. 确定该地址空间的监测目标地址范围。
+2. 检查目标空间中特定地址范围的访问。
+
+DAMON 将这些实现整合到称为 DAMON 操作集的层中，并定义它和上层之间的接口。
+上层专用于 DAMON 的核心逻辑，包括控制监测准确性和开销的机制。
+
+因此，DAMON 可以通过配置核心逻辑使用适当的操作集，轻松扩展到任意地址空间
+和/或可用硬件功能。如果给定目的没有可用操作集，也可以按照层间接口实现新的
+操作集。
+
+例如，物理内存、虚拟内存、交换空间、特定进程、NUMA 节点、文件和后端内存设备
+都可以被支持。另外，如果某些架构或设备支持特殊的优化访问检查功能，也可以很容易
+进行配置。
+
+DAMON 当前提供以下三个操作集。下面三个小节描述它们如何工作。
+
+ - vaddr：监测特定进程的虚拟地址空间
+ - fvaddr：监测固定虚拟地址范围
+ - paddr：监测系统的物理地址空间
+
+要了解用户空间如何通过 :ref:`DAMON sysfs 接口 <sysfs_interface_zh_CN>` 进行配置，
+请参考文档的 :ref:`operations <sysfs_context_zh_CN>` 文件部分。
+
+
+.. _damon_design_vaddr_target_regions_construction_zh_CN:
 
 基于VMA的目标地址范围构造
 -------------------------
 
-这仅仅是针对虚拟地址空间基元的实现。对于物理地址空间，只是要求用户手动设置监控目标地址范围。
+``vaddr`` DAMON 操作集的一种机制，会自动初始化并更新监测目标地址区域，
+以覆盖目标进程的整个内存映射。
+
+该机制仅用于 ``vaddr`` 操作集。对于 ``fvaddr`` 和 ``paddr`` 操作集，
+用户需要手动设置监测目标地址范围。
 
 在进程的超级巨大的虚拟地址空间中，只有小部分被映射到物理内存并被访问。因此，跟踪未映射的地
 址区域只是一种浪费。然而，由于DAMON可以使用自适应区域调整机制来处理一定程度的噪声，所以严
@@ -50,7 +98,7 @@ DAMON目前为物理和虚拟地址空间提供了基元的实现。下面两个
 
 出于这个原因，这个实现将复杂的映射转换为三个不同的区域，覆盖地址空间的每个映射区域。这三个
 区域之间的两个空隙是给定地址空间中两个最大的未映射区域。这两个最大的未映射区域是堆和最上面
-的mmap()区域之间的间隙，以及在大多数情况下最下面的mmap()区域和堆之间的间隙。因为这些间隙
+的mmap()区域之间的间隙，以及在大多数情况下最下面的mmap()区域和栈之间的间隙。因为这些间隙
 在通常的地址空间中是异常巨大的，排除这些间隙就足以做出合理的权衡。下面详细说明了这一点::
 
     <heap>
@@ -69,23 +117,52 @@ DAMON目前为物理和虚拟地址空间提供了基元的实现。下面两个
 找到相关的PTE访问位的方式。虚拟地址的实现是为该地址的目标任务查找页表，而物理地址的实现则
 是查找与该地址有映射关系的每一个页表。通过这种方式，实现者找到并清除下一个采样目标地址的位，
 并检查该位是否在一个采样周期后再次设置。这可能会干扰其他使用访问位的内核子系统，即空闲页跟
-踪和回收逻辑。为了避免这种干扰，DAMON使其与空闲页面跟踪相互排斥，并使用 ``PG_idle`` 和
-``PG_young`` 页面标志来解决与回收逻辑的冲突，就像空闲页面跟踪那样。
+踪和回收逻辑。DAMON 不做任何事情来避免干扰空闲页跟踪，因此处理这种干扰是系统管理员的责任。
+不过，它会像空闲页跟踪一样，使用 ``PG_idle`` 和 ``PG_young`` 页面标志解决与回收逻辑的冲突。
+
+
+.. _damon_design_addr_unit_zh_CN:
+
+地址单位
+--------
 
+DAMON 核心层使用 ``unsigned long`` 类型表示监测目标地址范围。在某些情况下，
+给定操作集的地址空间可能过大，无法用该类型处理。带有大物理地址扩展的
+ARM（32 位）就是一个例子。对于这类情况，提供了一个称为 ``address unit`` 的
+逐操作集参数。它表示一个缩放因子，需要乘以核心层地址，才能计算给定地址
+空间中的真实地址。是否支持 ``address unit`` 参数取决于每个操作集实现。
+``paddr`` 是唯一支持该参数的操作集实现。
 
-独立于地址空间的核心机制
-========================
+如果该值小于 ``PAGE_SIZE``，则只能使用 2 的幂。
+
+
+.. _damon_core_logic_zh_CN:
+
+核心逻辑
+========
+
+.. _damon_design_monitoring_zh_CN:
+
+监测
+----
 
 下面四个部分分别描述了DAMON的核心机制和五个监测属性，即 ``采样间隔`` 、 ``聚集间隔`` 、
 ``更新间隔`` 、 ``最小区域数`` 和 ``最大区域数`` 。
 
+请注意，``最小区域数`` 必须为 3 或更高。这是因为虚拟地址空间监测被设计为至少处理三个区域，
+以容纳普通虚拟地址空间中常见的两个大型未映射区域。虽然对 ``paddr`` 这类其他操作集来说，
+这一限制可能并非严格必要，但为了保持一致性，目前会对所有 DAMON 操作强制执行。
+
+要了解用户空间如何通过 :ref:`DAMON sysfs 接口 <sysfs_interface_zh_CN>` 设置这些属性，
+请参考文档的 :ref:`monitoring_attrs <sysfs_monitoring_attrs_zh_CN>` 部分。
+
 
 访问频率监测
-------------
+~~~~~~~~~~~~
 
 DAMON的输出显示了在给定的时间内哪些页面的访问频率是多少。访问频率的分辨率是通过设置
 ``采样间隔`` 和 ``聚集间隔`` 来控制的。详细地说，DAMON检查每个 ``采样间隔`` 对每
-个页面的访问，并将结果汇总。换句话说，计算每个页面的访问次数。在每个 ``聚合间隔`` 过
+个页面的访问，并将结果汇总。换句话说，计算每个页面的访问次数。在每个 ``聚集间隔`` 过
 去后，DAMON调用先前由用户注册的回调函数，以便用户可以阅读聚合的结果，然后再清除这些结
 果。这可以用以下简单的伪代码来描述::
 
@@ -103,38 +180,564 @@ DAMON的输出显示了在给定的时间内哪些页面的访问频率是多少
 这种机制的监测开销将随着目标工作负载规模的增长而任意增加。
 
 
+.. _damon_design_region_based_sampling_zh_CN:
+
 基于区域的抽样调查
-------------------
+~~~~~~~~~~~~~~~~~~
 
 为了避免开销的无限制增加，DAMON将假定具有相同访问频率的相邻页面归入一个区域。只要保持
 这个假设（一个区域内的页面具有相同的访问频率），该区域内就只需要检查一个页面。因此，对
 于每个 ``采样间隔`` ，DAMON在每个区域中随机挑选一个页面，等待一个 ``采样间隔`` ，检
-查该页面是否同时被访问，如果被访问则增加该区域的访问频率。因此，监测开销是可以通过设置
-区域的数量来控制的。DAMON允许用户设置最小和最大的区域数量来进行权衡。
+查该页面是否同时被访问，如果被访问则增加该区域的访问频率计数器。该计数器称为区域的
+``nr_accesses``。因此，监测开销是可以通过设置区域的数量来控制的。DAMON允许用户设置最小
+和最大的区域数量来进行权衡。
 
 然而，如果假设没有得到保证，这个方案就不能保持输出的质量。
 
 
+.. _damon_design_adaptive_regions_adjustment_zh_CN:
+
 适应性区域调整
---------------
+~~~~~~~~~~~~~~
 
 即使最初的监测目标区域被很好地构建以满足假设（同一区域内的页面具有相似的访问频率），数
 据访问模式也会被动态地改变。这将导致监测质量下降。为了尽可能地保持假设，DAMON根据每个
 区域的访问频率自适应地进行合并和拆分。
 
-对于每个 ``聚集区间`` ，它比较相邻区域的访问频率，如果频率差异较小，就合并这些区域。
-然后，在它报告并清除每个区域的聚合接入频率后，如果区域总数不超过用户指定的最大区域数，
-它将每个区域拆分为两个或三个区域。
+对于每个 ``聚集间隔`` ，它比较相邻区域的访问频率（``nr_accesses``）。如果差异较小，
+并且两个区域的大小之和小于总区域大小除以 ``最小区域数``，DAMON 就会合并这两个区域。如果
+合并后的总区域数仍然高于 ``最大区域数``，它会增大访问频率差异阈值并重复合并，直到满足区域
+数上限，或者阈值高于可能的最大值（``聚集间隔`` 除以 ``采样间隔``）。然后，在它报告并清除
+每个区域的聚合访问频率后，如果拆分后的区域总数不超过用户指定的最大区域数，它会把每个区域
+拆分为两个或三个区域。
 
 通过这种方式，DAMON提供了其最佳的质量和最小的开销，同时保持了用户为其权衡设定的界限。
 
+.. _damon_design_age_tracking_zh_CN:
+
+年龄跟踪
+~~~~~~~~
+
+通过分析监测结果，用户还可以发现某个区域当前的访问模式已经保持了多长时间。这可用于更好地理解
+访问模式。例如，可以利用访问频率和时近性实现页面放置算法。为了让这种访问模式保持时间分析更容
+易，DAMON 在每个区域中维护另一个名为 ``age`` 的计数器。对于每个 ``聚集间隔``，DAMON 检查该
+区域的大小和访问频率（``nr_accesses``）是否发生了显著变化。如果发生了变化，该计数器会被重置为
+零。否则，该计数器会增加。
+
+
+.. _damon_design_data_attrs_monitoring_zh_CN:
+
+数据属性监测
+~~~~~~~~~~~~
+
+数据访问模式只是数据属性的一种类型。在某些用例中，用户需要了解更多数据属性
+信息。例如，用户可能需要知道给定热或冷内存区域中有多少由匿名页支持，或者属于
+某个特定 cgroup。为此，提供了数据属性监测功能。
+
+使用该功能时，用户可以把感兴趣的数据属性注册到 DAMON :ref:`上下文
+<damon_design_execution_model_and_data_structures_zh_CN>` 中。注册通过为每个属性
+指定一个探针完成。每个探针指定一个规则，用于判断给定内存区域是否具有相关
+属性。该规则由多个过滤器构成。除支持的过滤器类型不同外，这些过滤器的工作方式
+与 :ref:`DAMOS 过滤器 <damon_design_damos_filters_zh_CN>` 相同。目前，数据属性
+监测只支持 ``anon`` 和 ``memcg`` 过滤器类型。
+
+如果注册了这类探针，DAMON 在进行访问 :ref:`采样
+<damon_design_region_based_sampling_zh_CN>` 时，会对每个区域的采样内存执行这些
+探针。每个 :ref:`聚集间隔 <damon_design_monitoring_zh_CN>` 中被识别为具有数据
+属性（命中探针）的样本数量，会计入每区域、每探针的计数器。因此，用户可以在
+每个聚集间隔后读取每区域、每探针的探针命中计数器，从而了解给定 DAMON 区域
+有多少具有特定数据属性。
+
+这是基于采样的机制。因此，它很轻量，但输出可能包含一些测量误差。用户应在
+充分理解统计意义的基础上使用输出。
+
+另一种更高精度的方式是使用 ``stat`` :ref:`动作
+<damon_design_damos_action_zh_CN>` 的 :ref:`DAMOS 过滤器
+<damon_design_damos_filters_zh_CN>`，并使用 ``sz_ops_filter_passed`` :ref:`统计
+<damon_design_damos_stat_zh_CN>`。这种方式以页级别提供数据属性信息。不过，由于
+它在页级别操作，开销与内存大小成正比。
 
 动态目标空间更新处理
---------------------
+~~~~~~~~~~~~~~~~~~~~
 
 监测目标地址范围可以动态改变。例如，虚拟内存可以动态地被映射和解映射。物理内存可以被
 热插拔。
 
 由于在某些情况下变化可能相当频繁，DAMON允许监控操作检查动态变化，包括内存映射变化，
 并仅在用户指定的时间间隔（ ``更新间隔`` ）中的每个时间段，将其应用于监控操作相关的
-数据结构，如抽象的监控目标内存区。
\ No newline at end of file
+数据结构，如抽象的监控目标内存区。
+
+用户空间可以通过 DAMON sysfs 接口和/或跟踪点获取监测结果。更多细节请分别参考
+:ref:`DAMOS 尝试区域 <sysfs_schemes_tried_regions_zh_CN>` 和 :ref:`跟踪点 <tracepoint_zh_CN>`
+文档。
+
+
+.. _damon_design_monitoring_params_tuning_guide_zh_CN:
+
+监测参数调优指南
+~~~~~~~~~~~~~~~~
+
+简而言之，应设置 ``聚集间隔``，使其能够为使用目的捕获有意义数量的访问。访问数量可以用聚集后
+监测结果快照中各区域的 ``nr_accesses`` 和 ``age`` 来衡量。该间隔的默认值 ``100ms`` 在许多情况
+下被证明过短。应按 ``聚集间隔`` 的比例设置 ``采样间隔``。默认推荐比例为 ``1/20``。
+
+``聚集间隔`` 应设置为工作负载可在该间隔内为监测目的产生一定数量访问的时间间隔。如果该间隔过短，
+只能捕获少量访问。结果是，监测结果会看起来像所有内容都同样只是很少被访问。对许多目的而言，这
+将毫无用处。不过，如果该间隔过长，根据给定目的的时间尺度，区域通过 :ref:`区域调整机制
+<damon_design_adaptive_regions_adjustment_zh_CN>` 收敛所需的时间可能过长。如果工作负载实际只产生
+很少访问，而用户却认为监测目的所需的访问数量很高，就可能发生这种情况。对于这种情况，应仔细重
+新考虑每个 ``聚集间隔`` 要捕获的目标访问数量。还要注意，捕获的访问数量不仅用 ``nr_accesses``
+表示，也用 ``age`` 表示。例如，即使监测结果中的每个区域都显示 ``nr_accesses`` 为零，仍然可以
+用 ``age`` 值作为时近性信息来区分区域。
+
+因此，``聚集间隔`` 的最佳值取决于工作负载的访问密集程度。用户应根据每个聚集后的监测结果快照
+中捕获的访问数量来调优该间隔。
+
+请注意，该间隔的默认值是 100 毫秒，在许多情况下都太短，尤其是在大型系统上。
+
+``采样间隔`` 定义每次聚集的分辨率。如果它设置得过大，监测结果会看起来像每个区域都同样很少被
+访问，或者同样频繁地被访问。也就是说，区域将无法根据访问模式区分，因此结果在许多用例中都会无
+用。如果 ``采样间隔`` 过小，它不会降低分辨率，但会增加监测开销。如果它已经足以为给定目的提供
+足够的监测结果分辨率，就不应再不必要地降低。建议将它按 ``聚集间隔`` 的比例设置。默认比例设为
+``1/20``，并且仍然推荐该比例。
+
+基于手动调优指南，DAMON 提供了更直观的、基于调节项的间隔自动调优机制。更多细节请参考
+:ref:`该功能的设计文档 <damon_design_monitoring_intervals_autotuning_zh_CN>`。
+
+基于上述指南的示例调优，请参考英文文档 Documentation/mm/damon/monitoring_intervals_tuning_example.rst。
+
+
+.. _damon_design_monitoring_intervals_autotuning_zh_CN:
+
+监测间隔自动调优
+~~~~~~~~~~~~~~~~
+
+DAMON 基于 :ref:`调优指南的思路 <damon_design_monitoring_params_tuning_guide_zh_CN>`，提供了
+对 ``采样间隔`` 和 ``聚集间隔`` 的自动调优机制。该调优机制允许用户设置希望 DAMON 在给定时间间隔
+内观测到的访问事件数量目标。用户可以把该目标指定为 DAMON 观测到的访问事件数量与理论最大事件数
+量之间的比例（``access_bp``），该比例在给定数量的聚集中测量（``aggrs``）。
+
+DAMON 观测到的访问事件基于 DAMON :ref:`区域假设 <damon_design_region_based_sampling_zh_CN>`
+按字节粒度计算。例如，如果发现大小为 ``X`` 字节、``nr_accesses`` 为 ``Y`` 的区域，就意味着
+DAMON 观测到了 ``X * Y`` 个访问事件。该区域的理论最大访问事件也以相同方式计算，但会把 ``Y``
+替换为理论最大 ``nr_accesses``，即 ``聚集间隔 / 采样间隔``。
+
+该机制会计算 ``aggrs`` 次聚集期间的访问事件比例。如果观测到的访问比例低于或高于目标值，就按
+相同比例增大或减小 ``采样间隔`` 和 ``聚集间隔``。间隔变化比例按当前采样比例与目标比例之间的
+距离决定。
+
+用户还可以通过两个参数（``min_sample_us`` 和 ``max_sample_us``）进一步设置调优机制可设置的
+最小和最大 ``采样间隔``。由于调优机制总是以相同比例改变 ``采样间隔`` 和 ``聚集间隔``，所以
+每次调优变化后的最小和最大 ``聚集间隔`` 也可以自动一起设置。
+
+该调优默认关闭，需要由用户显式设置。根据经验法则和帕累托原则，推荐使用 4% 的访问样本比例目标。
+请注意，这里应用了两次帕累托原则（80/20 规则）。也就是说，假设以 4%（20% 的 20%）的 DAMON
+观测访问事件比例（来源），捕获 64%（80% 乘以 80%）的真实访问事件（结果）。
+
+要了解用户空间如何通过 :ref:`DAMON sysfs 接口 <sysfs_interface_zh_CN>` 使用该功能，请参考文档
+的 :ref:`intervals_goal <damon_usage_sysfs_monitoring_intervals_goal_zh_CN>` 部分。
+
+
+.. _damon_design_damos_zh_CN:
+
+操作方案
+--------
+
+数据访问监测的一个常见目的，是实现访问感知的系统效率优化。例如：
+
+    换出超过两分钟未被访问的内存区域
+
+或者：
+
+    对大于 2 MiB 且显示高访问频率超过一分钟的内存区域使用 THP。
+
+这类方案的一种直接做法是基于剖析的优化。也就是说，使用 DAMON 获取工作负载
+或系统的数据访问监测结果，通过分析监测结果找到具有特殊特征的内存区域，并针对
+这些区域进行系统操作变更。这些变更可以通过修改软件（应用程序和/或内核）或向
+其提供建议来完成，也可以通过重新配置硬件来完成。离线和在线两种方式都可以使用。
+
+其中，在运行时向内核提供建议会比较灵活且有效，因此被广泛使用。不过，实现这类
+方案可能引入不必要的冗余和低效。如果关注的类型很常见，剖析可能是冗余的。在
+内核和用户空间之间交换包括监测结果和操作建议在内的信息，也可能效率较低。
+
+为了让用户通过移交这些工作来减少这种冗余和低效，DAMON 提供了一个名为基于
+数据访问监测的操作方案（DAMOS）的功能。它允许用户以高层次指定期望的方案。
+对于这类规格，DAMON 会开始监测，找到具有感兴趣访问模式的区域，并在每个用户
+指定的时间间隔（称为 ``apply_interval``）把用户期望的操作动作应用于这些区域。
+
+要了解用户空间如何通过 :ref:`DAMON sysfs 接口 <sysfs_interface_zh_CN>` 设置
+``apply_interval``，请参考文档的 :ref:`apply_interval_us <sysfs_scheme_zh_CN>`
+部分。
+
+
+.. _damon_design_damos_action_zh_CN:
+
+操作动作
+~~~~~~~~
+
+用户希望应用到其感兴趣区域的管理动作。例如，换出、为下一次回收受害者选择提高
+优先级、建议 ``khugepaged`` 折叠或拆分，或者什么也不做而只收集区域统计信息。
+
+支持的动作列表在 DAMOS 中定义，但每个动作的实现位于 DAMON 操作集层，因为实现
+通常依赖于监测目标地址空间。例如，换出特定虚拟地址范围的代码会不同于换出物理
+地址范围的代码。监测操作实现集也不被要求支持列表中的所有动作。因此，特定 DAMOS
+动作是否可用取决于选择一起使用的操作集。
+
+支持的动作列表、含义以及支持每个动作的 DAMON 操作集如下。
+
+ - ``willneed``：对带有 ``MADV_WILLNEED`` 的区域调用 ``madvise()``。
+   ``vaddr`` 和 ``fvaddr`` 操作集支持。
+ - ``cold``：对带有 ``MADV_COLD`` 的区域调用 ``madvise()``。
+   ``vaddr`` 和 ``fvaddr`` 操作集支持。
+ - ``pageout``：回收该区域。
+   ``vaddr``、``fvaddr`` 和 ``paddr`` 操作集支持。
+ - ``hugepage``：对带有 ``MADV_HUGEPAGE`` 的区域调用 ``madvise()``。
+   ``vaddr`` 和 ``fvaddr`` 操作集支持。当禁用 TRANSPARENT_HUGEPAGE 时，
+   应用该动作只会失败。
+ - ``nohugepage``：对带有 ``MADV_NOHUGEPAGE`` 的区域调用 ``madvise()``。
+   ``vaddr`` 和 ``fvaddr`` 操作集支持。当禁用 TRANSPARENT_HUGEPAGE 时，
+   应用该动作只会失败。
+ - ``collapse``：对带有 ``MADV_COLLAPSE`` 的区域调用 ``madvise()``。
+   ``vaddr`` 和 ``fvaddr`` 操作集支持。当禁用 TRANSPARENT_HUGEPAGE 时，
+   应用该动作只会失败。
+ - ``lru_prio``：提高该区域在其 LRU 链表上的优先级。
+   ``paddr`` 操作集支持。
+ - ``lru_deprio``：降低该区域在其 LRU 链表上的优先级。
+   ``paddr`` 操作集支持。
+ - ``migrate_hot``：迁移区域，并优先迁移更热的区域。
+   ``vaddr``、``fvaddr`` 和 ``paddr`` 操作集支持。
+ - ``migrate_cold``：迁移区域，并优先迁移更冷的区域。
+   ``vaddr``、``fvaddr`` 和 ``paddr`` 操作集支持。
+ - ``stat``：什么也不做，只统计信息。
+   所有操作集都支持。
+
+把除 ``stat`` 外的动作应用到某个区域，会被认为改变了该区域的特征。因此，
+当任何这类动作被应用到区域时，DAMOS 会重置这些区域的 age。
+
+要了解用户空间如何通过 :ref:`DAMON sysfs 接口 <sysfs_interface_zh_CN>` 设置
+动作，请参考文档的 :ref:`action <sysfs_scheme_zh_CN>` 部分。
+
+
+.. _damon_design_damos_access_pattern_zh_CN:
+
+目标访问模式
+~~~~~~~~~~~~
+
+方案感兴趣的访问模式。这些模式由 DAMON 监测结果提供的属性构成，具体包括
+大小、访问频率和年龄。用户可以通过设置这三个属性的最小值和最大值，描述
+自己感兴趣的访问模式。如果某个区域的这三个属性都在范围内，DAMOS 就把它
+分类为该方案感兴趣的区域之一。
+
+要了解用户空间如何通过 :ref:`DAMON sysfs 接口 <sysfs_interface_zh_CN>` 设置
+访问模式，请参考文档的 :ref:`access_pattern <sysfs_access_pattern_zh_CN>`
+部分。
+
+
+.. _damon_design_damos_quotas_zh_CN:
+
+配额
+~~~~
+
+DAMOS 的开销上界控制功能。如果目标访问模式没有正确调优，DAMOS 可能带来高开销。
+例如，如果发现一个具有感兴趣访问模式的巨大内存区域，把方案动作应用到该巨大区域
+的所有页面可能消耗不可接受的大量系统资源。通过调优访问模式来防止这类问题可能
+很有挑战，特别是在工作负载的访问模式高度动态时。
+
+为缓解这种情况，DAMOS 提供了一个称为配额的开销上界控制功能。它允许用户指定
+DAMOS 可用于应用动作的时间上限，和/或在用户指定的时间段内可应用动作的最大内存
+区域字节数。
+
+要了解用户空间如何通过 :ref:`DAMON sysfs 接口 <sysfs_interface_zh_CN>` 设置基本
+配额，请参考文档的 :ref:`quotas <sysfs_quotas_zh_CN>` 部分。
+
+
+.. _damon_design_damos_quotas_prioritization_zh_CN:
+
+优先级
+^^^^^^
+
+一种在配额限制下作出良好决策的机制。当由于配额限制而无法把动作应用到所有感兴趣
+区域时，DAMOS 会对区域排序，并只把动作应用到优先级足够高、且不会超过配额的区域。
+
+每个动作的优先级机制应该不同。例如，很少被访问（更冷）的内存区域应在 page-out
+方案动作中被优先处理。相反，对于大页折叠方案动作，更冷的区域应被降低优先级。
+因此，每个动作的优先级机制与动作一起，在各个 DAMON 操作集中实现。
+
+虽然实现取决于 DAMON 操作集，但通常会使用区域的访问模式属性来计算优先级。有些
+用户可能希望针对自己的特定场景个性化这些机制。例如，有些用户可能希望该机制更重视
+时近性（``age``）而不是访问频率（``nr_accesses``）。DAMOS 允许用户指定每个访问模式
+属性的权重，并把这些信息传递给底层机制。不过，权重如何被尊重，甚至是否被尊重，
+都取决于底层优先级机制实现。
+
+要了解用户空间如何通过 :ref:`DAMON sysfs 接口 <sysfs_interface_zh_CN>` 设置优先级
+权重，请参考文档的 :ref:`weights <sysfs_quotas_zh_CN>` 部分。
+
+
+.. _damon_design_damos_quotas_failed_memory_charging_ratio_zh_CN:
+
+动作失败内存计费比率
+^^^^^^^^^^^^^^^^^^^^
+
+对给定区域执行 DAMOS 动作时，区域中某些内存子集可能失败。例如，如果动作是
+``pageout``，而该区域包含一些不可回收页，则把该动作应用到这些页会失败。
+这类失败动作应用消耗的系统资源量通常不同于成功动作应用。对于这类情况，用户可以
+为失败内存设置不同的计费比率。该比率可以用 ``fail_charge_num`` 和
+``fail_charge_denom`` 参数指定。这两个参数分别表示比率的分子和分母。只有当
+``fail_charge_denom`` 不为零时，该功能才启用。
+
+例如，假设某个 DAMOS 动作被应用到大小为 1,000 MiB 的区域。该动作只成功应用到
+该区域的 700 MiB。``fail_charge_num`` 和 ``fail_charge_denom`` 分别设置为 ``1``
+和 ``1024``。那么只会计费 700 MiB 和 300 KiB 的大小（``700 MiB + 300 MiB * 1 /
+1024``）。
+
+
+.. _damon_design_damos_quotas_auto_tuning_zh_CN:
+
+面向目标的反馈驱动自动调优
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+自动反馈驱动的配额调优。用户可以不设置绝对配额值，而是指定自己感兴趣的指标，
+以及希望该指标达到的目标值。随后，DAMOS 会自动调优对应方案的激进程度（配额）。
+例如，如果 DAMOS 未达到目标，DAMOS 会自动增加配额。如果 DAMOS 超过目标，则会
+减少配额。
+
+用户可以按需要选择两种这样的调优算法。
+
+- ``consist``：基于比例反馈环的算法。尝试找到一个应持续保持的最佳配额，以便持续
+  达成目标。适用于动态和长时间运行环境中的内核内部操作。这是默认选择。如果不确定，
+  请使用它。
+- ``temporal``：更直接的算法。尝试尽快达成目标，使用允许的最大配额，但只持续短暂
+  时间。当配额未达成时，该算法持续把配额调优到允许的最大值。一旦配额[超过]达成，
+  它就把配额设置为零。适用于需要确定性控制的环境。
+
+目标可以用五个参数指定，即 ``target_metric``、``target_value``、``current_value``、
+``nid`` 和 ``path``。自动调优机制尝试使 ``target_metric`` 的 ``current_value``
+等于 ``target_value``。
+
+- ``user_input``：用户提供的值。用户可以使用任何自己感兴趣的指标作为该值。用户空间
+  主工作负载的延迟或吞吐量、空闲内存率或内存压力停滞时间（PSI）等系统指标都可以
+  作为示例。请注意，在这种情况下，用户应自己显式设置 ``current_value``。换言之，
+  用户应反复提供反馈。
+- ``some_mem_psi_us``：系统范围的 ``some`` 内存压力停滞信息，单位为微秒，从上一次
+  配额重置到下一次配额重置之间测量。DAMOS 自行进行测量，所以用户只需要在初始时
+  设置 ``target_value``。换言之，DAMOS 会自反馈。
+- ``node_mem_used_bp``：特定 NUMA 节点的已用内存比率，单位为 bp（1/10,000）。
+- ``node_mem_free_bp``：特定 NUMA 节点的空闲内存比率，单位为 bp（1/10,000）。
+- ``node_memcg_used_bp``：特定 cgroup 在特定 NUMA 节点上的节点已用内存比率，
+  单位为 bp（1/10,000）。
+- ``node_memcg_free_bp``：特定 cgroup 在特定 NUMA 节点上的节点未用内存比率，
+  单位为 bp（1/10,000）。
+- ``active_mem_bp``：活跃内存相对活跃 + 非活跃（LRU）内存大小的比率，单位为 bp
+  （1/10,000）。
+- ``inactive_mem_bp``：非活跃内存相对活跃 + 非活跃（LRU）内存大小的比率，单位为 bp
+  （1/10,000）。
+- ``node_eligible_mem_bp``：节点中符合方案目标访问模式条件的内存比率，单位为 bp
+  （1/10,000）。
+
+``nid`` 仅在使用 ``node_mem_used_bp``、``node_mem_free_bp``、
+``node_memcg_used_bp``、``node_memcg_free_bp`` 和 ``node_eligible_mem_bp`` 指标时
+必须提供，用于指定具体 NUMA 节点。
+
+``path`` 仅在使用 ``node_memcg_used_bp`` 和 ``node_memcg_free_bp`` 指标时必须提供，
+用于指定 cgroup 路径。该值应为从 cgroup 挂载点起算的内存 cgroup 路径。
+
+要了解用户空间如何通过 :ref:`DAMON sysfs 接口 <sysfs_interface_zh_CN>` 设置调优
+目标指标、目标值和/或当前值，请参考文档的 :ref:`quota goals
+<sysfs_schemes_quota_goals_zh_CN>` 部分。
+
+
+.. _damon_design_damos_watermarks_zh_CN:
+
+水位
+~~~~
+
+条件式 DAMOS（去）激活自动化。用户可能希望 DAMOS 只在特定情况下运行。例如，
+当保证有足够空闲内存时，运行主动回收方案只会消耗不必要的系统资源。为避免这类
+消耗，用户需要手动监测一些指标（例如空闲内存率），并打开或关闭 DAMON/DAMOS。
+
+DAMOS 允许用户使用三个水位移交这类工作。它允许用户配置自己感兴趣的指标，以及
+三个水位值，即高、中和低。如果指标值高于高水位或低于低水位，该方案会被停用。
+如果指标值低于中水位但高于低水位，该方案会被激活。如果所有方案都被水位停用，
+监测也会被停用。在这种情况下，DAMON 工作线程只会周期性地检查水位，因此几乎
+不会产生开销。
+
+要了解用户空间如何通过 :ref:`DAMON sysfs 接口 <sysfs_interface_zh_CN>` 设置水位，
+请参考文档的 :ref:`watermarks <sysfs_watermarks_zh_CN>` 部分。
+
+
+.. _damon_design_damos_filters_zh_CN:
+
+过滤器
+~~~~~~
+
+非访问模式的目标内存区域过滤。如果用户运行自己编写的程序或拥有好的剖析工具，
+他们可能比内核知道更多信息，例如未来的访问模式或针对特定内存类型的一些特殊需求。
+例如，一些用户可能知道只有匿名页会影响其程序性能。他们也可以拥有一组延迟关键进程
+列表。
+
+为了让用户用这类特殊知识优化 DAMOS 方案，DAMOS 提供了一个称为 DAMOS 过滤器的功能。
+该功能允许用户为每个方案设置任意数量的过滤器。每个过滤器指定：
+
+- 一种内存类型（``type``），
+- 它是针对该类型的内存，还是针对该类型以外的所有内存（``matching``），以及
+- 是否允许（包含）或拒绝（排除）把方案动作应用到该内存（``allow``）。
+
+为了高效处理过滤器，一些类型的过滤器由核心层处理，而其他类型由操作集处理。因此，
+在后一种情况下，是否支持过滤器类型取决于 DAMON 操作集。对于核心层处理的过滤器，
+被过滤器排除的内存区域不会计入方案已尝试应用的区域。相反，如果内存区域被操作集层
+处理的过滤器过滤，它会计入方案已尝试。这种差异会影响统计信息。
+
+安装多个过滤器时，由核心层处理的一组过滤器首先求值。之后，由操作层处理的一组过滤器
+求值。每组过滤器内部按安装顺序求值。如果某部分内存匹配某个过滤器，后续过滤器会被
+忽略。如果该部分因为没有匹配任何过滤器而通过过滤器求值阶段，则是否对其应用方案动作
+取决于最后一个过滤器的 allow 类型。如果最后一个过滤器是允许型，该部分内存会被拒绝，
+反之亦然。
+
+例如，假设按顺序安装了 1）一个允许匿名页的过滤器，和 2）另一个拒绝年轻页的过滤器。
+如果某个符合方案动作应用条件的区域中的页面是匿名页，不论它是否年轻，方案动作都会应用
+到该页，因为它匹配第一个允许过滤器。如果该页不是匿名页但年轻，则方案动作不会应用，
+因为第二个拒绝过滤器阻止了它。如果该页既不是匿名页也不年轻，由于没有匹配过滤器，
+该页会通过过滤器求值阶段，并且动作会应用到该页。
+
+当前支持以下 ``type`` 的过滤器。
+
+- 核心层处理
+    - addr
+        - 应用于属于给定地址范围的页面。
+    - target
+        - 应用于属于给定 DAMON 监测目标的页面。
+- 操作层处理，只有 ``paddr`` 操作集支持。
+    - anon
+        - 应用于包含未存储在文件中的数据的页面。
+    - active
+        - 应用于活跃页。
+    - memcg
+        - 应用于属于给定 cgroup 的页面。
+    - young
+        - 应用于自方案上次访问检查以来被访问过的页面。
+    - hugepage_size
+        - 应用于以给定大小范围管理的页面。
+    - unmapped
+        - 应用于未映射的页面。
+
+要了解用户空间如何通过 :ref:`DAMON sysfs 接口 <sysfs_interface_zh_CN>` 设置过滤器，
+请参考文档的 :ref:`filters <sysfs_filters_zh_CN>` 部分。
+
+.. _damon_design_damos_stat_zh_CN:
+
+统计信息
+~~~~~~~~
+
+DAMOS 行为的统计信息，用于帮助监测、调优和调试 DAMOS。
+
+DAMOS 从方案执行开始起，为每个方案统计以下信息。
+
+- ``nr_tried``：方案尝试应用的区域总数。
+- ``sz_tried``：方案尝试应用的区域总大小。
+- ``sz_ops_filter_passed``：通过操作集层处理的 DAMOS 过滤器的总字节数。
+- ``nr_applied``：方案已应用的区域总数。
+- ``sz_applied``：方案已应用的区域总大小。
+- ``qt_exceeds``：方案配额被超过的总次数。
+- ``nr_snapshots``：方案尝试应用的 DAMON 快照总数。
+- ``max_nr_snapshots``：``nr_snapshots`` 的上限。
+
+“方案尝试应用到某个区域”表示 DAMOS 核心逻辑判断该区域符合应用方案
+:ref:`动作 <damon_design_damos_action_zh_CN>` 的条件。核心逻辑处理的
+:ref:`访问模式 <damon_design_damos_access_pattern_zh_CN>`、:ref:`配额
+<damon_design_damos_quotas_zh_CN>`、:ref:`水位 <damon_design_damos_watermarks_zh_CN>`
+和 :ref:`过滤器 <damon_design_damos_filters_zh_CN>` 可能影响这一判断。核心逻辑
+只会请求底层 :ref:`操作集 <damon_operations_set_zh_CN>` 对该区域应用动作，因此
+该动作是否真正应用并不明确。这就是它被称为“尝试”的原因。
+
+“方案应用到某个区域”表示 :ref:`操作集 <damon_operations_set_zh_CN>` 已经把动作
+应用到该区域的至少一部分。操作集处理的 :ref:`过滤器
+<damon_design_damos_filters_zh_CN>`、:ref:`动作 <damon_design_damos_action_zh_CN>`
+类型以及该区域中的页面类型都可能影响这一点。例如，如果过滤器设置为排除匿名页且
+该区域只有匿名页，或者动作是 ``pageout`` 而该区域的所有页面都不可回收，则把动作
+应用到该区域会失败。
+
+不同于普通统计信息，``max_nr_snapshots`` 由用户设置。如果它设置为非零，且
+``nr_snapshots`` 等于或大于 ``max_nr_snapshots``，该方案会被停用。
+
+要了解用户空间如何通过 :ref:`DAMON sysfs 接口 <sysfs_interface_zh_CN>` 读取统计
+信息，请参考文档的 :ref:`stats <sysfs_schemes_stats_zh_CN>` 部分。
+
+
+区域遍历
+~~~~~~~~
+
+DAMOS 功能允许用户访问刚刚应用了 DAMOS 动作的每个区域。使用该功能，DAMON
+:ref:`API <damon_design_api_zh_CN>` 允许用户访问这些区域的完整属性，包括访问监测结果以及
+区域内部通过 DAMOS 过滤器的内存量。:ref:`DAMON sysfs 接口 <sysfs_interface_zh_CN>` 也允许
+用户通过特殊 :ref:`文件 <sysfs_schemes_tried_regions_zh_CN>` 读取这些数据。
+
+.. _damon_design_api_zh_CN:
+
+应用编程接口
+------------
+
+用于内核空间数据访问感知应用的编程接口。DAMON 是一个框架，所以它本身什么也不做。相反，
+它只帮助子系统和模块等其他内核组件使用 DAMON 的核心功能构建它们的数据访问感知应用。为此，
+DAMON 通过其应用编程接口，即 ``include/linux/damon.h``，向其他内核组件暴露所有功能。接口
+细节请参考 API :doc:`文档 <api>`。
+
+
+.. _damon_modules_zh_CN:
+
+模块
+====
+
+由于 DAMON 的核心是供内核组件使用的框架，它本身不向用户空间提供任何直接接口。相反，这些接口
+应由每个使用 DAMON API 的内核组件来实现。DAMON 子系统本身实现了这类 DAMON API 用户模块，
+它们分别用于通用目的的 DAMON 控制和特定目的的数据访问感知系统操作，并为用户空间提供稳定的应
+用二进制接口（ABI）。用户空间可以使用这些接口构建高效的数据访问感知应用程序。
+
+
+通用目的用户接口模块
+--------------------
+
+DAMON 模块为运行时的通用目的 DAMON 用法提供用户空间 ABI。
+
+与许多其他 ABI 一样，这些模块会在类似 ``sysfs`` 的伪文件系统上创建文件，允许用户通过写入和读
+取这些文件来向 DAMON 指定请求并获取回答。作为这类 I/O 的响应，DAMON 用户接口模块会通过 DAMON
+API 按用户请求控制 DAMON 并获取结果，然后把结果返回给用户空间。
+
+这些 ABI 是为用户空间应用程序开发而设计的，而不是为人工手动操作而设计的。建议人工用户使用这类
+用户空间工具。一个用 Python 编写的此类用户空间工具可在 Github
+（https://github.com/damonitor/damo）、Pypi（https://pypistats.org/packages/damo）以及多个发行
+版（https://repology.org/project/damo/versions）中获取。
+
+目前，该类型有一个模块可用，即 ``DAMON sysfs interface``。关于接口细节，请参考 ABI
+:ref:`文档 <sysfs_interface_zh_CN>`。
+
+
+.. _damon_modules_special_purpose_zh_CN:
+
+专用访问感知内核模块
+--------------------
+
+DAMON 模块为特定目的的 DAMON 用法提供用户空间 ABI。
+
+DAMON 用户接口模块用于在运行时完整控制所有 DAMON 功能。对于每种专用的、系统范围的数据访问感知
+系统操作，例如主动回收或 LRU 链表均衡，可以通过移除该特定目的不需要的调节项来简化接口，并扩展
+为启动时甚至编译时控制。用于该用途的 DAMON 控制参数默认值也需要针对该目的进行优化。
+
+为支持这些场景，DAMON 还提供了更多使用 DAMON API 的内核模块，它们提供更简单且更优化的用户空间
+接口。目前提供了用于访问监测统计、主动回收和 LRU 链表操作的三个模块。更多细节请阅读这些模块的
+使用文档（:doc:`../../admin-guide/mm/damon/stat`,
+:doc:`../../admin-guide/mm/damon/reclaim` 和
+:doc:`../../admin-guide/mm/damon/lru_sort`）。
+
+.. _damon_design_special_purpose_modules_exclusivity_zh_CN:
+
+请注意，这些模块当前以互斥方式运行。如果其中一个模块已经在运行，其他模块在收到启动请求时将返回
+``-EBUSY``。
+
+示例 DAMON 模块
+----------------
+
+DAMON 模块提供 DAMON 内核 API 用法示例。
+
+内核程序员可以使用 DAMON 内核 API 构建自己的专用或通用目的 DAMON 模块。为了帮助他们容易理解
+如何使用 DAMON 内核 API，Linux 源码树的 ``samples/damon/`` 目录下提供了一些示例模块。请注意，
+这些模块不是为实际产品使用而开发的，而只是为了展示如何以简单方式使用 DAMON 内核 API。
diff --git a/Documentation/translations/zh_CN/networking/driver.rst b/Documentation/translations/zh_CN/networking/driver.rst
new file mode 100644
index 000000000000..acb0863c6b0d
--- /dev/null
+++ b/Documentation/translations/zh_CN/networking/driver.rst
@@ -0,0 +1,138 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: Documentation/networking/driver.rst
+
+:翻译:
+
+	陈思为 Siwei Chen <businiaoanka@anka1.top>
+
+================
+Softnet 驱动问题
+================
+
+探测指南
+========
+
+地址校验
+--------
+
+为设备获取的任何硬件层地址都应进行校验。例如，以太网地址应使用
+linux/etherdevice.h 中的 is_valid_ether_addr() 进行检查。
+
+关闭/停止指南
+=============
+
+静默
+----
+
+ndo_stop 例程被调用后，硬件不得再收发任何数据。所有在途报文都必须中止。
+如有必要，应轮询或等待任何复位命令完成。
+
+自动关闭
+--------
+
+若设备仍处于 UP 状态，ndo_stop 例程将由 unregister_netdevice 调用。
+
+发送路径指南
+============
+
+提前停止队列
+------------
+
+ndo_start_xmit 方法在任何正常情况下都不得返回 NETDEV_TX_BUSY。
+除非设备确实无法预先判断其发送功能何时会繁忙，否则返回该值被视为严重错误。
+
+相反，驱动必须正确地维护队列。例如，对于实现分散-聚集
+（scatter-gather）的驱动，这意味着：
+
+.. code-block:: c
+
+	static u32 drv_tx_avail(struct drv_ring *dr)
+	{
+		u32 used = READ_ONCE(dr->prod) - READ_ONCE(dr->cons);
+
+		return dr->tx_ring_size - (used & dr->tx_ring_mask);
+	}
+
+	static netdev_tx_t drv_hard_start_xmit(struct sk_buff *skb,
+					       struct net_device *dev)
+	{
+		struct drv *dp = netdev_priv(dev);
+		struct netdev_queue *txq;
+		struct drv_ring *dr;
+		int idx;
+
+		idx = skb_get_queue_mapping(skb);
+		dr = dp->tx_rings[idx];
+		txq = netdev_get_tx_queue(dev, idx);
+
+		//...
+		/* 这应当是极为罕见的竞争——记录下来。 */
+		if (drv_tx_avail(dr) <= skb_shinfo(skb)->nr_frags + 1) {
+			netif_tx_stop_queue(txq);
+			netdev_warn(dev, "Tx Ring full when queue awake!\n");
+			return NETDEV_TX_BUSY;
+		}
+
+		//... 将报文排队到网卡 ...
+
+		netdev_tx_sent_queue(txq, skb->len);
+
+		//... 使用 WRITE_ONCE() 更新 tx 生产者索引 ...
+
+		if (!netif_txq_maybe_stop(txq, drv_tx_avail(dr),
+					  MAX_SKB_FRAGS + 1, 2 * MAX_SKB_FRAGS))
+			dr->stats.stopped++;
+
+		//...
+		return NETDEV_TX_OK;
+	}
+
+然后在 TX 回收事件处理的末尾：
+
+.. code-block:: c
+
+	//... 使用 WRITE_ONCE() 更新 tx 消费者索引 ...
+
+	netif_txq_completed_wake(txq, cmpl_pkts, cmpl_bytes,
+				 drv_tx_avail(dr), 2 * MAX_SKB_FRAGS);
+
+无锁队列停止/唤醒辅助宏
+~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: include/net/netdev_queues.h
+   :doc: Lockless queue stopping / waking helpers.
+
+netif_txq_maybe_stop()、netif_txq_try_stop() 等标准宏已经过充分测试，
+请优先使用它们，而非本地同步方案。
+
+无独占所有权
+------------
+
+ndo_start_xmit 方法不得修改被克隆 SKB 的共享部分。
+
+及时完成
+--------
+
+请谨记：一旦 ndo_start_xmit 方法返回 NETDEV_TX_OK，
+驱动就有责任在有限的时间内释放该 SKB。
+
+例如，这意味着不允许你的 TX 缓解方案在没有新 TX 报文发送时，
+让 TX 报文永远“滞留”在 TX 环中而不被回收。
+这种错误会使等待发送缓冲区空间释放的套接字发生死锁。
+
+若 ndo_start_xmit 方法返回 NETDEV_TX_BUSY，
+则不得保留对该 SKB 的任何引用，也不得尝试释放它。
+
+错误消息报告
+============
+
+许多驱动配置接口会向驱动传递一个 Netlink 扩展 ACK（``extack``）对象
+（直接作为参数，或作为参数结构体的成员）。驱动应尽量通过 ``extack`` 对象
+报告大多数错误。表示系统或设备行为异常、处于不良状态的系统级异常，则应继续
+报告到系统日志。
+
+消息应 **要么** 通过 ``extack`` 传递， **要么** 写入系统日志。驱动不应
+试图将同一信息同时报告到两处。
diff --git a/Documentation/translations/zh_CN/networking/index.rst b/Documentation/translations/zh_CN/networking/index.rst
index 333e9f6cafff..bf22d22b64db 100644
--- a/Documentation/translations/zh_CN/networking/index.rst
+++ b/Documentation/translations/zh_CN/networking/index.rst
@@ -21,7 +21,10 @@
    :maxdepth: 1
 
    msg_zerocopy
+   driver
+   ipv6
    napi
+   secid
    vxlan
    netif-msg
    xfrm_proc
@@ -29,6 +32,8 @@
    alias
    mptcp-sysctl
    generic-hdlc
+   sriov
+   team
    timestamping
 
 Todolist:
@@ -74,7 +79,6 @@ Todolist:
 *   dctcp
 *   devmem
 *   dns_resolver
-*   driver
 *   eql
 *   fib_trie
 *   filter
@@ -87,7 +91,6 @@ Todolist:
 *   ip_dynaddr
 *   ipsec
 *   ip-sysctl
-*   ipv6
 *   ipvlan
 *   ipvs-sysctl
 *   kcm
@@ -124,10 +127,8 @@ Todolist:
 *   representors
 *   rxrpc
 *   sctp
-*   secid
 *   seg6-sysctl
 *   smc-sysctl
-*   sriov
 *   statistics
 *   strparser
 *   switchdev
@@ -136,7 +137,6 @@ Todolist:
 *   tc-queue-filters
 *   tcp_ao
 *   tcp-thin
-*   team
 *   tipc
 *   tproxy
 *   tuntap
diff --git a/Documentation/translations/zh_CN/networking/ipv6.rst b/Documentation/translations/zh_CN/networking/ipv6.rst
new file mode 100644
index 000000000000..3726b6fdc460
--- /dev/null
+++ b/Documentation/translations/zh_CN/networking/ipv6.rst
@@ -0,0 +1,76 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: Documentation/networking/ipv6.rst
+
+:翻译:
+
+	陈思为 Siwei Chen <businiaoanka@anka1.top>
+
+====
+IPv6
+====
+
+
+ipv6 模块的选项在加载时以参数形式提供。
+
+模块选项可作为 insmod 或 modprobe 命令的命令行参数给出，但通常在
+``/etc/modules.d/*.conf`` 配置文件中，或在发行版特定的配置文件中指定。
+
+可用的 ipv6 模块参数如下所列。若未指定某参数，则使用其默认值。
+
+参数如下：
+
+disable
+
+	指定是否在加载 IPv6 模块的同时禁用其全部功能。当另一模块依赖于 IPv6
+	模块已加载，但又不需要任何 IPv6 地址或操作时，可使用此选项。
+
+	可选值及其效果如下：
+
+	0
+		启用 IPv6。
+
+		这是默认值。
+
+	1
+		禁用 IPv6。
+
+		接口不会添加 IPv6 地址，也无法打开 IPv6 套接字。
+
+		需要重启才能启用 IPv6。
+
+autoconf
+
+	指定是否在所有接口上启用 IPv6 地址自动配置。当不希望根据路由器通告
+	（Router Advertisement）中收到的前缀自动生成地址时，可使用此选项。
+
+	可选值及其效果如下：
+
+	0
+		所有接口均禁用 IPv6 地址自动配置。
+
+		仅添加 IPv6 回环地址（::1）与链路本地地址。
+
+	1
+		所有接口均启用 IPv6 地址自动配置。
+
+		这是默认值。
+
+disable_ipv6
+
+	指定是否在所有接口上禁用 IPv6。
+	当不需要任何 IPv6 地址时，可使用此选项。
+
+	可选值及其效果如下：
+
+	0
+		在所有接口上启用 IPv6。
+
+		这是默认值。
+
+	1
+		在所有接口上禁用 IPv6。
+
+		接口不会添加 IPv6 地址。
diff --git a/Documentation/translations/zh_CN/networking/secid.rst b/Documentation/translations/zh_CN/networking/secid.rst
new file mode 100644
index 000000000000..94d9e7fb5d13
--- /dev/null
+++ b/Documentation/translations/zh_CN/networking/secid.rst
@@ -0,0 +1,24 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: Documentation/networking/secid.rst
+
+:翻译:
+
+	陈思为 Siwei Chen <businiaoanka@anka1.top>
+
+=================
+LSM/SeLinux secid
+=================
+
+flowi 结构体：
+
+flowi 结构体中的 secid 成员在 LSM（如 SELinux）中用于表示该流的标签。
+该流的标签目前用于选择相匹配的带标签 xfrm。
+
+若为出向流，标签派生自套接字（若有）；如果该流是为响应某个入站报文而生成的，
+则标签派生自相应的入站报文（例如 TCP 复位、timewait ACK 等）。
+在特殊情况下，也可酌情让标签派生自其他来源，如进程上下文、设备等。
+
+若为入向流，标签派生自报文所使用的 IPSec 安全关联（若存在）。
diff --git a/Documentation/translations/zh_CN/networking/sriov.rst b/Documentation/translations/zh_CN/networking/sriov.rst
new file mode 100644
index 000000000000..d5e16a099b07
--- /dev/null
+++ b/Documentation/translations/zh_CN/networking/sriov.rst
@@ -0,0 +1,34 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: Documentation/networking/sriov.rst
+
+:翻译:
+
+	陈思为 Siwei Chen <businiaoanka@anka1.top>
+
+===============
+网卡 SR-IOV API
+===============
+
+强烈建议现代网卡专注于实现 ``switchdev`` 模型
+（参见 `以太网交换机设备驱动模型（switchdev）`_）
+来配置 SR-IOV 功能的转发与安全。
+
+传统 API
+========
+
+旧的 SR-IOV API 在 ``rtnetlink`` Netlink 协议族中实现，是 ``RTM_GETLINK`` 和
+``RTM_SETLINK`` 命令的一部分。在驱动侧，它由若干 ``ndo_set_vf_*`` 和
+``ndo_get_vf_*`` 回调组成。
+
+由于传统 API 与协议栈其余部分集成不佳，该 API 被视为已冻结；不再接受任何新功能或扩展。
+新驱动不应实现那些不常用的回调；
+即以下回调禁止使用：
+
+ - ``ndo_get_vf_port``
+ - ``ndo_set_vf_port``
+ - ``ndo_set_vf_rss_query_en``
+
+.. _`以太网交换机设备驱动模型（switchdev）`: https://docs.kernel.org/networking/switchdev.html#switchdev
diff --git a/Documentation/translations/zh_CN/networking/team.rst b/Documentation/translations/zh_CN/networking/team.rst
new file mode 100644
index 000000000000..e6cf19a245a1
--- /dev/null
+++ b/Documentation/translations/zh_CN/networking/team.rst
@@ -0,0 +1,16 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: Documentation/networking/team.rst
+
+:翻译:
+
+	陈思为 Siwei Chen <businiaoanka@anka1.top>
+
+====================
+Team（网络接口聚合）
+====================
+
+Team 设备由用户空间通过 libteam 库驱动，该库位于：
+	https://github.com/jpirko/libteam
diff --git a/Documentation/translations/zh_CN/process/applying-patches.rst b/Documentation/translations/zh_CN/process/applying-patches.rst
new file mode 100644
index 000000000000..c056b241b0cd
--- /dev/null
+++ b/Documentation/translations/zh_CN/process/applying-patches.rst
@@ -0,0 +1,390 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: Documentation/process/applying-patches.rst
+
+:翻译:
+
+ 袁维杰 Weijie Yuan <wy@wyuan.org>
+
+将补丁应用到 Linux 内核
++++++++++++++++++++++++
+
+原文作者：
+	Jesper Juhl，2005 年 8 月
+
+.. note::
+
+   本文档已经过时。绝大多数情况下，你几乎肯定应该考虑使用 Git，而不是
+   手工运行 ``patch``。
+
+Linux 内核邮件列表中经常有人询问如何给内核打补丁；更确切地说，为众多
+内核树或分支之一制作的补丁，应当以哪个版本的内核为基础来应用。希望本文
+能够解答这些问题。
+
+除了说明如何应用和撤销补丁，本文还会简要介绍不同的内核树，并举例说明
+如何应用各个内核树特有的补丁。
+
+
+什么是补丁？
+============
+
+补丁是一份短小的文本文档，其中记录了源码树两个不同版本之间的改动。
+补丁由 ``diff`` 程序生成。
+
+要正确应用补丁，你必须知道它是基于哪个版本生成的，又会把源码树更新成
+哪个版本。这两项信息应当记录在补丁文件的元数据中，或者能够根据文件名
+推断出来。
+
+
+如何应用或撤销补丁？
+====================
+
+使用 ``patch`` 程序应用补丁。patch 程序读取 diff 文件（也称补丁
+文件），再按照文件中的描述修改源码树。
+
+Linux 内核补丁以存放内核源码目录的父目录为基准生成。
+
+因此，补丁文件中的路径会带有生成补丁时所用的内核源码目录名（也可能是
+“a/”和“b/”之类的其他目录名）。
+
+这个目录名一般不会恰好与本机的内核源码目录名相同（不过，它往往有助于
+判断未注明版本的补丁是基于哪个版本生成的）。应用补丁时，应先进入内核
+源码目录，再去掉补丁文件所列路径中的第一个组成部分（``patch`` 的
+``-p1`` 参数正是用于此目的）。
+
+要撤销先前应用的补丁，请给 patch 加上 -R 参数。也就是说，如果应用
+补丁时执行的是::
+
+	patch -p1 < ../patch-x.y.z
+
+那么可以这样撤销它::
+
+	patch -R -p1 < ../patch-x.y.z
+
+
+如何把补丁或 diff 文件交给 ``patch``？
+======================================
+
+和 Linux 及其他类 UNIX 操作系统中的许多操作一样，这件事也有好几种
+做法。
+
+下文的所有示例都使用如下语法，通过标准输入（stdin）把未压缩的文件
+交给 patch::
+
+	patch -p1 < path/to/patch-x.y.z
+
+如果你只想照着下文的示例操作，无意了解 patch 的其他用法，那么读到
+这里就可以跳过本节余下的内容。
+
+patch 也能通过 -i 参数取得待处理文件的名称，例如::
+
+	patch -p1 -i path/to/patch-x.y.z
+
+如果补丁文件以 gzip 或 xz 格式压缩，而你不想先解压再应用，可以这样
+把它交给 patch::
+
+	xzcat path/to/patch-x.y.z.xz | patch -p1
+	bzcat path/to/patch-x.y.z.gz | patch -p1
+
+如果想在应用前手工解压补丁文件（下文的示例均假定你已经这样做了），
+只需对文件运行 gunzip 或 xz，例如::
+
+	gunzip patch-x.y.z.gz
+	xz -d patch-x.y.z.xz
+
+执行后会留下一个纯文本的 patch-x.y.z 文件。你可以按自己的喜好，
+通过标准输入或 ``-i`` 参数把它交给 patch。
+
+patch 还有几个很实用的参数：``-s`` 会让 patch 除错误外不输出任何
+信息，以免错误信息很快滚出屏幕；``--dry-run`` 只列出将会发生的事情，
+并不实际修改文件；最后，``--verbose`` 会让 patch 输出更详细的处理
+信息。
+
+
+应用补丁时的常见错误
+====================
+
+应用补丁文件时，patch 会用多种方式检查文件是否合理。
+
+例如，patch 会检查文件是否像一个有效的补丁文件，也会检查待修改代码
+周围的内容是否与补丁提供的上下文相符。这只是它所做的两项基本检查。
+
+如果遇到不太对劲的地方，patch 有两种选择：拒绝应用改动并中止，或者
+稍作调整，设法把补丁应用上去。
+
+patch 会尝试调整的一种情况是：上下文和待修改的行全都匹配，只有行号
+不同。例如，补丁要修改文件中部的内容，但文件开头附近由于某种原因增删
+了几行，就会出现这种情况。此时所有内容其实都能对上，只是整体向前或
+向后移动了一些，patch 通常会相应调整行号并应用补丁。
+
+每当 patch 必须略作调整才能匹配时，它会提示补丁是在经过模糊匹配
+（**fuzz**）后应用的。你应当谨慎对待这样的改动：patch 很可能处理
+正确，但它并不保证每次都能正确处理，有时会得到错误的结果。
+
+如果某项改动无法通过模糊匹配调整，patch 会直接拒绝这项改动，并留下
+一个扩展名为 ``.rej`` 的文件（拒绝文件）。你可以阅读这个文件，准确
+了解哪项改动未能应用，再视需要手工处理。
+
+假如内核源码中没有第三方补丁，只有来自 kernel.org 的补丁，而且补丁
+应用顺序正确，源码文件也没有经过自行修改，那么 patch 绝不应报告模糊
+匹配或拒绝应用。如果还是看到这类信息，你的本地源码树或补丁文件很可能
+已经损坏。此时应先尝试重新下载补丁；如果问题依旧，建议从 kernel.org
+重新下载完整的全新源码树，从头再来。
+
+下面进一步看看 patch 可能输出的几种信息。
+
+如果 patch 停下来并显示 ``File to patch:`` 提示，说明它找不到待修改
+的文件。最可能的原因是你忘记指定 -p1，或者当前目录不对。偶尔也会
+遇到必须用 ``-p0`` 而不是 ``-p1`` 应用的补丁（查看补丁文件便能判断
+是否如此；如果确实如此，是补丁制作者犯了错，但并不致命）。
+
+如果看到 ``Hunk #2 succeeded at 1887 with fuzz 2 (offset 7 lines).``
+或类似信息，说明 patch 必须调整改动的位置才能应用；在这个例子中，
+实际改动位置必须与预期位置相差 7 行才能匹配。
+
+最终得到的文件可能正确，也可能不正确，取决于文件为何与预期不符。
+
+尝试应用一个基于其他内核版本生成的补丁时，经常会出现这种情况。
+
+如果看到 ``Hunk #3 FAILED at 2387.`` 之类的信息，说明补丁未能正确
+应用，patch 程序也无法通过模糊匹配完成应用。此时会生成一个 ``.rej``
+文件，其中包含导致应用失败的改动；还会生成一个 ``.orig`` 文件，其中
+是未能修改的原始内容。
+
+如果看到 ``Reversed (or previously applied) patch detected!  Assume
+-R? [n]``，说明 patch 检测到补丁中的改动似乎已经存在。
+
+如果你确实已经应用过这个补丁，只是不慎又应用了一次，请回答 [n]o 并
+中止应用。如果先前应用过补丁，现在本来就想撤销它，只是忘了指定 -R，
+则可以在这里回答 [**y**]es，让 patch 替你撤销。
+
+如果补丁制作者在生成补丁时颠倒了源目录和目标目录，也会出现这条信息；
+在这种情况下，撤销补丁实际上才是在应用补丁。
+
+``patch: **** unexpected end of file in patch`` 或 ``patch unexpectedly
+ends in middle of line`` 之类的信息，表示 patch 无法理解收到的文件。
+可能是文件下载不完整，可能是你没有先解压便把压缩补丁交给了 patch，
+也可能是补丁文件在途经某个邮件客户端或邮件传输代理时遭到破坏，例如
+一行过长的内容被拆成了两行。这类警告通常很容易处理，只需把被拆开的
+两行重新连接（拼接）起来即可。
+
+如前所述，如果把 kernel.org 提供的补丁应用到版本正确、未经修改的
+源码树上，这些错误绝不应出现。因此，如果应用 kernel.org 的补丁时
+遇到这些错误，应当认为补丁文件或源码树已经损坏；建议重新下载完整的
+内核源码树和要应用的补丁，从头再来。
+
+
+除了 ``patch``，还有其他选择吗？
+================================
+
+有。
+
+可以使用 ``interdiff`` 程序（http://cyberelk.net/tim/patchutils/），
+为两个补丁之间的差异生成一个补丁，然后应用生成的补丁。
+
+这样便能一步从 5.7.2 更新到 5.7.3。interdiff 的 -z 参数甚至允许
+直接传入以 gzip 或 bzip2 格式压缩的补丁，无需使用 zcat、bzcat，也
+无需手工解压。
+
+下面是一步从 5.7.2 更新到 5.7.3 的方法::
+
+	interdiff -z ../patch-5.7.2.gz ../patch-5.7.3.gz | patch -p1
+
+尽管 interdiff 能省去一两个步骤，一般仍建议按常规方法多执行这些步骤，
+因为 interdiff 在某些情况下可能产生错误结果。
+
+另一个选择是 ``ketchup``。它是一个自动下载并应用补丁的 Python 脚本
+（https://www.selenic.com/ketchup/）。
+
+其他好用的工具还有：diffstat，用于显示补丁改动的摘要；lsdiff，用于
+简要列出补丁文件影响的文件，还可以选择同时显示各段补丁的起始行号；
+grepdiff，用于在补丁中查找与指定正则表达式匹配的内容，并列出这些内容
+所在的文件。
+
+
+可以从哪里下载补丁？
+====================
+
+补丁可从 https://kernel.org/ 获取。网站首页提供了最新补丁的链接，
+各类补丁也有各自固定的存放位置。
+
+5.x.y（-stable）补丁和 5.x 补丁位于
+
+	https://www.kernel.org/pub/linux/kernel/v5.x/
+
+5.x.y 增量补丁位于
+
+	https://www.kernel.org/pub/linux/kernel/v5.x/incr/
+
+-rc 补丁并不存放在 Web 服务器上，而是根据下面这样的 git 标签按需
+生成
+
+	https://git.kernel.org/torvalds/p/v5.1-rc1/v5.0
+
+稳定版的 -rc 补丁位于
+
+	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/
+
+
+5.x 内核
+========
+
+这些是 Linus 发布的基础稳定版本，其中版本号最大者最新。
+
+如果发现回归或其他严重缺陷，会在这个基础版本之上发布 -stable 修复
+补丁（见下文）。每当新的 5.x 基础内核发布时，还会提供一个补丁，用来
+表示上一个 5.x 内核与新内核之间的差异。
+
+要应用从 5.6 更新到 5.7 的补丁，可以按下面的步骤操作。请注意，这类
+补丁**不能**应用到 5.x.y 内核之上，只能应用到基础 5.x 内核之上；
+如果要从 5.x.y 更新到 5.x+1，必须先撤销 5.x.y 补丁。
+
+下面是两个示例::
+
+	# 从 5.6 更新到 5.7
+
+	$ cd ~/linux-5.6		# 进入内核源码目录
+	$ patch -p1 < ../patch-5.7	# 应用 5.7 补丁
+	$ cd ..
+	$ mv linux-5.6 linux-5.7	# 重命名源码目录
+
+	# 从 5.6.1 更新到 5.7
+
+	$ cd ~/linux-5.6.1		# 进入内核源码目录
+	$ patch -p1 -R < ../patch-5.6.1	# 撤销 5.6.1 补丁
+					# 源码目录现在是 5.6
+	$ patch -p1 < ../patch-5.7	# 应用新的 5.7 补丁
+	$ cd ..
+	$ mv linux-5.6.1 linux-5.7	# 重命名源码目录
+
+
+5.x.y 内核
+==========
+
+版本号由三段数字组成的是 -stable 内核。它们包含规模较小但至关重要的
+修复，用于解决某个 5.x 内核中发现的安全问题或严重回归。
+
+对于想使用最新的稳定内核，又无意帮助测试开发版或实验版的用户，推荐
+选择这个分支。
+
+如果没有 5.x.y 内核可用，则版本号最大的 5.x 内核就是当前稳定内核。
+
+-stable 团队既提供普通补丁，也提供增量补丁。下面说明如何应用这两类
+补丁。
+
+普通补丁
+~~~~~~~~
+
+这类补丁不是增量补丁。例如，5.7.3 补丁不能应用到 5.7.2 内核源码
+之上，而应应用到基础 5.7 内核源码之上。
+
+因此，要把 5.7.3 补丁应用到现有的 5.7.2 内核源码，必须先撤销
+5.7.2 补丁（回到基础 5.7 内核源码），再应用新的 5.7.3 补丁。
+
+下面是一个简单的示例::
+
+	$ cd ~/linux-5.7.2		# 进入内核源码目录
+	$ patch -p1 -R < ../patch-5.7.2	# 撤销 5.7.2 补丁
+	$ patch -p1 < ../patch-5.7.3	# 应用新的 5.7.3 补丁
+	$ cd ..
+	$ mv linux-5.7.2 linux-5.7.3	# 重命名内核源码目录
+
+增量补丁
+~~~~~~~~
+
+增量补丁则不同：它们不应用到基础 5.x 内核之上，而应用到前一个稳定版
+内核（5.x.y-1）之上。
+
+下面是应用增量补丁的示例::
+
+	$ cd ~/linux-5.7.2		# 进入内核源码目录
+	$ patch -p1 < ../patch-5.7.2-3	# 应用新的 5.7.3 补丁
+	$ cd ..
+	$ mv linux-5.7.2 linux-5.7.3	# 重命名内核源码目录
+
+
+-rc 内核
+========
+
+这些是候选发布版内核。每当 Linus 认为当前的 git 树（git 是内核的
+源码管理工具）处于相当合理、足以测试的状态时，就会发布这样的开发版内核。
+
+这些内核并不稳定；如果打算运行，就要预料到它们偶尔会出故障。不过，
+在几个主要开发分支中，这是最稳定的一个，而且它最终会成为下一个稳定版
+内核，所以让尽可能多的人参与测试十分重要。
+
+如果你想帮助测试开发版内核，但不想运行真正具有实验性的内容，这个分支
+很合适（有关真正实验性的内容，请参阅下文介绍 -next 和 -mm 内核的
+章节）。
+
+-rc 补丁不是增量补丁；与上文介绍的 5.x.y 补丁一样，它们应用到基础
+5.x 内核之上。-rcN 后缀前面的内核版本号，表示这个 -rc 内核最终会
+成为哪个版本。
+
+因此，5.8-rc5 表示它是 5.8 内核的第五个候选发布版，这个补丁应当
+应用到 5.7 内核源码之上。
+
+下面是三个应用这类补丁的示例::
+
+	# 第一个示例：从 5.7 更新到 5.8-rc3
+
+	$ cd ~/linux-5.7			# 进入 5.7 源码目录
+	$ patch -p1 < ../patch-5.8-rc3		# 应用 5.8-rc3 补丁
+	$ cd ..
+	$ mv linux-5.7 linux-5.8-rc3		# 重命名源码目录
+
+	# 接着从 5.8-rc3 更新到 5.8-rc5
+
+	$ cd ~/linux-5.8-rc3			# 进入 5.8-rc3 目录
+	$ patch -p1 -R < ../patch-5.8-rc3	# 撤销 5.8-rc3 补丁
+	$ patch -p1 < ../patch-5.8-rc5		# 应用新的 5.8-rc5 补丁
+	$ cd ..
+	$ mv linux-5.8-rc3 linux-5.8-rc5	# 重命名源码目录
+
+	# 最后尝试从 5.7.3 更新到 5.8-rc5
+
+	$ cd ~/linux-5.7.3			# 进入内核源码目录
+	$ patch -p1 -R < ../patch-5.7.3		# 撤销 5.7.3 补丁
+	$ patch -p1 < ../patch-5.8-rc5		# 应用新的 5.8-rc5 补丁
+	$ cd ..
+	$ mv linux-5.7.3 linux-5.8-rc5		# 重命名源码目录
+
+
+-mm 补丁与 linux-next 树
+========================
+
+-mm 补丁是 Andrew Morton 发布的实验性补丁。
+
+过去，-mm 树还用于测试子系统补丁；现在这项工作由
+`linux-next` （https://www.kernel.org/doc/man-pages/linux-next.html）
+树承担。子系统维护者先把补丁推送到 linux-next，再在合并窗口期间直接
+发送给 Linus。
+
+-mm 补丁是新功能和其他实验性补丁的试验场，这些补丁并未通过子系统树
+合并。一旦这类补丁在 -mm 中经受一段时间的检验并证明自身价值，Andrew
+就会将其提交给 Linus，以纳入主线。
+
+linux-next 树每天更新，其中包括 -mm 补丁。二者始终处于变化之中，
+含有许多实验性功能、大量不适合主线的调试补丁等，是本文所述各分支中
+实验性最强的。
+
+这些补丁不适合用在必须保持稳定的系统上，运行它们的风险高于其他任何
+分支（务必备有最新的备份；运行任何实验性内核都应如此，运行 -mm 补丁
+或 linux-next 树中的内核时尤其如此）。
+
+我们非常欢迎大家测试 -mm 补丁和 linux-next，因为测试的意义就是在改动
+合入更稳定的 Linus 主线树之前，排查并消除回归、崩溃、数据损坏缺陷、
+构建失败以及其他各种缺陷。
+
+不过，-mm 和 linux-next 的测试者必须明白，这些树发生故障的频率高于
+其他任何内核树。
+
+
+至此，各种内核树已经介绍完毕。希望你现在已经清楚如何应用各类补丁，
+并能帮助测试内核。
+
+感谢 Randy Dunlap、Rolf Eike Beer、Linus Torvalds、Bodo Eggert、
+Johannes Stezenbach、Grant Coady、Pavel Machek，以及其他可能被我
+遗漏的人，感谢他们对本文档的审阅和贡献。
diff --git a/Documentation/translations/zh_CN/process/howto.rst b/Documentation/translations/zh_CN/process/howto.rst
index cc47be356dd3..89af3f8f6e2b 100644
--- a/Documentation/translations/zh_CN/process/howto.rst
+++ b/Documentation/translations/zh_CN/process/howto.rst
@@ -142,7 +142,7 @@ Linux内核代码中包含有大量的文档。这些文档对于学习如何与
     有助于内核开发的外部文档列表。如果你在内核自带的文档中没有找到你想找
     的内容，可以查看这些文档。
 
-  :ref:`Documentation/process/applying-patches.rst <applying_patches>`
+  :doc:`Documentation/translations/zh_CN/process/applying-patches.rst <applying-patches>`
     关于补丁是什么以及如何将它打在不同内核开发分支上的好介绍
 
 内核还拥有大量从代码自动生成或者从 ReStructuredText(ReST) 标记生成的文档，
diff --git a/Documentation/translations/zh_CN/process/index.rst b/Documentation/translations/zh_CN/process/index.rst
index 3bcb3bdaf533..3a36ca7d9333 100644
--- a/Documentation/translations/zh_CN/process/index.rst
+++ b/Documentation/translations/zh_CN/process/index.rst
@@ -82,13 +82,13 @@ TODOLIST:
    :maxdepth: 1
 
    magic-number
+   applying-patches
    volatile-considered-harmful
    ../arch/riscv/patch-acceptance
    ../core-api/unaligned-memory-access
 
 TODOLIST:
 
-* applying-patches
 * backporting
 * adding-syscalls
 * botching-up-ioctls
diff --git a/Documentation/translations/zh_TW/glossary.rst b/Documentation/translations/zh_TW/glossary.rst
new file mode 100644
index 000000000000..15ed1be54416
--- /dev/null
+++ b/Documentation/translations/zh_TW/glossary.rst
@@ -0,0 +1,168 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _tw_glossary:
+
+術語表
+======
+
+:作者: 葉宸佑 Chen-Yu Yeh <chenyou910331@gmail.com>
+
+本術語表列出Linux核心繁體中文（zh_TW）翻譯所使用的術語。zh_TW翻譯以臺灣
+慣用的資訊術語為準。新增或更新翻譯時，請依照本表選擇用詞，以維持整個
+zh_TW文件樹的一致性；若遇到本表未收錄的術語，歡迎提交補丁補充。
+
+下表同時列出常見的簡體中文（zh_CN）譯法，方便從zh_CN翻譯轉換或對照時
+使用。本表的zh_CN欄位為對照參考，其用詞經核對核心文件樹zh_CN譯文中的
+實際用法，非引用外部術語表。
+
+一般術語
+--------
+
+========================  ==========================  ====================
+英文                      zh_TW                       zh_CN（對照）
+========================  ==========================  ====================
+kernel                    核心                        内核
+user / user space         使用者／使用者空間          用户／用户空间
+software / hardware       軟體／硬體                  软件／硬件
+firmware                  韌體                        固件
+operating system          作業系統                    操作系统
+distribution              發行版                      发行版
+community                 社群                        社区
+project                   專案                        项目
+documentation             文件                        文档
+file                      檔案                        文件
+folder / directory        資料夾／目錄                文件夹／目录
+default                   預設                        默认／缺省
+support                   支援                        支持
+information               資訊                        信息
+message                   訊息                        消息
+data                      資料                        数据
+quality                   品質                        质量
+performance               效能                        性能
+network                   網路                        网络
+the Internet              網際網路                    因特网
+server                    伺服器                      服务器
+digital                   數位                        数字
+computer                  電腦                        计算机
+integrate                 整合                        集成
+create                    建立                        创建
+access                    存取                        访问
+via / through             透過                        通过
+========================  ==========================  ====================
+
+程式設計術語
+------------
+
+========================  ==========================  ====================
+英文                      zh_TW                       zh_CN（對照）
+========================  ==========================  ====================
+source code               原始程式碼／原始碼          源代码
+code                      程式碼                      代码
+program                   程式                        程序
+process                   行程                        进程
+thread                    執行緒                      线程
+scheduler / schedule      排程器／排程                调度器／调度
+queue                     佇列                        队列
+memory                    記憶體                      内存
+cache                     快取                        缓存
+interface                 介面                        接口
+port                      埠                          端口
+register                  暫存器                      寄存器
+stack                     堆疊                        堆栈
+function                  函式                        函数
+function call             呼叫                        调用
+callback                  回呼                        回调
+return value              回傳值                      返回值
+macro                     巨集                        宏
+enum                      列舉                        枚举
+variable                  變數                        变量
+pointer                   指標                        指针
+array                     陣列                        数组
+linked list               鏈結串列                    链表
+loop                      迴圈                        循环
+declaration               宣告                        声明
+identifier                識別字                      标识符
+character / string        字元／字串                  字符／字符串
+byte                      位元組                      字节
+boolean                   布林                        布尔
+binary                    二進位                      二进制
+object                    物件                        对象
+type                      型別／類型                  类型
+module                    模組                        模块
+component                 元件                        组件
+build                     建置                        构建
+compile / assembler       編譯／組譯器                编译／汇编器
+debug                     除錯                        调试
+optimize                  最佳化                      优化
+implement                 實作                        实现
+global / local            全域／區域                  全局／局部
+constant                  常數                        常量
+comment (in code)         註解                        注释
+indentation               縮排                        缩进
+inline                    行內                        内联
+generate                  產生                        生成
+load / loader             載入／載入器                加载／加载器
+export / import           匯出／匯入                  导出／导入
+link / linker             連結／連結器                链接／链接器
+repository                儲存庫                      存储库／仓库
+distributed               分散式                      分布式
+header file               標頭檔                      头文件
+configuration file        設定檔                      配置文件
+file system               檔案系統                    文件系统
+settings / configuration  設定                        设置／配置
+========================  ==========================  ====================
+
+介面與其他術語
+--------------
+
+========================  ==========================  ====================
+英文                      zh_TW                       zh_CN（對照）
+========================  ==========================  ====================
+menu                      選單                        菜单
+window                    視窗                        窗口
+toolbar                   工具列                      工具栏
+field                     欄位                        字段
+icon                      圖示                        图标
+mouse / cursor            滑鼠／游標                  鼠标／光标
+paste                     貼上                        粘贴
+print / printer           列印／印表機                打印／打印机
+disk (hard disk)          磁碟（硬碟）                磁盘（硬盘）
+text / plain text         文字／純文字                文本／纯文本
+mailbox                   信箱                        邮箱
+account                   帳戶／帳號                  帐户
+tracking                  追蹤                        跟踪
+advanced                  進階                        高级
+free software             自由軟體                    自由软件／免费软件
+========================  ==========================  ====================
+
+特定用語說明
+------------
+
+- **access 與 visit**：access（資料、記憶體、資源的存取）譯為「存取」；
+  visit（造訪網站、頁面或連結）譯為「造訪」。兩者在 zh_CN 皆作「訪問」，
+  zh_TW 依語意區分。
+
+- **Fellow**：現有翻譯將 Linux Foundation Fellow 譯為「院士」。「院士」在
+  臺灣多指中央研究院等學術機構的頭銜，「研究員」也不完全對等，實務上亦常
+  直接保留英文。此譯法尚在討論中，暫維持現有譯法，待社群取得共識後再統一。
+
+- **mailing list**：譯為「郵件列表」（zh_CN 亦作「邮件列表」）。
+
+- **-stable 與穩定版**：核心的 ``-stable`` 樹保留英文原名 ``-stable``；泛指
+  時譯為「穩定版核心」。既有翻譯中「穩定版」與 ``-stable`` 混用者不強制
+  統一，新增或更新的翻譯請套用此慣例。
+
+用字慣例
+--------
+
+除術語之外，zh_TW翻譯採用臺灣標準用字，例如「為」（不用「爲」）、「裡」
+（不用「裏」）、「著」（不用「着」）、「才」（不用「纔」）、「啟」（不用
+「啓」）、「只」（不用「隻」）與「發布」（不用「發佈」）。
+
+標點符號沿用現有文件樹的全形標點。每行寬度沿用原文慣例（每行約75個半形
+字元寬）。
+
+中文與英文、數字相鄰時不加空格，例如「Linux核心」而非「Linux 核心」；此為
+現有zh_TW文件樹的主要慣例。本規則適用於新增的翻譯與改寫過的段落，既有檔案
+不另行回頭修改。行內標記（``literal``、:ref: 等）前後仍依reStructuredText
+的需要保留必要的空白。
diff --git a/Documentation/translations/zh_TW/index.rst b/Documentation/translations/zh_TW/index.rst
index 660a74d2023c..95809012a9ef 100644
--- a/Documentation/translations/zh_TW/index.rst
+++ b/Documentation/translations/zh_TW/index.rst
@@ -119,9 +119,10 @@ TODOList:
 術語表
 ------
 
-TODOList:
+.. toctree::
+   :maxdepth: 1
 
-* glossary
+   glossary
 
 
 索引和表格
diff --git a/Documentation/translations/zh_TW/process/1.Intro.rst b/Documentation/translations/zh_TW/process/1.Intro.rst
index 345c4cbe9b55..2639ab99793f 100644
--- a/Documentation/translations/zh_TW/process/1.Intro.rst
+++ b/Documentation/translations/zh_TW/process/1.Intro.rst
@@ -12,6 +12,7 @@
 
  吳想成 Wu XiangCheng <bobwxc@email.cn>
  胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
+ 葉宸佑 Chen-Yu Yeh <chenyou910331@gmail.com>
 
 .. _tw_development_process_intro:
 
@@ -21,179 +22,183 @@
 內容提要
 --------
 
-本節的其餘部分涵蓋了內核開發的過程，以及開發人員及其僱主在這方面可能遇到的
-各種問題。有很多原因使內核代碼應被合併到正式的（“主線”）內核中，包括對用戶
-的自動可用性、多種形式的社區支持以及影響內核開發方向的能力。提供給Linux內核
-的代碼必須在與GPL兼容的許可證下可用。
+本節的其餘部分涵蓋了核心開發的過程，以及開發人員及其僱主在這方面可能遇到的
+各種問題。有很多原因使核心程式碼應被合併到正式的（“主線”）核心中，包括對使用者
+的自動可用性、多種形式的社群支援以及影響核心開發方向的能力。提供給Linux核心
+的程式碼必須在與GPL相容的許可證下可用。
 
-:ref:`tw_development_process` 介紹了開發過程、內核發佈週期和合並窗口的機制。
-涵蓋了補丁開發、審查和合並週期中的各個階段。還有一些關於工具和郵件列表的討論？
-鼓勵希望開始內核開發的開發人員跟蹤並修復缺陷以作爲初步練習。
+:ref:`tw_development_process` 介紹了開發過程、核心發布週期和合併視窗的機制。
+涵蓋了補丁開發、審查和合併週期中的各個階段。還有一些關於工具和郵件列表的討論。
+鼓勵希望開始核心開發的開發人員追蹤並修復缺陷以作為初步練習。
 
 
-:ref:`tw_development_early_stage` 包括項目的早期規劃，重點是儘快讓開發社區
+:ref:`tw_development_early_stage` 包括專案的早期規劃，重點是儘快讓開發社群
 參與進來。
 
-:ref:`tw_development_coding` 是關於編程過程的；介紹了其他開發人員遇到的幾個
-陷阱。也涵蓋了對補丁的一些要求，並且介紹了一些工具，這些工具有助於確保內核
+:ref:`tw_development_coding` 是關於程式設計過程的；介紹了其他開發人員遇到的幾個
+陷阱。也涵蓋了對補丁的一些要求，並且介紹了一些工具，這些工具有助於確保核心
 補丁是正確的。
 
-:ref:`tw_development_posting` 描述發佈補丁以供評審的過程。爲了讓開發社區能
+:ref:`tw_development_posting` 描述發布補丁以供評審的過程。為了讓開發社群能
 認真對待，補丁必須被正確格式化和描述，並且必須發送到正確的地方。遵循本節中的
 建議有助於確保您的工作能被較好地接納。
 
-:ref:`tw_development_followthrough` 介紹了發佈補丁之後發生的事情；工作在這時
+:ref:`tw_development_followthrough` 介紹了發布補丁之後發生的事情；工作在這時
 還遠遠沒有完成。與審閱者一起工作是開發過程中的一個重要部分；本節提供了一些
 關於如何在這個重要階段避免問題的提示。當補丁被合併到主線中時，開發人員要注意
 不要假定任務已經完成。
 
-:ref:`tw_development_advancedtopics` 介紹了兩個“高級”主題：使用Git管理補丁
-和查看其他人發佈的補丁。
+:ref:`tw_development_advancedtopics` 介紹了兩個“進階”主題：使用Git管理補丁
+和查看其他人發布的補丁。
 
-:ref:`tw_development_conclusion` 總結了有關內核開發的更多信息，附帶有相關資源
-鏈接。
+:ref:`tw_development_conclusion` 總結了有關核心開發的更多資訊，附帶有相關資源
+連結。
 
-這個文檔是關於什麼的
+這個文件是關於什麼的
 --------------------
 
-Linux內核有超過800萬行代碼，每個版本的貢獻者超過1000人，是現存最大、最活躍的
-免費軟件項目之一。從1991年開始，這個內核已經發展成爲一個最好的操作系統組件，
-運行在袖珍數字音樂播放器、臺式電腦、現存最大的超級計算機以及所有類型的系統上。
-它是一種適用於幾乎任何情況的健壯、高效和可擴展的解決方案。
-
-隨着Linux的發展，希望參與其開發的開發人員（和公司）的數量也在增加。硬件供應商
-希望確保Linux能夠很好地支持他們的產品，使這些產品對Linux用戶具有吸引力。嵌入
-式系統供應商使用Linux作爲集成產品的組件，希望Linux能夠儘可能地勝任手頭的任務。
-分銷商和其他基於Linux的軟件供應商切實關心Linux內核的功能、性能和可靠性。最終
-用戶也常常希望修改Linux，使之能更好地滿足他們的需求。
-
-Linux最引人注目的特性之一是這些開發人員可以訪問它；任何具備必要技能的人都可以
-改進Linux並影響其開發方向。專有產品不能提供這種開放性，這是自由軟件的一個特點。
-如果有什麼不同的話，那就是內核比大多數其他自由軟件項目更開放。一個典型的三個
-月內核開發週期可以涉及1000多個開發人員，他們爲100多個不同的公司（或者根本不
-隸屬公司）工作。
-
-與內核開發社區合作並不是特別困難。但儘管如此，仍有許多潛在的貢獻者在嘗試做
-內核工作時遇到了困難。內核社區已經發展出自己獨特的操作方式，使其能夠在每天
-都要更改數千行代碼的環境中順利運行（並生成高質量的產品）。因此，Linux內核開發
-過程與專有的開發模式有很大的不同也就不足爲奇了。
-
-對於新開發人員來說，內核的開發過程可能會讓人感到奇怪和恐懼，但這背後有充分的
-理由和堅實的經驗。一個不瞭解內核社區工作方式的開發人員（或者更糟的是，他們
-試圖拋棄或規避之）會得到令人沮喪的體驗。開發社區在幫助那些試圖學習的人的同時，
+Linux核心有超過800萬行程式碼，每個版本的貢獻者超過1000人，是現存最大、最活躍的
+自由軟體專案之一。從1991年開始，這個核心已經發展成為一個最好的作業系統元件，
+執行在袖珍數位音樂播放器、桌上型電腦、現存最大的超級電腦以及所有類型的系統上。
+它是一種適用於幾乎任何情況的強健、高效和可擴展的解決方案。
+
+隨著Linux的發展，希望參與其開發的開發人員（和公司）的數量也在增加。硬體供應商
+希望確保Linux能夠很好地支援他們的產品，使這些產品對Linux使用者具有吸引力。嵌入
+式系統供應商使用Linux作為整合產品的元件，希望Linux能夠儘可能地勝任手頭的任務。
+分銷商和其他基於Linux的軟體供應商切實關心Linux核心的功能、效能和可靠性。最終
+使用者也常常希望修改Linux，使之能更好地滿足他們的需求。
+
+Linux最引人注目的特性之一是這些開發人員可以存取它；任何具備必要技能的人都
+可以改進Linux並影響其開發方向。專有產品不能提供這種開放性，這是自由軟體的
+一個特點。如果有什麼不同的話，那就是核心比大多數其他自由軟體專案更開放。一
+個典型的三個月核心開發週期可以涉及1000多個開發人員，他們為100多個不同的公
+司（或者根本不隸屬公司）工作。
+
+與核心開發社群合作並不是特別困難。但儘管如此，仍有許多潛在的貢獻者在嘗試做
+核心工作時遇到了困難。核心社群已經發展出自己獨特的操作方式，使其能夠在每天
+都要更改數千行程式碼的環境中順利執行（並產生高品質的產品）。因此，Linux核
+心開發過程與專有的開發模式有很大的不同也就不足為奇了。
+
+對於新開發人員來說，核心的開發過程可能會讓人感到奇怪和恐懼，但這背後有充分的
+理由和堅實的經驗。一個不瞭解核心社群工作方式的開發人員（或者更糟的是，他們
+試圖拋棄或規避之）會得到令人沮喪的體驗。開發社群在幫助那些試圖學習的人的同時，
 沒有時間幫助那些不願意傾聽或不關心開發過程的人。
 
 希望閱讀本文的人能夠避免這種令人沮喪的經歷。這些材料很長，但閱讀它們時所做的
-努力會在短時間內得到回報。開發社區總是需要能讓內核變更好的開發人員；下面的
-文字應該幫助您或爲您工作的人員加入我們的社區。
+努力會在短時間內得到回報。開發社群總是需要能讓核心變更好的開發人員；下面的
+文字應該幫助您或為您工作的人員加入我們的社群。
 
 致謝
 ----
 
-本文檔由Jonathan Corbet <corbet@lwn.net> 撰寫。以下人員的建議使之更爲完善：
+本文件由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，他看到了這項工作
+這項工作得到了Linux基金會的支援，特別感謝Amanda McPherson，他看到了這項工作
 的價值並將其變成現實。
 
-代碼進入主線的重要性
---------------------
+程式碼進入主線的重要性
+----------------------
 
-有些公司和開發人員偶爾會想，爲什麼他們要費心學習如何與內核社區合作，並將代碼
-放入主線內核（“主線”是由Linus Torvalds維護的內核，Linux發行商將其用作基礎）。
-在短期內，貢獻代碼看起來像是一種可以避免的開銷；維護獨立代碼並直接支持用戶
-似乎更容易。事實上，保持代碼獨立（“樹外”）是在經濟上是錯誤的。
+有些公司和開發人員偶爾會想，為什麼他們要費心學習如何與核心社群合作，並將程
+式碼放入主線核心（“主線”是由Linus Torvalds維護的核心，Linux發行商將其用作
+基礎）。在短期內，貢獻程式碼看起來像是一種可以避免的開銷；維護獨立程式碼並
+直接支援使用者似乎更容易。事實上，保持程式碼獨立（“樹外”）是在經濟上是錯誤
+的。
 
-爲了說明樹外代碼成本，下面給出內核開發過程的一些相關方面；本文稍後將更詳細地
+為了說明樹外程式碼成本，下面給出核心開發過程的一些相關方面；本文稍後將更詳細地
 討論其中的大部分內容。請考慮：
 
-- 所有Linux用戶都可以使用合併到主線內核中的代碼。它將自動出現在所有啓用它的
-  發行版上。無需驅動程序磁盤、額外下載，也不需要爲多個發行版的多個版本提供
-  支持；這一切將方便所有開發人員和用戶。併入主線解決了大量的分發和支持問題。
+- 所有Linux使用者都可以使用合併到主線核心中的程式碼。它將自動出現在所有啟
+  用它的發行版上。無需驅動程式磁碟、額外下載，也不需要為多個發行版的多個版
+  本提供支援；這一切將方便所有開發人員和使用者。併入主線解決了大量的分發和
+  支援問題。
 
-- 當內核開發人員努力維護一個穩定的用戶空間接口時，內核內部API處於不斷變化之中。
-  不維持穩定的內部接口是一個慎重的設計決策；它允許在任何時候進行基本的改進，
-  併產出更高質量的代碼。但該策略導致結果是，若要使用新的內核，任何樹外代碼都
-  需要持續的維護。維護樹外代碼會需要大量的工作才能使代碼保持正常運行。
+- 當核心開發人員努力維護一個穩定的使用者空間介面時，核心內部API處於不斷變
+  化之中。不維持穩定的內部介面是一個慎重的設計決策；它允許在任何時候進行基
+  本的改進，並產出更高品質的程式碼。但該策略導致結果是，若要使用新的核心，
+  任何樹外程式碼都需要持續的維護。維護樹外程式碼會需要大量的工作才能使程式
+  碼保持正常執行。
 
-  相反，位於主線中的代碼不需要這樣做，因爲基本規則要求進行API更改的任何開發
-  人員也必須修復由於該更改而破壞的任何代碼。因此，合併到主線中的代碼大大降低
+  相反，位於主線中的程式碼不需要這樣做，因為基本規則要求進行API更改的任何開發
+  人員也必須修復由於該更改而破壞的任何程式碼。因此，合併到主線中的程式碼大大降低
   了維護成本。
 
-- 除此之外，內核中的代碼通常會被其他開發人員改進。您授權的用戶社區和客戶對您
-  產品的改進可能會令人驚喜。
+- 除此之外，核心中的程式碼通常會被其他開發人員改進。您授權的使用者社群和客
+  戶對您產品的改進可能會令人驚喜。
 
-- 內核代碼在合併到主線之前和之後都要經過審查。無論原始開發人員的技能有多強，
-  這個審查過程總是能找到改進代碼的方法。審查經常發現嚴重的錯誤和安全問題。
-  對於在封閉環境中開發的代碼尤其如此；這種代碼從外部開發人員的審查中獲益匪淺。
-  樹外代碼是低質量代碼。
+- 核心程式碼在合併到主線之前和之後都要經過審查。無論原始開發人員的技能有多
+  強，這個審查過程總是能找到改進程式碼的方法。審查經常發現嚴重的錯誤和安全
+  問題。對於在封閉環境中開發的程式碼尤其如此；這種程式碼從外部開發人員的審
+  查中獲益匪淺。樹外程式碼是低品質程式碼。
 
-- 參與開發過程是您影響內核開發方向的方式。旁觀者的抱怨會被聽到，但是活躍的
-  開發人員有更強的聲音——並且能夠實現使內核更好地滿足其需求的更改。
+- 參與開發過程是您影響核心開發方向的方式。旁觀者的抱怨會被聽到，但是活躍的
+  開發人員有更強的聲音——並且能夠實作使核心更好地滿足其需求的更改。
 
-- 當單獨維護代碼時，總是存在第三方爲類似功能提供不同實現的可能性。如果發生
-  這種情況，合併代碼將變得更加困難——甚至成爲不可能。之後，您將面臨以下令人
-  不快的選擇：（1）無限期地維護樹外的非標準特性，或（2）放棄代碼並將用戶遷移
-  到樹內版本。
+- 當單獨維護程式碼時，總是存在第三方為類似功能提供不同實作的可能性。如果發
+  生這種情況，合併程式碼將變得更加困難——甚至成為不可能。之後，您將面臨以下
+  令人不快的選擇：（1）無限期地維護樹外的非標準特性，或（2）放棄程式碼並將
+  使用者遷移到樹內版本。
 
-- 代碼的貢獻是使整個流程工作的根本。通過貢獻代碼，您可以向內核添加新功能，並
-  提供其他內核開發人員使用的功能和示例。如果您已經爲Linux開發了代碼（或者正在
-  考慮這樣做），那麼您顯然對這個平臺的持續成功感興趣；貢獻代碼是確保成功的
-  最好方法之一。
+- 程式碼的貢獻是使整個流程工作的根本。透過貢獻程式碼，您可以向核心添加新功
+  能，並提供其他核心開發人員使用的功能和範例。如果您已經為Linux開發了程式
+  碼（或者正在考慮這樣做），那麼您顯然對這個平臺的持續成功感興趣；貢獻程式
+  碼是確保成功的最好方法之一。
 
-上述所有理由都適用於任何樹外內核代碼，包括以專有的、僅二進制形式分發的代碼。
-然而，在考慮任何類型的純二進制內核代碼分佈之前，還需要考慮其他因素。包括：
+上述所有理由都適用於任何樹外核心程式碼，包括以專有的、僅二進位形式分發的程
+式碼。然而，在考慮任何類型的純二進位核心程式碼分發之前，還需要考慮其他因素。
+包括：
 
-- 圍繞專有內核模塊分發的法律問題其實較爲模糊；相當多的內核版權所有者認爲，
-  大多數僅二進制的模塊是內核的派生產品，因此，它們的分發違反了GNU通用公共
-  許可證（下面將詳細介紹）。本文作者不是律師，本文檔中的任何內容都不可能被
-  視爲法律建議。封閉源代碼模塊的真實法律地位只能由法院決定。但不管怎樣，困擾
-  這些模塊的不確定性仍然存在。
+- 圍繞專有核心模組分發的法律問題其實較為模糊；相當多的核心版權所有者認為，
+  大多數僅二進位的模組是核心的派生產品，因此，它們的分發違反了GNU通用公共
+  許可證（下面將詳細介紹）。本文作者不是律師，本文件中的任何內容都不可能被
+  視為法律建議。封閉原始程式碼模組的真實法律地位只能由法院決定。但不管怎樣，
+  困擾這些模組的不確定性仍然存在。
 
-- 二進制模塊大大增加了調試內核問題的難度，以至於大多數內核開發人員甚至都不會
-  嘗試。因此，只分發二進制模塊將使您的用戶更難從社區獲得支持。
+- 二進位模組大大增加了除錯核心問題的難度，以至於大多數核心開發人員甚至都不會
+  嘗試。因此，只分發二進位模組將使您的使用者更難從社群獲得支援。
 
-- 對於僅二進制的模塊的發行者來說，支持也更加困難，他們必須爲他們希望支持的
-  每個發行版和每個內核版本提供不同版本的模塊。爲了提供較爲全面的覆蓋範圍，
-  可能需要一個模塊的幾十個構建，並且每次升級內核時，您的用戶都必須單獨升級
-  這些模塊。
+- 對於僅二進位的模組的發行者來說，支援也更加困難，他們必須為他們希望支援的
+  每個發行版和每個核心版本提供不同版本的模組。為了提供較為全面的覆蓋範圍，
+  可能需要一個模組的幾十個建置，並且每次升級核心時，您的使用者都必須單獨升級
+  這些模組。
 
-- 上面提到的關於代碼評審的所有問題都更加存在於封閉源代碼中。由於該代碼根本
-  不可得，因此社區無法對其進行審查，毫無疑問，它將存在嚴重問題。
+- 上面提到的關於程式碼評審的所有問題都更加存在於封閉原始程式碼中。由於該程
+  式碼根本不可得，因此社群無法對其進行審查，毫無疑問，它將存在嚴重問題。
 
-尤其是嵌入式系統的製造商，可能會傾向於忽視本節中所說的大部分內容；因爲他們
-相信自己正在商用一種使用凍結內核版本的獨立產品，在發佈後不需要再進行開發。
-這個論點忽略了廣泛的代碼審查的價值以及允許用戶向產品添加功能的價值。但這些
-產品的商業壽命有限，之後必須發佈新版本的產品。在這一點上，代碼在主線上並得到
+尤其是嵌入式系統的製造商，可能會傾向於忽視本節中所說的大部分內容；因為他們
+相信自己正在商用一種使用凍結核心版本的獨立產品，在發布後不需要再進行開發。
+這個論點忽略了廣泛的程式碼審查的價值以及允許使用者向產品添加功能的價值。但這些
+產品的商業壽命有限，之後必須發布新版本的產品。在這一點上，程式碼在主線上並得到
 良好維護的供應商將能夠更好地佔位，以使新產品快速上市。
 
 許可
 ----
 
-代碼是根據一些許可證提供給Linux內核的，但是所有代碼都必須與GNU通用公共許可
-證（GPLV2）的版本2兼容，該版本是覆蓋整個內核分發的許可證。在實踐中，這意味
-着所有代碼貢獻都由GPLv2（可選地，語言允許在更高版本的GPL下分發）或3子句BSD
-許可（New BSD License，譯者注）覆蓋。任何不包含在兼容許可證中的貢獻都不會
-被接受到內核中。
+程式碼是根據一些許可證提供給Linux核心的，但是所有程式碼都必須與GNU通用公共許可
+證（GPLv2）的版本2相容，該版本是覆蓋整個核心分發的許可證。在實踐中，這意味
+著所有程式碼貢獻都由GPLv2（可選地，語言允許在更高版本的GPL下分發）或3子句BSD
+許可（New BSD License，譯者注）覆蓋。任何不包含在相容許可證中的貢獻都不會
+被接受到核心中。
 
-貢獻給內核的代碼不需要（或請求）版權分配。合併到主線內核中的所有代碼都保留
-其原始所有權；因此，內核現在擁有數千個所有者。
+貢獻給核心的程式碼不需要（或請求）版權分配。合併到主線核心中的所有程式碼都保留
+其原始所有權；因此，核心現在擁有數千個所有者。
 
-這種所有權結構也暗示着，任何改變內核許可的嘗試都註定會失敗。很少有實際情況
-可以獲得所有版權所有者的同意（或者從內核中刪除他們的代碼）。因此，尤其是在
+這種所有權結構也暗示著，任何改變核心許可的嘗試都註定會失敗。很少有實際情況
+可以獲得所有版權所有者的同意（或者從核心中刪除他們的程式碼）。因此，尤其是在
 可預見的將來，許可證不大可能遷移到GPL的版本3。
 
-所有貢獻給內核的代碼都必須是合法的免費軟件。因此，不接受匿名（或化名）貢獻
-者的代碼。所有貢獻者都需要在他們的代碼上“sign off（簽發）”，聲明代碼可以
-在GPL下與內核一起分發。無法提供未被其所有者許可爲免費軟件的代碼，或可能爲
-內核造成版權相關問題的代碼（例如，由缺乏適當保護的反向工程工作派生的代碼）
-不能被接受。
+所有貢獻給核心的程式碼都必須是合法的自由軟體。因此，不接受身分不明或匿名的
+貢獻者的程式碼。所有貢獻者都需要在他們的程式碼上“sign off（簽發）”，聲明程
+式碼可以在GPL下與核心一起分發。無法提供未被其所有者許可為自由軟體的程式碼，
+或可能為核心造成版權相關問題的程式碼（例如，由缺乏適當保護的反向工程工作派
+生的程式碼）不能被接受。
 
-有關版權問題的提問在Linux開發郵件列表中很常見。這樣的問題通常會得到不少答案，
-但請記住，回答這些問題的人不是律師，不能提供法律諮詢。如果您有關於Linux源代碼
-的法律問題，沒有什麼可以代替諮詢瞭解這一領域的律師。依賴從技術郵件列表中獲得
-的答案是一件冒險的事情。
+有關版權問題的提問在Linux開發郵件列表中很常見。這樣的問題通常會得到不少答
+案，但請記住，回答這些問題的人不是律師，不能提供法律諮詢。如果您有關於
+Linux原始程式碼的法律問題，沒有什麼可以代替諮詢瞭解這一領域的律師。依賴從
+技術郵件列表中獲得的答案是一件冒險的事情。
 
 
diff --git a/Documentation/translations/zh_TW/process/2.Process.rst b/Documentation/translations/zh_TW/process/2.Process.rst
index f45ddba6238f..36b109622ea6 100644
--- a/Documentation/translations/zh_TW/process/2.Process.rst
+++ b/Documentation/translations/zh_TW/process/2.Process.rst
@@ -12,64 +12,60 @@
 
  吳想成 Wu XiangCheng <bobwxc@email.cn>
  胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
+ 葉宸佑 Chen-Yu Yeh <chenyou910331@gmail.com>
 
 .. _tw_development_process:
 
 開發流程如何進行
 ================
 
-90年代早期的Linux內核開發是一件相當鬆散的事情，涉及的用戶和開發人員相對較少。
-由於擁有數以百萬計的用戶羣，且每年有大約2000名開發人員參與進來，內核因此必須
-發展出許多既定流程來保證開發的順利進行。要參與到流程中來，需要對此流程的進行
-方式有一個紮實的理解。
+90年代早期的Linux核心開發是一件相當鬆散的事情，涉及的使用者和開發人員相對
+較少。由於擁有數以百萬計的使用者羣，且每年有大約2000名開發人員參與進來，核
+心因此必須發展出許多既定流程來保證開發的順利進行。要參與到流程中來，需要對
+此流程的進行方式有一個紮實的理解。
 
 總覽
 ----
 
-內核開發人員使用一個鬆散的基於時間的發佈過程，每兩到三個月發佈一次新的主要
-內核版本。最近的發佈歷史記錄如下：
+Linux核心使用一種鬆散的、基於時間的滾動發布開發模式。每兩到三個月就會有
+一個新的主要核心版本發布（作為範例，我們稱之為9.x） [1]_ ，它帶來新特性、
+內部API更改等等。一個典型的版本可以包含大約13000個變更集，變更了幾十萬行
+程式碼。最近的版本及其日期可以在
+`維基百科 <https://en.wikipedia.org/wiki/Linux_kernel_version_history>`_
+找到。
 
-	======  =================
-	5.0	2019年3月3日
-	5.1	2019年5月5日
-	5.2	2019年7月7日
-	5.3	2019年9月15日
-	5.4	2019年11月24日
-	5.5	2020年1月6日
-	======  =================
-
-每個5.x版本都是一個主要的內核版本，具有新特性、內部API更改等等。一個典型的5.x
-版本包含大約13000個變更集，變更了幾十萬行代碼。因此，5.x是Linux內核開發的前
-沿；內核使用滾動開發模型，不斷集成重大變化。
+.. [1] 嚴格來說，Linux核心並不使用語意化版本編號方案，而是以9.x這一對
+       數字作為一個整體來標識主要發布版本。每次發布時x會遞增，只有當x被
+       認為足夠大時才會遞增9（例如，Linux 5.0是繼Linux 4.20之後發布的）。
 
 對於每個版本的補丁合併，遵循一個相對簡單的規則。在每個開發週期的開頭，“合併
-窗口”被打開。這時，被認爲足夠穩定（並且被開發社區接受）的代碼被合併到主線內
+視窗”被開啟。這時，被認為足夠穩定（並且被開發社群接受）的程式碼被合併到主線內
 核中。在這段時間內，新開發週期的大部分變更（以及所有主要變更）將以接近每天
 1000次變更（“補丁”或“變更集”）的速度合併。
 
-（順便說一句，值得注意的是，合併窗口期間集成的更改並不是憑空產生的；它們是經
+（順便說一句，值得注意的是，合併視窗期間整合的更改並不是憑空產生的；它們是經
 提前收集、測試和分級的。稍後將詳細描述該過程的工作方式。）
 
-合併窗口持續大約兩週。在這段時間結束時，Linus Torvalds將聲明窗口已關閉，並
-釋放第一個“rc”內核。例如，對於目標爲5.6的內核，在合併窗口結束時發生的釋放
-將被稱爲5.6-rc1。-rc1 版本是一個信號，表示合併新特性的時間已經過去，穩定下一
-個內核的時間已經到來。
+合併視窗持續大約兩週。在這段時間結束時，Linus Torvalds將聲明視窗已關閉，並
+釋放第一個“rc”核心。例如，對於目標為9.x的核心，在合併視窗結束時發生的釋放
+將被稱為9.x-rc1。-rc1 版本是一個信號，表示合併新特性的時間已經過去，穩定下一
+個核心的時間已經到來。
 
 在接下來的6到10周內，只有修復問題的補丁才應該提交給主線。有時會允許更大的
-更改，但這種情況很少發生；試圖在合併窗口外合併新功能的開發人員往往受不到
-友好的接待。一般來說，如果您錯過了給定特性的合併窗口，最好的做法是等待下一
-個開發週期。（偶爾會對未支持硬件的驅動程序進行例外；如果它們不改變已有代碼，
+更改，但這種情況很少發生；試圖在合併視窗外合併新功能的開發人員往往受不到
+友好的接待。一般來說，如果您錯過了給定特性的合併視窗，最好的做法是等待下一
+個開發週期。（偶爾會對未支援硬體的驅動程式進行例外；如果它們不改變已有程式碼，
 則不會導致迴歸，應該可以隨時被安全地加入）。
 
-隨着修復程序進入主線，補丁速度將隨着時間的推移而變慢。Linus大約每週發佈一次
-新的-rc內核；在內核被認爲足夠穩定並最終發佈前，一般會達到-rc6到-rc9之間。
+隨著修復程式進入主線，補丁速度將隨著時間的推移而變慢。Linus大約每週發布一次
+新的-rc核心；在核心被認為足夠穩定並最終發布前，一般會達到-rc6到-rc9之間。
 然後，整個過程又重新開始了。
 
-例如，這裏是5.4的開發週期進行情況（2019年）:
+例如，這裡是5.4的開發週期進行情況（2019年）:
 
 	==============  ==============================
-	九月 15         5.3 穩定版發佈
-	九月 30         5.4-rc1 合併窗口關閉
+	九月 15         5.3 穩定版發布
+	九月 30         5.4-rc1 合併視窗關閉
 	十月 6          5.4-rc2
 	十月 13         5.4-rc3
 	十月 20         5.4-rc4
@@ -77,26 +73,26 @@
 	十一月 3        5.4-rc6
 	十一月 10       5.4-rc7
 	十一月 17       5.4-rc8
-	十一月 24       5.4 穩定版發佈
+	十一月 24       5.4 穩定版發布
 	==============  ==============================
 
-開發人員如何決定何時結束開發週期並創建穩定版本？最重要的指標是以前版本的
-迴歸列表。不歡迎出現任何錯誤，但是那些破壞了以前能工作的系統的錯誤被認爲是
+開發人員如何決定何時結束開發週期並建立穩定版本？最重要的指標是以前版本的
+迴歸列表。不歡迎出現任何錯誤，但是那些破壞了以前能工作的系統的錯誤被認為是
 特別嚴重的。因此，導致迴歸的補丁是不受歡迎的，很可能在穩定期內刪除。
 
-開發人員的目標是在穩定發佈之前修復所有已知的迴歸。在現實世界中，這種完美是
-很難實現的；在這種規模的項目中，變數太多了。需要說明的是，延遲最終版本只會
-使問題變得更糟；等待下一個合併窗口的更改將變多，導致下次出現更多的迴歸錯誤。
-因此，大多數5.x內核都有一些已知的迴歸錯誤，不過，希望沒有一個是嚴重的。
+開發人員的目標是在穩定發布之前修復所有已知的迴歸。在現實世界中，這種完美是
+很難實作的；在這種規模的專案中，變數太多了。需要說明的是，延遲最終版本只會
+使問題變得更糟；等待下一個合併視窗的更改將變多，導致下次出現更多的迴歸錯誤。
+因此，大多數核心版本都有一些已知的迴歸錯誤，不過，希望沒有一個是嚴重的。
 
-一旦一個穩定的版本發佈，它的持續維護工作就被移交給“穩定團隊”，目前由
-Greg Kroah-Hartman領導。穩定團隊將使用5.x.y編號方案不定期地發佈穩定版本的
-更新。要合入更新版本，補丁必須（1）修復一個重要的缺陷，且（2）已經合併到
-下一個開發版本主線中。內核通常會在其初始版本後的一個以上的開發週期內收到
-穩定版更新。例如，5.2內核的歷史如下（2019年）：
+一旦一個穩定的版本發布，它的持續維護工作就被移交給“穩定團隊”，目前由Greg
+Kroah-Hartman和Sasha Levin組成。穩定團隊將使用9.x.y編號方案不定期地發布穩
+定版本的更新。要合入更新版本，補丁必須（1）修復一個重要的缺陷，且（2）已經
+合併到下一個開發版本主線中。核心通常會在其初始版本後的一個以上的開發週期內
+收到穩定版更新。例如，5.2核心的歷史如下（2019年）：
 
 	==============  ===============================
-        七月 7 	        5.2 穩定版發佈
+        七月 7 	        5.2 穩定版發布
 	七月 13	        5.2.1
 	七月 21	        5.2.2
 	七月 26	        5.2.3
@@ -108,36 +104,29 @@ Greg Kroah-Hartman領導。穩定團隊將使用5.x.y編號方案不定期地發
 
 5.2.21是5.2版本的最終穩定更新。
 
-有些內核被指定爲“長期”內核；它們將得到更長時間的支持。在本文中，當前的長期
-內核及其維護者是：
+有些核心被指定為“長期”核心；它們將得到更長時間的支援。當前的長期核心
+版本及其維護者的列表，請參考以下連結：
 
-	======  ================================	================
-	3.16	Ben Hutchings				（長期穩定內核）
-	4.4	Greg Kroah-Hartman & Sasha Levin	（長期穩定內核）
-	4.9	Greg Kroah-Hartman & Sasha Levin
-	4.14	Greg Kroah-Hartman & Sasha Levin
-	4.19	Greg Kroah-Hartman & Sasha Levin
-	5.4	Greg Kroah-Hartman & Sasha Levin
-	======  ================================	================
+	https://www.kernel.org/category/releases.html
 
-長期支持內核的選擇純粹是維護人員是否有需求和時間來維護該版本的問題。
-目前還沒有爲即將發佈的任何特定版本提供長期支持的已知計劃。
+長期支援核心的選擇純粹是維護人員是否有需求和時間來維護該版本的問題。
 
 補丁的生命週期
 --------------
 
-補丁不會直接從開發人員的鍵盤進入主線內核。相反，有一個稍微複雜（如果有些非
-正式）的過程，旨在確保對每個補丁進行質量審查，並確保每個補丁實現了一個在主線
-中需要的更改。對於小的修復，這個過程可能會很快完成，，而對於較大或有爭議的
-變更，可能會持續數年。許多開發人員的沮喪來自於對這個過程缺乏理解或者試圖繞過它。
+補丁不會直接從開發人員的鍵盤進入主線核心。相反，有一個稍微複雜（如果有些非
+正式）的過程，旨在確保對每個補丁進行品質審查，並確保每個補丁實作了一個在主
+線中需要的更改。對於小的修復，這個過程可能會很快完成，，而對於較大或有爭議
+的變更，可能會持續數年。許多開發人員的沮喪來自於對這個過程缺乏理解或者試圖
+繞過它。
 
-爲了減少這種挫敗，本文將描述補丁如何進入內核。下面的介紹以一種較爲理想化的
+為了減少這種挫敗，本文將描述補丁如何進入核心。下面的介紹以一種較為理想化的
 方式描述了這個過程。更詳細的過程將在後面的章節中介紹。
 
 補丁通常要經歷以下階段：
 
 - 設計。這就是補丁的真正需求——以及滿足這些需求的方式——所在。設計工作通常
-  是在不涉及社區的情況下完成的，但是如果可能的話，最好是在公開的情況下完成
+  是在不涉及社群的情況下完成的，但是如果可能的話，最好是在公開的情況下完成
   這項工作；這樣可以節省很多稍後再重新設計的時間。
 
 - 早期評審。補丁被髮布到相關的郵件列表中，列表中的開發人員會回覆他們可能有
@@ -150,74 +139,75 @@ Greg Kroah-Hartman領導。穩定團隊將使用5.x.y編號方案不定期地發
   問題。
 
 - 請注意，大多數維護人員也有日常工作，因此合併補丁可能不是他們的最優先工作。
-  如果您的補丁得到了需要更改的反饋，那麼您應該進行這些更改，或者解釋爲何
+  如果您的補丁得到了需要更改的反饋，那麼您應該進行這些更改，或者解釋為何
   不應該進行這些更改。如果您的補丁沒有評審意見，也沒有被其相應的子系統或
-  驅動程序維護者接受，那麼您應該堅持不懈地將補丁更新到當前內核使其可被正常
-  應用，並不斷地發送它以供審查和合並。
+  驅動程式維護者接受，那麼您應該堅持不懈地將補丁更新到當前核心使其可被正常
+  應用，並不斷地發送它以供審查和合併。
 
-- 合併到主線。最終，一個成功的補丁將被合併到由LinusTorvalds管理的主線存儲庫
+- 合併到主線。最終，一個成功的補丁將被合併到由Linus Torvalds管理的主線儲存庫
   中。此時可能會出現更多的評論和/或問題；對開發人員來說應對這些問題並解決
   出現的任何問題仍很重要。
 
-- 穩定版發佈。大量用戶可能受此補丁影響，因此可能再次出現新的問題。
+- 穩定版發布。大量使用者可能受此補丁影響，因此可能再次出現新的問題。
 
-- 長期維護。雖然開發人員在合併代碼後可能會忘記代碼，但這種行爲往往會給開發
-  社區留下不良印象。合併代碼消除了一些維護負擔，因爲其他人將修復由API更改
-  引起的問題。但是，如果代碼要長期保持可用，原始開發人員應該繼續爲代碼負責。
+- 長期維護。雖然開發人員在合併程式碼後可能會忘記程式碼，但這種行為往往會給
+  開發社群留下不良印象。合併程式碼消除了一些維護負擔，因為其他人將修復由
+  API更改引起的問題。但是，如果程式碼要長期保持可用，原始開發人員應該繼續
+  為程式碼負責。
 
-內核開發人員（或他們的僱主）犯的最大錯誤之一是試圖將流程簡化爲一個“合併到
+核心開發人員（或他們的僱主）犯的最大錯誤之一是試圖將流程簡化為一個“合併到
 主線”步驟。這種方法總是會讓所有相關人員感到沮喪。
 
-補丁如何進入內核
+補丁如何進入核心
 ----------------
 
-只有一個人可以將補丁合併到主線內核存儲庫中：Linus Torvalds。但是，在進入
-2.6.38內核的9500多個補丁中，只有112個（大約1.3%）是由Linus自己直接選擇的。
-內核項目已經發展到一個沒有一個開發人員可以在沒有支持的情況下檢查和選擇每個
-補丁的規模。內核開發人員處理這種增長的方式是使用圍繞信任鏈構建的助理系統。
+只有一個人可以將補丁合併到主線核心儲存庫中：Linus Torvalds。但是，在進入
+2.6.38核心的9500多個補丁中，只有112個（大約1.3%）是由Linus自己直接選擇的。
+核心專案已經發展到一個沒有一個開發人員可以在沒有支援的情況下檢查和選擇每個
+補丁的規模。核心開發人員處理這種增長的方式是使用圍繞信任鏈建置的助理系統。
 
-內核代碼庫在邏輯上被分解爲一組子系統：網絡、特定體系結構支持、內存管理、視
-頻設備等。大多數子系統都有一個指定的維護人員，其總體負責該子系統中的代碼。
-這些子系統維護者（鬆散地）是他們所管理的內核部分的“守門員”；他們（通常）
-會接受一個補丁以包含到主線內核中。
+核心程式碼庫在邏輯上被分解為一組子系統：網路、特定體系結構支援、記憶體管理、視
+頻設備等。大多數子系統都有一個指定的維護人員，其總體負責該子系統中的程式碼。
+這些子系統維護者（鬆散地）是他們所管理的核心部分的“守門員”；他們（通常）
+會接受一個補丁以包含到主線核心中。
 
-子系統維護人員每個人都管理着自己版本的內核源代碼樹，通常（並非總是）使用Git。
-Git等工具（以及Quilt或Mercurial等相關工具）允許維護人員跟蹤補丁列表，包括作者
-信息和其他元數據。在任何給定的時間，維護人員都可以確定他或她的存儲庫中的哪
-些補丁在主線中找不到。
+子系統維護人員每個人都管理著自己版本的核心原始程式碼樹，通常（並非總是）使
+用Git。Git等工具（以及Quilt或Mercurial等相關工具）允許維護人員追蹤補丁列表，
+包括作者資訊和其他元資料。在任何給定的時間，維護人員都可以確定他或她的儲存
+庫中的哪些補丁在主線中找不到。
 
-當合並窗口打開時，頂級維護人員將要求Linus從存儲庫中“拉出”他們爲合併選擇
-的補丁。如果Linus同意，補丁流將流向他的存儲庫，成爲主線內核的一部分。
+當合併視窗開啟時，頂級維護人員將要求Linus從儲存庫中“拉出”他們為合併選擇
+的補丁。如果Linus同意，補丁流將流向他的儲存庫，成為主線核心的一部分。
 Linus對拉取中接收到的特定補丁的關注程度各不相同。很明顯，有時他看起來很
 關注。但是一般來說，Linus相信子系統維護人員不會向上遊發送壞補丁。
 
-子系統維護人員反過來也可以從其他維護人員那裏獲取補丁。例如，網絡樹是由首先
-在專用於網絡設備驅動程序、無線網絡等的樹中積累的補丁構建的。此存儲鏈可以
-任意長，但很少超過兩個或三個鏈接。由於鏈中的每個維護者都信任那些管理較低
-級別樹的維護者，所以這個過程稱爲“信任鏈”。
+子系統維護人員反過來也可以從其他維護人員那裡獲取補丁。例如，網路樹是由首先
+在專用於網路設備驅動程式、無線網路等的樹中積累的補丁建置的。此儲存鏈可以
+任意長，但很少超過兩個或三個連結。由於鏈中的每個維護者都信任那些管理較低
+級別樹的維護者，所以這個過程稱為“信任鏈”。
 
-顯然，在這樣的系統中，獲取內核補丁取決於找到正確的維護者。直接向Linus發送
+顯然，在這樣的系統中，獲取核心補丁取決於找到正確的維護者。直接向Linus發送
 補丁通常不是正確的方法。
 
 Next 樹
 -------
 
-子系統樹鏈引導補丁流到內核，但它也提出了一個有趣的問題：如果有人想查看爲
-下一個合併窗口準備的所有補丁怎麼辦？開發人員將感興趣的是，還有什麼其他的
-更改有待解決，以瞭解是否存在需要擔心的衝突；例如，更改核心內核函數原型的
-修補程序將與使用該函數舊形式的任何其他修補程序衝突。審查人員和測試人員希望
-在所有這些變更到達主線內核之前，能夠訪問它們的集成形式的變更。您可以從所有
+子系統樹鏈引導補丁流到核心，但它也提出了一個有趣的問題：如果有人想查看為
+下一個合併視窗準備的所有補丁怎麼辦？開發人員將感興趣的是，還有什麼其他的
+更改有待解決，以瞭解是否存在需要擔心的衝突；例如，更改核心核心函式原型的
+修補程式將與使用該函式舊形式的任何其他修補程式衝突。審查人員和測試人員希望
+在所有這些變更到達主線核心之前，能夠存取它們的整合形式的變更。您可以從所有
 相關的子系統樹中提取更改，但這將是一項複雜且容易出錯的工作。
 
-解決方案以-next樹的形式出現，在這裏子系統樹被收集以供測試和審查。這些樹中
-由Andrew Morton維護的較老的一個，被稱爲“-mm”（用於內存管理，創建時爲此）。
--mm 樹集成了一長串子系統樹中的補丁；它還包含一些旨在幫助調試的補丁。
+解決方案以-next樹的形式出現，在這裡子系統樹被收集以供測試和審查。這些樹中
+由Andrew Morton維護的較老的一個，被稱為“-mm”（用於記憶體管理，建立時為此）。
+-mm 樹整合了一長串子系統樹中的補丁；它還包含一些旨在幫助除錯的補丁。
 
 除此之外，-mm 還包含大量由Andrew直接選擇的補丁。這些補丁可能已經發布在郵件
-列表上，或者它們可能應用於內核中未指定子系統樹的部分。同時，-mm 作爲最後
+列表上，或者它們可能應用於核心中未指定子系統樹的部分。同時，-mm 作為最後
 手段的子系統樹；如果沒有其他明顯的路徑可以讓補丁進入主線，那麼它很可能最
 終選擇-mm 樹。累積在-mm 中的各種補丁最終將被轉發到適當的子系統樹，或者直接
-發送到Linus。在典型的開發週期中，大約5-10%的補丁通過-mm 進入主線。
+發送到Linus。在典型的開發週期中，大約5-10%的補丁透過-mm 進入主線。
 
 當前-mm 補丁可在“mmotm”（-mm of the moment）目錄中找到：
 
@@ -225,102 +215,103 @@ Next 樹
 
 然而，使用MMOTM樹可能會十分令人頭疼；它甚至可能無法編譯。
 
-下一個週期補丁合併的主要樹是linux-next，由Stephen Rothwell 維護。根據設計
-linux-next 是下一個合併窗口關閉後主線的快照。linux-next樹在Linux-kernel 和
-Linux-next 郵件列表中發佈，可從以下位置下載：
+下一個週期補丁合併的主要樹是linux-next，由Mark Brown維護。根據設計
+linux-next 是下一個合併視窗關閉後主線的快照。linux-next樹在Linux-kernel 和
+Linux-next 郵件列表中發布，可從以下位置下載：
 
         https://www.kernel.org/pub/linux/kernel/next/
 
-Linux-next 已經成爲內核開發過程中不可或缺的一部分；在一個給定的合併窗口中合併
-的所有補丁都應該在合併窗口打開之前的一段時間內找到進入Linux-next 的方法。
+Linux-next 已經成為核心開發過程中不可或缺的一部分；在一個給定的合併視窗中合併
+的所有補丁都應該在合併視窗開啟之前的一段時間內找到進入Linux-next 的方法。
 
 Staging 樹
 ----------
 
-內核源代碼樹包含drivers/staging/目錄，其中有許多驅動程序或文件系統的子目錄
-正在被添加到內核樹中。它們在仍然需要更多的修正的時候可以保留在driver/staging/
-目錄中；一旦完成，就可以將它們移到內核中。這是一種跟蹤不符合Linux內核編碼或
-質量標準的驅動程序的方法，人們可能希望使用它們並跟蹤開發。
+核心原始程式碼樹包含drivers/staging/目錄，其中有許多驅動程式或檔案系統的子目錄
+正在被添加到核心樹中。它們在仍然需要更多的修正的時候可以保留在driver/staging/
+目錄中；一旦完成，就可以將它們移到核心中。這是一種追蹤不符合Linux核心編碼或
+品質標準的驅動程式的方法，人們可能希望使用它們並追蹤開發。
 
-Greg Kroah Hartman 目前負責維護staging 樹。仍需要修正的驅動程序將發送給他，
-每個驅動程序在drivers/staging/中都有自己的子目錄。除了驅動程序源文件之外，
-目錄中還應該有一個TODO文件。TODO文件列出了驅動程序需要接受的暫停的工作，
-以及驅動程序的任何補丁都應該抄送的人員列表。當前的規則要求，staging的驅動
-程序必須至少正確編譯。
+Greg Kroah-Hartman 目前負責維護staging樹。仍需要修正的驅動程式將發送給他，
+每個驅動程式在drivers/staging/中都有自己的子目錄。除了驅動程式原始檔之外，
+目錄中還應該有一個TODO檔案。TODO檔案列出了驅動程式需要接受的暫停的工作，
+以及驅動程式的任何補丁都應該抄送的人員列表。當前的規則要求，staging的驅動
+程式必須至少正確編譯。
 
-Staging 是一種讓新的驅動程序進入主線的相對容易的方法，它們會幸運地引起其他
+Staging 是一種讓新的驅動程式進入主線的相對容易的方法，它們會幸運地引起其他
 開發人員的注意，並迅速改進。然而，進入staging並不是故事的結尾；staging中
-沒有看到常規進展的代碼最終將被刪除。經銷商也傾向於相對不願意使用staging驅動
-程序。因此，在成爲一個合適的主線驅動的路上，staging 僅是一箇中轉站。
+沒有看到常規進展的程式碼最終將被刪除。經銷商也傾向於相對不願意使用staging驅動
+程式。因此，在成為一個合適的主線驅動的路上，staging 僅是一箇中轉站。
 
 工具
 ----
 
-從上面的文本可以看出，內核開發過程在很大程度上依賴於在不同方向上聚集補丁的
+從上面的文字可以看出，核心開發過程在很大程度上依賴於在不同方向上聚集補丁的
 能力。如果沒有適當強大的工具，整個系統將無法在任何地方正常工作。關於如何使用
-這些工具的教程遠遠超出了本文檔的範圍，但還是用一點篇幅介紹一些關鍵點。
+這些工具的教程遠遠超出了本文件的範圍，但還是用一點篇幅介紹一些關鍵點。
 
-到目前爲止，內核社區使用的主要源代碼管理系統是git。Git是在自由軟件社區中開發
-的許多分佈式版本控制系統之一。它非常適合內核開發，因爲它在處理大型存儲庫和
-大量補丁時性能非常好。它也以難以學習和使用而著稱，儘管隨着時間的推移它變得
-更好了。對於內核開發人員來說，對Git的某種熟悉幾乎是一種要求；即使他們不將它
-用於自己的工作，他們也需要Git來跟上其他開發人員（以及主線）正在做的事情。
+到目前為止，核心社群使用的主要原始程式碼管理系統是git。Git是在自由軟體社群
+中開發的許多分散式版本控制系統之一。它非常適合核心開發，因為它在處理大型儲
+存庫和大量補丁時效能非常好。它也以難以學習和使用而著稱，儘管隨著時間的推移
+它變得更好了。對於核心開發人員來說，對Git的某種熟悉幾乎是一種要求；即使他
+們不將它用於自己的工作，他們也需要Git來跟上其他開發人員（以及主線）正在做
+的事情。
 
 現在幾乎所有的Linux發行版都打包了Git。Git主頁位於：
 
         https://git-scm.com/
 
-此頁面包含了文檔和教程的鏈接。
+此頁面包含了文件和教程的連結。
 
-在不使用git的內核開發人員中，最流行的選擇幾乎肯定是Mercurial：
+在不使用git的核心開發人員中，最流行的選擇幾乎肯定是Mercurial：
 
         http://www.seleric.com/mercurial/
 
-Mercurial與Git共享許多特性，但它提供了一個界面，許多人覺得它更易於使用。
+Mercurial與Git共享許多特性，但它提供了一個介面，許多人覺得它更易於使用。
 
 另一個值得了解的工具是Quilt:
 
         https://savannah.nongnu.org/projects/quilt
 
-Quilt 是一個補丁管理系統，而不是源代碼管理系統。它不會隨着時間的推移跟蹤歷史；
-相反，它面向根據不斷發展的代碼庫跟蹤一組特定的更改。一些主要的子系統維護人員
-使用Quilt來管理打算向上遊移動的補丁。對於某些樹的管理（例如-mm），quilt 是
-最好的工具。
+Quilt 是一個補丁管理系統，而不是原始程式碼管理系統。它不會隨著時間的推移追
+蹤歷史；相反，它面向根據不斷發展的程式碼庫追蹤一組特定的更改。一些主要的子
+系統維護人員使用Quilt來管理打算向上遊移動的補丁。對於某些樹的管理（例如-mm），
+quilt 是最好的工具。
 
 郵件列表
 --------
 
-大量的Linux內核開發工作是通過郵件列表完成的。如果不加入至少一個某個列表，
-就很難成爲社區中的一個“全功能”成員。但是，Linux郵件列表對開發人員來說也是
+大量的Linux核心開發工作是透過郵件列表完成的。如果不加入至少一個某個列表，
+就很難成為社群中的一個“全功能”成員。但是，Linux郵件列表對開發人員來說也是
 一個潛在的危險，他們可能會被一堆電子郵件淹沒、違反Linux列表上使用的約定，
 或者兩者兼而有之。
 
-大多數內核郵件列表都在vger.kernel.org上運行；主列表位於：
+大多數核心郵件列表都託管在kernel.org上；主列表位於：
 
-        http://vger.kernel.org/vger-lists.html
+        https://subspace.kernel.org
 
-不過，也有一些列表託管在別處；其中一些列表位於
-redhat.com/mailman/listinfo。
+也有一些列表託管在別處；請查閱MAINTAINERS檔案以找到與特定子系統相關的
+列表。
 
-當然，內核開發的核心郵件列表是linux-kernel。這個列表是一個令人生畏的地方：
-每天的信息量可以達到500條，噪音很高，談話技術性很強，且參與者並不總是表現出
-高度的禮貌。但是，沒有其他地方可以讓內核開發社區作爲一個整體聚集在一起；
-不使用此列表的開發人員將錯過重要信息。
+當然，核心開發的核心郵件列表是linux-kernel。這個列表是一個令人生畏的地方：
+每天的資訊量可以達到500條，噪音很高，談話技術性很強，且參與者並不總是表現出
+高度的禮貌。但是，沒有其他地方可以讓核心開發社群作為一個整體聚集在一起；
+不使用此列表的開發人員將錯過重要資訊。
 
 以下一些提示可以幫助在linux-kernel生存：
 
-- 將郵件轉移到單獨的文件夾，而不是主郵箱文件夾。我們必須能夠持續地忽略洪流。
+- 將郵件轉移到單獨的資料夾，而不是主信箱資料夾。我們必須能夠持續地忽略洪流。
 
 - 不要試圖跟上每一次談話——沒人會這樣。重要的是要篩選感興趣的主題（但請注意
   長時間的對話可能會偏離原來的主題，儘管未改變電子郵件的主題）和參與的人。
 
 - 不要回復挑事的人。如果有人試圖激起憤怒，請忽略他們。
 
-- 當回覆Linux內核電子郵件（或其他列表上的電子郵件）時，請爲所有相關人員保留
+- 當回覆Linux核心電子郵件（或其他列表上的電子郵件）時，請為所有相關人員保留
   Cc: 抄送頭。如果沒有確實的理由（如明確的請求），則不應刪除收件人。一定要
   確保你要回復的人在抄送列表中。這個慣例也使你不必在回覆郵件時明確要求被抄送。
 
-- 在提出問題之前，搜索列表存檔（和整個網絡）。有些開發人員可能會對那些顯然
+- 在提出問題之前，搜索列表存檔（和整個網路）。有些開發人員可能會對那些顯然
   沒有完成家庭作業的人感到不耐煩。
 
 - 避免頂部回覆（把你的答案放在你要回復的引文上面的做法）。這會讓你的回答更難
@@ -329,41 +320,41 @@ redhat.com/mailman/listinfo。
 - 在正確的郵件列表發問。linux-kernel 可能是通用的討論場所，但它不是尋找所有
   子系統開發人員的最佳場所。
 
-最後一點——找到正確的郵件列表——是開發人員常出錯的地方。在linux-kernel上
-提出與網絡相關的問題的人幾乎肯定會收到一個禮貌的建議，轉到netdev列表上提出，
-因爲這是大多數網絡開發人員經常出現的列表。還有其他列表可用於scsi、video4linux、
-ide、filesystem等子系統。查找郵件列表的最佳位置是與內核源代碼一起打包的
-MAINTAINERS文件。
+最後一點——找到正確的郵件列表——是開發人員常出錯的地方。在linux-kernel上提出
+與網路相關的問題的人幾乎肯定會收到一個禮貌的建議，轉到netdev列表上提出，因
+為這是大多數網路開發人員經常出現的列表。還有其他列表可用於scsi、
+video4linux、ide、filesystem等子系統。查找郵件列表的最佳位置是與核心原始程
+式碼一起打包的MAINTAINERS檔案。
 
-開始內核開發
+開始核心開發
 ------------
 
-關於如何開始內核開發過程的問題很常見——個人和公司皆然。同樣常見的是失誤，這
+關於如何開始核心開發過程的問題很常見——個人和公司皆然。同樣常見的是失誤，這
 使得關係的開始比本應的更困難。
 
-公司通常希望聘請知名的開發人員來啓動開發團隊。實際上，這是一種有效的技術。
-但它也往往是昂貴的，而且對增加有經驗的內核開發人員的數量沒有多大幫助。考
-慮到時間投入，可以讓內部開發人員加快Linux內核的開發速度。利用這段時間可以
-讓僱主擁有一批既瞭解內核又瞭解公司的開發人員，還可以幫助培訓其他人。從中期
+公司通常希望聘請知名的開發人員來啟動開發團隊。實際上，這是一種有效的技術。
+但它也往往是昂貴的，而且對增加有經驗的核心開發人員的數量沒有多大幫助。考
+慮到時間投入，可以讓內部開發人員加快Linux核心的開發速度。利用這段時間可以
+讓僱主擁有一批既瞭解核心又瞭解公司的開發人員，還可以幫助培訓其他人。從中期
 來看，這通常是更有利可圖的方法。
 
-可以理解的是，單個開發人員往往對起步感到茫然。從一個大型項目開始可能會很
-嚇人；人們往往想先用一些較小的東西來試試水。由此，一些開發人員開始創建修補
+可以理解的是，單個開發人員往往對起步感到茫然。從一個大型專案開始可能會很
+嚇人；人們往往想先用一些較小的東西來試試水。由此，一些開發人員開始建立修補
 拼寫錯誤或輕微編碼風格問題的補丁。不幸的是，這樣的補丁會產生一定程度的噪音，
-這會分散整個開發社區的注意力，因此，它們越來越被人不看重。希望向社區介紹
-自己的新開發人員將無法通過這些方式獲得他們期待的反響。
+這會分散整個開發社群的注意力，因此，它們越來越被人不看重。希望向社群介紹
+自己的新開發人員將無法透過這些方式獲得他們期待的反響。
 
-Andrew Morton 爲有抱負的內核開發人員提供瞭如下建議
+Andrew Morton 為有抱負的核心開發人員提供了如下建議
 
 ::
 
-	所有內核開發者的第一個項目肯定應該是“確保內核在您可以操作的所有
-	機器上始終完美運行”。通常的方法是和其他人一起解決問題（這可能需
-	要堅持！），但就是如此——這是內核開發的一部分。
+	所有核心開發者的第一個專案肯定應該是“確保核心在您可以操作的所有
+	機器上始終完美執行”。通常的方法是和其他人一起解決問題（這可能需
+	要堅持！），但就是如此——這是核心開發的一部分。
 
 (http://lwn.net/Articles/283982/)
 
 在沒有明顯問題需要解決的情況下，通常建議開發人員查看當前的迴歸和開放缺陷
-列表。從來都不缺少需要解決的問題；通過解決這些問題，開發人員將從該過程獲得
-經驗，同時與開發社區的其他成員建立相互尊重。
+列表。從來都不缺少需要解決的問題；透過解決這些問題，開發人員將從該過程獲得
+經驗，同時與開發社群的其他成員建立相互尊重。
 
diff --git a/Documentation/translations/zh_TW/process/5.Posting.rst b/Documentation/translations/zh_TW/process/5.Posting.rst
index 38f3a6d618eb..698cde5cd06d 100644
--- a/Documentation/translations/zh_TW/process/5.Posting.rst
+++ b/Documentation/translations/zh_TW/process/5.Posting.rst
@@ -12,73 +12,78 @@
 
  吳想成 Wu XiangCheng <bobwxc@email.cn>
  胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
+ 葉宸佑 Chen-Yu Yeh <chenyou910331@gmail.com>
 
 .. _tw_development_posting:
 
-發佈補丁
+發布補丁
 ========
 
-您的工作遲早會準備好提交給社區進行審查，並最終包含到主線內核中。毫不稀奇，
-內核開發社區已經發展出一套用於發佈補丁的約定和過程；遵循這些約定和過程將使
-參與其中的每個人的生活更加輕鬆。本文檔試圖描述這些約定的部分細節；更多信息
-也可在以下文檔中找到
-:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <tw_submittingpatches>`
-和 :ref:`Documentation/translations/zh_CN/process/submit-checklist.rst <tw_submitchecklist>`。
+您的工作遲早會準備好提交給社群進行審查，並最終包含到主線核心中。毫不稀奇，
+核心開發社群已經發展出一套用於發布補丁的約定和過程；遵循這些約定和過程將使
+參與其中的每個人的生活更加輕鬆。本文件試圖描述這些約定的部分細節；更多資訊
+也可在以下文件中找到
+:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
+和
+:ref:`Documentation/translations/zh_TW/process/submit-checklist.rst <tw_submitchecklist>`。
 
 何時寄送
 --------
 
-在補丁完全“準備好”之前，避免發佈補丁是一種持續的誘惑。對於簡單的補丁，這
-不是問題。但是如果正在完成的工作很複雜，那麼在工作完成之前從社區獲得反饋就
-可以獲得很多好處。因此，您應該考慮發佈正在進行的工作，甚至維護一個可用的Git
+在補丁完全“準備好”之前，避免發布補丁是一種持續的誘惑。對於簡單的補丁，這
+不是問題。但是如果正在完成的工作很複雜，那麼在工作完成之前從社群獲得反饋就
+可以獲得很多好處。因此，您應該考慮發布正在進行的工作，甚至維護一個可用的Git
 樹，以便感興趣的開發人員可以隨時趕上您的工作。
 
-當發佈中有尚未準備好被包含的代碼，最好在發佈中說明。還應提及任何有待完成的
-主要工作和任何已知問題。很少有人會願意看那些被認爲是半生不熟的補丁，但是
-那些願意的人會帶着他們的點子來一起幫助你把工作推向正確的方向。
+當發布中有尚未準備好被包含的程式碼，最好在發布中說明。還應提及任何有待完成的
+主要工作和任何已知問題。很少有人會願意看那些被認為是半生不熟的補丁，但是
+那些願意的人會帶著他們的點子來一起幫助你把工作推向正確的方向。
 
-創建補丁之前
+建立補丁之前
 ------------
 
-在考慮將補丁發送到開發社區之前，有許多事情應該做。包括：
+在考慮將補丁發送到開發社群之前，有許多事情應該做。包括：
 
- - 儘可能地測試代碼。利用內核的調試工具，確保內核使用了所有可能的配置選項組合
-   進行構建，使用交叉編譯器爲不同的體系結構進行構建等。
+ - 儘可能地測試程式碼。利用核心的除錯工具，確保核心使用了所有可能的設定選
+   項組合進行建置，使用交叉編譯器為不同的架構進行建置等。添加測試，最好使
+   用現有的測試框架（如KUnit），並將其作為補丁系列中單獨的一員（關於補丁系
+   列，見下一節）。注意，對某些子系統而言這可能是強制性的。例如，函式庫函
+   式（位於lib/下）幾乎在所有地方被廣泛使用，應當有適當的測試。
 
- - 確保您的代碼符合內核代碼風格指南。
+ - 確保您的程式碼符合核心程式碼風格指南。
 
- - 您的更改是否具有性能影響？如果是這樣，您應該運行基準測試來顯示您的變更的
+ - 您的更改是否具有效能影響？如果是這樣，您應該執行基準測試來顯示您的變更的
    影響（或好處）；結果的摘要應該包含在補丁中。
 
- - 確保您有權發佈代碼。如果這項工作是爲僱主完成的，僱主對這項工作具有所有權，
-   並且必須同意根據GPL對其進行發佈。
+ - 確保您有權發布程式碼。如果這項工作是為僱主完成的，僱主對這項工作具有所
+   有權，並且必須同意根據GPL對其進行發布。
 
-一般來說，在發佈代碼之前進行一些額外的思考，幾乎總是能在短時間內得到回報。
+一般來說，在發布程式碼之前進行一些額外的思考，幾乎總是能在短時間內得到回報。
 
 補丁準備
 --------
 
-準備補丁發佈的工作量可能很驚人，但在此嘗試節省時間通常是不明智的，即使在短期
+準備補丁發布的工作量可能很驚人，但在此嘗試節省時間通常是不明智的，即使在短期
 內亦然。
 
-必須針對內核的特定版本準備補丁。一般來說，補丁應該基於Linus的Git樹中的當前
-主線。當以主線爲基礎時，請從一個衆所周知的發佈點開始——如穩定版本或 -rc
-版本發佈點——而不是在一個任意的主線分支點。
+必須針對核心的特定版本準備補丁。一般來說，補丁應該基於Linus的Git樹中的當前
+主線。當以主線為基礎時，請從一個衆所周知的發布點開始——如穩定版本或 -rc
+版本發布點——而不是在一個任意的主線分支點。
 
-也可能需要針對-mm、linux-next或子系統樹生成版本，以便於更廣泛的測試和審查。
+也可能需要針對-mm、linux-next或子系統樹產生版本，以便於更廣泛的測試和審查。
 根據補丁的區域以及其他地方的情況，針對其他樹建立的補丁可能需要大量的工作來
 解決衝突和處理API更改。
 
-只有最簡單的更改才應格式化爲單個補丁；其他所有更改都應作爲一系列邏輯更改進行。
-分割補丁是一門藝術；一些開發人員花了很長時間來弄清楚如何按照社區期望的方式來
+只有最簡單的更改才應格式化為單個補丁；其他所有更改都應作為一系列邏輯更改進行。
+分割補丁是一門藝術；一些開發人員花了很長時間來弄清楚如何按照社群期望的方式來
 分割。不過，這些經驗法則也許有幫助：
 
- - 您發佈的補丁系列幾乎肯定不會是開發過程中版本控制系統中的一系列更改。相反，
+ - 您發布的補丁系列幾乎肯定不會是開發過程中版本控制系統中的一系列更改。相反，
    需要對您所做更改的最終形式加以考慮，然後以有意義的方式進行拆分。開發人員對
    離散的、自包含的更改感興趣，而不是您創造這些更改的原始路徑。
 
- - 每個邏輯上獨立的變更都應該格式化爲單獨的補丁。這些更改可以是小的（如“向
-   此結構體添加字段”）或大的（如添加一個重要的新驅動程序），但它們在概念上
+ - 每個邏輯上獨立的變更都應該格式化為單獨的補丁。這些更改可以是小的（如“向
+   此結構體添加欄位”）或大的（如添加一個重要的新驅動程式），但它們在概念上
    應該是小的，並且可以在一行內簡述。每個補丁都應該做一個特定的、可以單獨
    檢查並驗證它所做的事情的更改。
 
@@ -86,132 +91,164 @@
    一個補丁修復了一個關鍵的安全漏洞，又重新排列了一些結構，還重新格式化了代
    碼，那麼它很有可能會被忽略，從而導致重要的修復丟失。
 
- - 每個補丁都應該能創建一個可以正確地構建和運行的內核；如果補丁系列在中間被
-   斷開，那麼結果仍應是一個正常工作的內核。部分應用一系列補丁是使用
-   “git bisct”工具查找回歸的一個常見場景；如果結果是一個損壞的內核，那麼將使
-   那些從事追蹤問題的高尚工作的開發人員和用戶的生活更加艱難。
+ - 每個補丁都應該能建立一個可以正確地建置和執行的核心；如果補丁系列在中間被
+   斷開，那麼結果仍應是一個正常工作的核心。部分應用一系列補丁是使用
+   “git bisct”工具查找回歸的一個常見場景；如果結果是一個損壞的核心，那麼將使
+   那些從事追蹤問題的高尚工作的開發人員和使用者的生活更加艱難。
 
- - 不要過分分割。一位開發人員曾經將一組針對單個文件的編輯分成500個單獨的補丁
-   發佈，這並沒有使他成爲內核郵件列表中最受歡迎的人。一個補丁可以相當大，
+ - 不要過分分割。一位開發人員曾經將一組針對單一檔案的編輯分成500個單獨的補丁
+   發布，這並沒有使他成為核心郵件列表中最受歡迎的人。一個補丁可以相當大，
    只要它仍然包含一個單一的 *邏輯* 變更。
 
- - 用一系列補丁添加一個全新的基礎設施，但是該設施在系列中的最後一個補丁啓用
+ - 用一系列補丁添加一個全新的基礎設施，但是該設施在系列中的最後一個補丁啟用
    整個變更之前不能使用，這看起來很誘人。如果可能的話，應該避免這種誘惑；
    如果這個系列增加了迴歸，那麼二分法將指出最後一個補丁是導致問題的補丁，
-   即使真正的bug在其他地方。只要有可能，添加新代碼的補丁程序應該立即激活該
-   代碼。
+   即使真正的bug在其他地方。只要有可能，添加新程式碼的補丁程式應該立即激活該
+   程式碼。
 
-創建完美補丁系列的工作可能是一個令人沮喪的過程，在完成“真正的工作”之後需要
+建立完美補丁系列的工作可能是一個令人沮喪的過程，在完成“真正的工作”之後需要
 花費大量的時間和思考。但是如果做得好，花費的時間就是值得的。
 
 補丁格式和更改日誌
 ------------------
 
-所以現在你有了一系列完美的補丁可以發佈，但是這項工作還沒有完成。每個補丁都
-需要被格式化成一條消息，以快速而清晰地將其目的傳達到世界其他地方。爲此，
+所以現在你有了一系列完美的補丁可以發布，但是這項工作還沒有完成。每個補丁都
+需要被格式化成一條訊息，以快速而清晰地將其目的傳達到世界其他地方。為此，
 每個補丁將由以下部分組成：
 
- - 可選的“From”行，表明補丁作者。只有當你通過電子郵件發送別人的補丁時，這一行
-   纔是必須的，但是爲防止疑問加上它也不會有什麼壞處。
+ - 可選的“From”行，表明補丁作者。只有當你透過電子郵件發送別人的補丁時，這一行
+   才是必須的，但是為防止疑問加上它也不會有什麼壞處。
 
- - 一行描述，說明補丁的作用。對於在沒有其他上下文的情況下看到該消息的讀者來說，
-   該消息應足以確定修補程序的範圍；此行將顯示在“short form（簡短格式）”變更
-   日誌中。此消息通常需要先加上子系統名稱前綴，然後是補丁的目的。例如：
+ - 一行描述，說明補丁的作用。對於在沒有其他上下文的情況下看到該訊息的讀者
+   來說，該訊息應足以確定修補程式的範圍；此行將顯示在“short form（簡短格式）”
+   變更日誌中。此訊息通常需要先加上子系統名稱前綴，然後是補丁的目的。例如：
 
    ::
 
         gpio: fix build on CONFIG_GPIO_SYSFS=n
 
- - 一行空白，後接補丁內容的詳細描述。此描述可以是任意需要的長度；它應該說明補丁
-   的作用以及爲什麼它應該應用於內核。
+ - 一行空白，後接補丁內容的詳細描述。此描述可以是任意需要的長度；它應該說
+   明補丁的作用以及為什麼它應該應用於核心。
 
  - 一個或多個標記行，至少有一個由補丁作者的 Signed-off-by 簽名。標記將在下面
    詳細描述。
 
-上面的項目一起構成補丁的變更日誌。寫一則好的變更日誌是一門至關重要但常常被
+上面的專案一起構成補丁的變更日誌。寫一則好的變更日誌是一門至關重要但常常被
 忽視的藝術；值得花一點時間來討論這個問題。當你編寫變更日誌時，你應該記住有
 很多不同的人會讀你的話。其中包括子系統維護人員和審查人員，他們需要決定是否
-應該合併補丁，分銷商和其他維護人員試圖決定是否應該將補丁反向移植到其他內核，
-缺陷搜尋人員想知道補丁是否導致他們正在追查的問題，以及想知道內核如何變化的
-用戶等等。一個好的變更日誌以最直接和最簡潔的方式向所有這些人傳達所需的信息。
+應該合併補丁，分銷商和其他維護人員試圖決定是否應該將補丁反向移植到其他核心，
+缺陷搜尋人員想知道補丁是否導致他們正在追查的問題，以及想知道核心如何變化的
+使用者等等。一個好的變更日誌以最直接和最簡潔的方式向所有這些人傳達所需的資訊。
 
 在結尾，總結行應該描述變更的影響和動機，以及在一行約束條件下可能發生的變化。
-然後，詳細的描述可以詳述這些主題，並提供任何需要的附加信息。如果補丁修復了
+然後，詳細的描述可以詳述這些主題，並提供任何需要的附加資訊。如果補丁修復了
 一個缺陷，請引用引入該缺陷的提交（如果可能，請在引用提交時同時提供其 id 和
 標題）。如果某個問題與特定的日誌或編譯器輸出相關聯，請包含該輸出以幫助其他
-人搜索同一問題的解決方案。如果更改是爲了支持以後補丁中的其他更改，那麼應當
+人搜索同一問題的解決方案。如果更改是為了支援以後補丁中的其他更改，那麼應當
 說明。如果更改了內部API，請詳細說明這些更改以及其他開發人員應該如何響應。
-一般來說，你越把自己放在每個閱讀你變更日誌的人的位置上，變更日誌（和內核
-作爲一個整體）就越好。
+一般來說，你越把自己放在每個閱讀你變更日誌的人的位置上，變更日誌（和核心
+作為一個整體）就越好。
 
-不需要說，變更日誌是將變更提交到版本控制系統時使用的文本。接下來將是：
+不需要說，變更日誌是將變更提交到版本控制系統時使用的文字。接下來將是：
 
- - 補丁本身，採用統一的（“-u”）補丁格式。使用“-p”選項來diff將使函數名與
+ - 補丁本身，採用統一的（“-u”）補丁格式。使用“-p”選項來diff將使函式名與
    更改相關聯，從而使結果補丁更容易被其他人讀取。
 
-上面提到的標籤（tag）用於描述各種開發人員如何與這個補丁的開發相關聯。
-:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <tw_submittingpatches>`
-文檔中對它們進行了詳細描述；下面是一個簡短的總結。每一行的格式如下：
+前面已簡要提到的標籤（tag）用於提供補丁如何產生的線索。
+:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
+文件中對它們進行了詳細描述；下面是一個簡短的總結。
 
-::
+有一種標籤用於引用引入了本補丁所修復問題的較早提交::
+
+	Fixes: 1f2e3d4c5b6a ("The first line of the commit specified by the first 12 characters of its SHA-1 ID")
+
+另一種標籤用於連結帶有額外背景或細節的網頁，例如導致此補丁的較早討論，或
+一份由此補丁實作的規格文件::
+
+	Link: https://example.com/somewhere.html  optional-other-stuff
+
+依照企鵝老大（Chief Penguin）的指導，只有當Link:標籤指向的有用資訊無法在
+提交本身中找到時，才應該把它加到提交中。
+
+如果URL指向此補丁所修復的公開缺陷報告，請改用“Closes:”標籤::
+
+	Closes: https://example.com/issues/1234  optional-other-stuff
+
+一些缺陷追蹤系統能夠在帶有此類標籤的提交被套用時自動關閉問題。一些監控
+郵件列表的機器人也會追蹤這類標籤並採取相應動作。私有缺陷追蹤系統和無效
+的URL是被禁止的。
+
+另一種標籤用於記錄誰參與了補丁的開發。它們每個都使用如下格式::
 
 	tag: Full Name <email address>  optional-other-stuff
 
 常用的標籤有：
 
- - Signed-off-by: 這是一個開發人員的證明，證明他或她有權提交補丁以包含到內核
-   中。這表明同意開發者來源認證協議，其全文見
-   :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <tw_submittingpatches>`
+ - Signed-off-by: 這是一個開發人員的證明，證明他或她有權提交補丁以包含到核
+   心中。這表明同意開發者來源認證協議，其全文見
+   :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
    如果沒有合適的簽字，則不能合併到主線中。
 
- - Co-developed-by: 聲明補丁是由多個開發人員共同創建的；當幾個人在一個補丁上
-   工作時，它用於給出共同作者（除了 From: 所給出的作者之外）。由於
-   Co-developed-by: 表示作者身份，所以每個共同開發人，必須緊跟在相關合作作者
-   的Signed-off-by之後。具體內容和示例見以下文件
-   :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <tw_submittingpatches>`
+ - Co-developed-by: 聲明補丁是由多個開發人員共同建立的；當幾個人在一個補丁
+   上工作時，它用於給出共同作者（除了 From: 所給出的作者之外）。由於
+   Co-developed-by: 表示作者身份，所以每個共同開發人，必須緊跟在相關合作作
+   者的Signed-off-by之後。具體內容和範例見以下文件
+   :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
 
- - Acked-by: 表示另一個開發人員（通常是相關代碼的維護人員）同意補丁適合包含
-   在內核中。
+ - Acked-by: 表示另一個開發人員（通常是相關程式碼的維護人員）同意補丁適合包含
+   在核心中。
 
  - Tested-by: 聲明某人已經測試了補丁並確認它可以工作。
 
- - Reviewed-by: 表示某開發人員已經審查了補丁的正確性；有關詳細信息，請參閱
-   :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <tw_submittingpatches>`
+ - Reviewed-by: 表示某開發人員已經審查了補丁的正確性；有關詳細資訊，請參閱
+   :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
+
+ - Reported-by: 指定報告此補丁修復的問題的使用者；此標籤用於向測試我們的
+   程式碼並在發現問題時告知我們的人們（他們常常沒有得到應有的重視）表示
+   感謝。注意，此標籤後面應跟隨指向該報告的Closes:標籤，除非該報告無法在
+   網路上取得。如果補丁只修復了所報告問題的一部分，可以用Link:標籤代替
+   Closes:。
 
- - Reported-by: 指定報告此補丁修復的問題的用戶；此標記用於表示感謝。
+ - Suggested-by: 標籤表明補丁的想法是由被指名者建議的，確保其想法獲得
+   讚譽。希望這能激勵他們在未來繼續幫助我們。
 
  - Cc：指定某人收到了補丁的副本，並有機會對此發表評論。
 
-在補丁中添加標籤時要小心：只有Cc:才適合在沒有指定人員明確許可的情況下添加。
+在補丁中添加上述標籤時要小心：除了Cc:、Reported-by:和Suggested-by:之外，
+所有標籤都需要被指名者的明確許可。對於這三個標籤，如果根據lore存檔或提交
+歷史，該人曾以該名字和電子郵件地址對Linux核心做出過貢獻，那麼隱含的許可
+就足夠了——並且對於Reported-by:和Suggested-by:，報告或建議必須是公開作出
+的。注意，就此而言bugzilla.kernel.org是公開場所，但其中使用的電子郵件地址
+是私密的；因此不要在標籤中暴露它們，除非該人在先前的貢獻中使用過。
 
 寄送補丁
 --------
 
 在寄送補丁之前，您還需要注意以下幾點：
 
- - 您確定您的郵件發送程序不會損壞補丁嗎？被郵件客戶端更改空白或修飾了行的補丁
+ - 您確定您的郵件發送程式不會損壞補丁嗎？被郵件客戶端更改空白或修飾了行的補丁
    無法被另一端接受，並且通常不會進行任何詳細檢查。如果有任何疑問，先把補丁寄
    給你自己，讓你自己確定它是完好無損的。
 
-   :ref:`Documentation/translations/zh_CN/process/email-clients.rst <tw_email_clients>`
+   :ref:`Documentation/translations/zh_TW/process/email-clients.rst <tw_email_clients>`
    提供了一些有用的提示，可以讓特定的郵件客戶端正常發送補丁。
 
- - 你確定你的補丁沒有荒唐的錯誤嗎？您應該始終通過scripts/checkpatch.pl檢查
-   補丁程序，並解決它提出的問題。請記住，checkpatch.pl，雖然體現了對內核補丁
+ - 你確定你的補丁沒有荒唐的錯誤嗎？您應該始終透過scripts/checkpatch.pl檢查
+   補丁程式，並解決它提出的問題。請記住，checkpatch.pl，雖然體現了對核心補丁
    應該是什麼樣的大量思考，但它並不比您聰明。如果修復checkpatch.pl給的問題會
-   使代碼變得更糟，請不要這樣做。
+   使程式碼變得更糟，請不要這樣做。
 
-補丁應始終以純文本形式發送。請不要將它們作爲附件發送；這使得審閱者在答覆中更難
-引用補丁的部分。相反，只需將補丁直接放到您的消息中。
+補丁應始終以純文字形式發送。請不要將它們作為附件發送；這使得審閱者在答覆中更難
+引用補丁的部分。相反，只需將補丁直接放到您的訊息中。
 
-寄出補丁時，重要的是將副本發送給任何可能感興趣的人。與其他一些項目不同，內核
-鼓勵人們甚至錯誤地發送過多的副本；不要假定相關人員會看到您在郵件列表中的發佈。
+寄出補丁時，重要的是將副本發送給任何可能感興趣的人。與其他一些專案不同，核心
+鼓勵人們甚至錯誤地發送過多的副本；不要假定相關人員會看到您在郵件列表中的發布。
 尤其是，副本應發送至：
 
- - 受影響子系統的維護人員。如前所述，維護人員文件是查找這些人員的首選地方。
+ - 受影響子系統的維護人員。如前所述，MAINTAINERS檔案是查找這些人員的首選地方。
 
- - 其他在同一領域工作的開發人員，尤其是那些現在可能在那裏工作的開發人員。使用
-   git查看還有誰修改了您正在處理的文件，這很有幫助。
+ - 其他在同一領域工作的開發人員，尤其是那些現在可能在那裡工作的開發人員。使用
+   git查看還有誰修改了您正在處理的檔案，這很有幫助。
 
  - 如果您對某錯誤報告或功能請求做出響應，也可以抄送原始發送人。
 
@@ -221,9 +258,9 @@
    補丁副本也應發到stable@vger.kernel.org 。另外，在補丁本身的標籤中添加一個
    “Cc: stable@vger.kernel.org”；這將使穩定版團隊在修復進入主線時收到通知。
 
-當爲一個補丁選擇接收者時，最好清楚你認爲誰最終會接受這個補丁並將其合併。雖然
+當為一個補丁選擇接收者時，最好清楚你認為誰最終會接受這個補丁並將其合併。雖然
 可以將補丁直接發給Linus Torvalds並讓他合併，但通常情況下不會這樣做。Linus很
-忙，並且有子系統維護人員負責監視內核的特定部分。通常您會希望維護人員合併您的
+忙，並且有子系統維護人員負責監視核心的特定部分。通常您會希望維護人員合併您的
 補丁。如果沒有明顯的維護人員，Andrew Morton通常是最後的補丁接收者。
 
 補丁需要好的主題行。補丁主題行的規範格式如下：
@@ -235,12 +272,12 @@
 其中“nn”是補丁的序號，“mm”是系列中補丁的總數，“subsys”是受影響子系統的
 名稱。當然，一個單獨的補丁可以省略nn/mm。
 
-如果您有一系列重要的補丁，那麼通常發送一個簡介作爲第〇部分。不過，這個約定
-並沒有得到普遍遵循；如果您使用它，請記住簡介中的信息不會進入內核變更日誌。
-因此，請確保補丁本身具有完整的變更日誌信息。
+如果您有一系列重要的補丁，那麼通常發送一個簡介作為第〇部分。不過，這個約定
+並沒有得到普遍遵循；如果您使用它，請記住簡介中的資訊不會進入核心變更日誌。
+因此，請確保補丁本身具有完整的變更日誌資訊。
 
-一般來說，多部分補丁的第二部分和後續部分應作爲對第一部分的回覆發送，以便它們
-在接收端都連接在一起。像git和coilt這樣的工具有命令，可以通過適當的線程發送
+一般來說，多部分補丁的第二部分和後續部分應作為對第一部分的回覆發送，以便它們
+在接收端都連接在一起。像git和coilt這樣的工具有命令，可以透過適當的執行緒發送
 一組補丁。但是，如果您有一長串補丁，並正使用git，請不要使用–-chain-reply-to
-選項，以避免創建過深的嵌套。
+選項，以避免建立過深的嵌套。
 
diff --git a/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst b/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst
index b449d67e3ad9..8090d482c4b0 100644
--- a/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst
+++ b/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst
@@ -12,28 +12,29 @@
 
  吳想成 Wu XiangCheng <bobwxc@email.cn>
  胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
+ 葉宸佑 Chen-Yu Yeh <chenyou910331@gmail.com>
 
 .. _tw_development_advancedtopics:
 
-高級主題
+進階主題
 ========
 
 現在，希望您能夠掌握開發流程的工作方式。然而，還有更多的東西要學！本節將介紹
-一些主題，這些主題對希望成爲Linux內核開發過程常規部分的開發人員有幫助。
+一些主題，這些主題對希望成為Linux核心開發過程常規部分的開發人員有幫助。
 
 使用Git管理補丁
 ---------------
 
-內核使用分佈式版本控制始於2002年初，當時Linus首次開始使用專有的Bitkeeper應用
-程序。雖然BitKeeper存在爭議，但它所體現的軟件版本管理方法卻肯定不是。分佈式
-版本控制可以立即加速內核開發項目。現在有好幾種免費的BitKeeper替代品。
-但無論好壞，內核項目都已經選擇了Git作爲其工具。
+核心使用分散式版本控制始於2002年初，當時Linus首次開始使用專有的Bitkeeper應用
+程式。雖然BitKeeper存在爭議，但它所體現的軟體版本管理方法卻肯定不是。分散式
+版本控制可以立即加速核心開發專案。現在有好幾種自由的BitKeeper替代品。
+但無論好壞，核心專案都已經選擇了Git作為其工具。
 
-使用Git管理補丁可以使開發人員的生活更加輕鬆，尤其是隨着補丁數量的增長。Git也
+使用Git管理補丁可以使開發人員的生活更加輕鬆，尤其是隨著補丁數量的增長。Git也
 有其粗糙的邊角和一定的危險性，它是一個年輕和強大的工具，仍然在其開發人員完善
-中。本文檔不會試圖教會讀者如何使用git；這會是個巨長的文檔。相反，這裏的重點
-將是Git如何特別適合內核開發過程。想要加快用Git速度的開發人員可以在以下網站上
-找到更多信息：
+中。本文件不會試圖教會讀者如何使用git；這會是個巨長的文件。相反，這裡的重點
+將是Git如何特別適合核心開發過程。想要加快用Git速度的開發人員可以在以下網站上
+找到更多資訊：
 
 	https://git-scm.com/
 
@@ -41,44 +42,44 @@
 
 同時網上也能找到各種各樣的教程。
 
-在嘗試使用它生成補丁供他人使用之前，第一要務是閱讀上述網頁，對Git的工作方式
-有一個紮實的瞭解。使用Git的開發人員應能進行拉取主線存儲庫的副本，查詢修訂
+在嘗試使用它產生補丁供他人使用之前，第一要務是閱讀上述網頁，對Git的工作方式
+有一個紮實的瞭解。使用Git的開發人員應能進行拉取主線儲存庫的副本，查詢修訂
 歷史，提交對樹的更改，使用分支等操作。瞭解Git用於重寫歷史的工具（如rebase）
-也很有用。Git有自己的術語和概念；Git的新用戶應該瞭解引用、遠程分支、索引、
-快進合併、推拉、遊離頭等。一開始可能有點嚇人，但這些概念不難通過一點學習來
+也很有用。Git有自己的術語和概念；Git的新使用者應該瞭解引用、遠端分支、索引、
+快進合併、推拉、遊離頭等。一開始可能有點嚇人，但這些概念不難透過一點學習來
 理解。
 
-使用git生成通過電子郵件提交的補丁是提高速度的一個很好的練習。
+使用git產生透過電子郵件提交的補丁是提高速度的一個很好的練習。
 
-當您準備好開始建立Git樹供其他人查看時，無疑需要一個可以從中拉取的服務器。
-如果您有一個可以訪問因特網的系統，那麼使用git-daemon設置這樣的服務器相對
-簡單。同時，免費的公共託管網站（例如github）也開始出現在網絡上。成熟的開發
-人員可以在kernel.org上獲得一個帳戶，但這些帳戶並不容易得到；更多有關信息，
+當您準備好開始建立Git樹供其他人查看時，無疑需要一個可以從中拉取的伺服器。
+如果您有一個可以連上網際網路的系統，那麼使用git-daemon設定這樣的伺服器相對
+簡單。同時，免費的公共託管網站（例如GitHub）也開始出現在網路上。成熟的開發
+人員可以在kernel.org上獲得一個帳戶，但這些帳戶並不容易得到；更多有關資訊，
 請參閱 https://kernel.org/faq/ 。
 
-正常的Git工作流程涉及到許多分支的使用。每一條開發線都可以分爲單獨的“主題
+正常的Git工作流程涉及到許多分支的使用。每一條開發線都可以分為單獨的“主題
 分支”，並獨立維護。Git的分支很容易使用，沒有理由不使用它們。而且，在任何
 情況下，您都不應該在任何您打算讓其他人從中拉取的分支中進行開發。應該小心地
-創建公開可用的分支；當開發分支處於完整狀態並已準備好時(而不是之前）才合併
+建立公開可用的分支；當開發分支處於完整狀態並已準備好時(而不是之前）才合併
 開發分支的補丁。
 
 Git提供了一些強大的工具，可以讓您重寫開發歷史。一個不方便的補丁（比如說，
 一個打破二分法的補丁，或者有其他一些明顯的缺陷）可以在適當的位置修復，或者
 完全從歷史中消失。一個補丁系列可以被重寫，就好像它是在今天的主線上寫的一樣，
 即使你已經花了幾個月的時間在寫它。可以透明地將更改從一個分支轉移到另一個
-分支。等等。明智地使用git修改歷史的能力可以幫助創建問題更少的乾淨補丁集。
+分支。等等。明智地使用git修改歷史的能力可以幫助建立問題更少的乾淨補丁集。
 
-然而，過度使用這種功能可能會導致其他問題，而不僅僅是對創建完美項目歷史的
-簡單癡迷。重寫歷史將重寫該歷史中包含的更改，將經過測試（希望如此）的內核樹
-變爲未經測試的內核樹。除此之外，如果開發人員沒有共享項目歷史，他們就無法
-輕鬆地協作；如果您重寫了其他開發人員拉入他們存儲庫的歷史，您將使這些開發
-人員的生活更加困難。因此，這裏有一個簡單的經驗法則：被導出到其他地方的歷史
-在此後通常被認爲是不可變的。
+然而，過度使用這種功能可能會導致其他問題，而不僅僅是對建立完美專案歷史的
+簡單癡迷。重寫歷史將重寫該歷史中包含的更改，將經過測試（希望如此）的核心樹
+變為未經測試的核心樹。除此之外，如果開發人員沒有共享專案歷史，他們就無法
+輕鬆地協作；如果您重寫了其他開發人員拉入他們儲存庫的歷史，您將使這些開發
+人員的生活更加困難。因此，這裡有一個簡單的經驗法則：被導出到其他地方的歷史
+在此後通常被認為是不可變的。
 
-因此，一旦將一組更改推送到公開可用的服務器上，就不應該重寫這些更改。如果您
+因此，一旦將一組更改推送到公開可用的伺服器上，就不應該重寫這些更改。如果您
 嘗試強制進行無法快進合併的更改（即不共享同一歷史記錄的更改），Git將嘗試強制
 執行此規則。這可能覆蓋檢查，有時甚至需要重寫導出的樹。在樹之間移動變更集以
-避免linux-next中的衝突就是一個例子。但這種行爲應該是罕見的。這就是爲什麼
+避免linux-next中的衝突就是一個例子。但這種行為應該是罕見的。這就是為什麼
 開發應該在私有分支中進行（必要時可以重寫）並且只有在公共分支處於合理的較新
 狀態時才轉移到公共分支中的原因之一。
 
@@ -86,52 +87,53 @@ Git提供了一些強大的工具，可以讓您重寫開發歷史。一個不�
 對於一個私有的分支，rebasing 可能是一個很容易跟上另一棵樹的方法，但是一旦
 一棵樹被導出到外界，rebasing就不可取了。一旦發生這種情況，就必須進行完全
 合併（merge）。合併有時是很有意義的，但是過於頻繁的合併會不必要地擾亂歷史。
-在這種情況下建議的做法是不要頻繁合併，通常只在特定的發佈點（如主線-rc發佈）
+在這種情況下建議的做法是不要頻繁合併，通常只在特定的發布點（如主線-rc發布）
 合併。如果您對特定的更改感到緊張，則可以始終在私有分支中執行測試合併。在
 這種情況下，git“rerere”工具很有用；它能記住合併衝突是如何解決的，這樣您
 就不必重複相同的工作。
 
-關於Git這樣的工具的一個最大的反覆抱怨是：補丁從一個存儲庫到另一個存儲庫的
+關於Git這樣的工具的一個最大的反覆抱怨是：補丁從一個儲存庫到另一個儲存庫的
 大量移動使得很容易陷入錯誤建議的變更中，這些變更避開審查雷達進入主線。當內
 核開發人員看到這種情況發生時，他們往往會感到不高興；在Git樹上放置未審閱或
 主題外的補丁可能會影響您將來讓樹被拉取的能力。引用Linus的話:
 
 ::
 
-   你可以給我發補丁，但當我從你那裏拉取一個Git補丁時，我需要知道你清楚
+   你可以給我發補丁，但當我從你那裡拉取一個Git補丁時，我需要知道你清楚
    自己在做什麼，我需要能夠相信事情而 *無需* 手動檢查每個單獨的更改。
 
 （http://lwn.net/Articles/224135/）。
 
-爲了避免這種情況，請確保給定分支中的所有補丁都與相關主題緊密相關；“驅動程序
-修復”分支不應更改核心內存管理代碼。而且，最重要的是，不要使用Git樹來繞過
-審查過程。不時的將樹的摘要發佈到相關的列表中，在合適時候請求linux-next中
+為了避免這種情況，請確保給定分支中的所有補丁都與相關主題緊密相關；“驅動程式
+修復”分支不應更改核心記憶體管理程式碼。而且，最重要的是，不要使用Git樹來繞過
+審查過程。不時的將樹的摘要發布到相關的列表中，在合適時候請求linux-next中
 包含該樹。
 
 如果其他人開始發送補丁以包含到您的樹中，不要忘記審閱它們。還要確保您維護正確
-的作者信息； git “am”工具在這方面做得最好，但是如果補丁通過第三方轉發給您，
+的作者資訊； git “am”工具在這方面做得最好，但是如果補丁透過第三方轉發給您，
 您可能需要在補丁中添加“From:”行。
 
-請求拉取時，請務必提供所有相關信息：樹的位置、要拉取的分支以及拉取將導致的
+請求拉取時，請務必提供所有相關資訊：樹的位置、要拉取的分支以及拉取將導致的
 更改。在這方面 git request-pull 命令非常有用；它將按照其他開發人員所期望的
-格式化請求，並檢查以確保您已記得將這些更改推送到公共服務器。
+格式化請求，並檢查以確保您已記得將這些更改推送到公共伺服器。
 
 審閱補丁
 --------
 
-一些讀者顯然會反對將本節與“高級主題”放在一起，因爲即使是剛開始的內核開發人員
-也應該審閱補丁。當然，沒有比查看其他人發佈的代碼更好的方法來學習如何在內核環境
-中編程了。此外，審閱者永遠供不應求；通過審閱代碼，您可以對整個流程做出重大貢獻。
-
-審查代碼可能是一副令人生畏的圖景，特別是對一個新的內核開發人員來說，他們
-可能會對公開詢問代碼感到緊張，而這些代碼是由那些有更多經驗的人發佈的。不過，
-即使是最有經驗的開發人員編寫的代碼也可以得到改進。也許對（所有）審閱者最好
-的建議是：把審閱評論當成問題而不是批評。詢問“在這條路徑中如何釋放鎖？”
-總是比說“這裏的鎖是錯誤的”更好。
-
-不同的開發人員將從不同的角度審查代碼。部分人會主要關注代碼風格以及代碼行是
-否有尾隨空格。其他人會主要關注補丁作爲一個整體實現的變更是否對內核有好處。
-同時也有人會檢查是否存在鎖問題、堆棧使用過度、可能的安全問題、在其他地方
-發現的代碼重複、足夠的文檔、對性能的不利影響、用戶空間ABI更改等。所有類型
-的檢查，只要它們能引導更好的代碼進入內核，都是受歡迎和值得的。
+一些讀者顯然會反對將本節與“進階主題”放在一起，因為即使是剛開始的核心開發人
+員也應該審閱補丁。當然，沒有比查看其他人發布的程式碼更好的方法來學習如何在
+核心環境中撰寫程式了。此外，審閱者永遠供不應求；透過審閱程式碼，您可以對整
+個流程做出重大貢獻。
+
+審查程式碼可能是一副令人生畏的圖景，特別是對一個新的核心開發人員來說，他們
+可能會對公開詢問程式碼感到緊張，而這些程式碼是由那些有更多經驗的人發布的。
+不過，即使是最有經驗的開發人員編寫的程式碼也可以得到改進。也許對（所有）審
+閱者最好的建議是：把審閱評論當成問題而不是批評。詢問“在這條路徑中如何釋放
+鎖？”總是比說“這裡的鎖是錯誤的”更好。
+
+不同的開發人員將從不同的角度審查程式碼。部分人會主要關注程式碼風格以及程式
+碼行是否有尾隨空格。其他人會主要關注補丁作為一個整體實作的變更是否對核心有
+好處。同時也有人會檢查是否存在鎖問題、堆疊使用過度、可能的安全問題、在其他
+地方發現的程式碼重複、足夠的文件、對效能的不利影響、使用者空間ABI更改等。
+所有類型的檢查，只要它們能引導更好的程式碼進入核心，都是受歡迎和值得的。
 
diff --git a/Documentation/translations/zh_TW/process/8.Conclusion.rst b/Documentation/translations/zh_TW/process/8.Conclusion.rst
index d1634421b62c..8f9b4ec6845f 100644
--- a/Documentation/translations/zh_TW/process/8.Conclusion.rst
+++ b/Documentation/translations/zh_TW/process/8.Conclusion.rst
@@ -11,45 +11,46 @@
 
  吳想成 Wu XiangCheng <bobwxc@email.cn>
  胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
+ 葉宸佑 Chen-Yu Yeh <chenyou910331@gmail.com>
 
 .. _tw_development_conclusion:
 
-更多信息
+更多資訊
 ========
 
-關於Linux內核開發和相關主題的信息來源很多。首先是在內核源代碼分發中找到的
-文檔目錄。頂級
-:ref:`Documentation/translations/zh_CN/process/howto.rst <tw_process_howto>`
+關於Linux核心開發和相關主題的資訊來源很多。首先是在核心原始碼分發中找到的
+文件目錄。頂級
+:ref:`Documentation/translations/zh_TW/process/howto.rst <tw_process_howto>`
 文件是一個重要的起點；
-:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <tw_submittingpatches>`
-也是所有內核開發人員都應該閱讀的內容。許多內部內核API都是使用kerneldoc機制
-記錄的；“make htmldocs”或“make pdfdocs”可用於以HTML或PDF格式生成這些文檔
-（儘管某些發行版提供的tex版本會遇到內部限制，無法正確處理文檔）。
+:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
+也是所有核心開發人員都應該閱讀的內容。許多內部核心API都是使用kerneldoc機制
+記錄的；“make htmldocs”或“make pdfdocs”可用於以HTML或PDF格式產生這些文件
+（儘管某些發行版提供的tex版本會遇到內部限制，無法正確處理文件）。
 
-不同的網站在各個細節層次上討論內核開發。本文作者想謙虛地建議用 https://lwn.net/
-作爲來源；有關許多特定內核主題的信息可以通過以下網址的 LWN 內核索引找到：
+不同的網站在各個細節層次上討論核心開發。本文作者想謙虛地建議用 https://lwn.net/
+作為來源；有關許多特定核心主題的資訊可以透過以下網址的 LWN 核心索引找到：
 
-  http://lwn.net/kernel/index/
+  https://lwn.net/Kernel/Index/
 
-除此之外，內核開發人員的一個寶貴資源是：
+除此之外，核心開發人員的一個寶貴資源是：
 
   https://kernelnewbies.org/
 
-當然，也不應該忘記 https://kernel.org/ ，這是內核發佈信息的最終位置。
+當然，也不應該忘記 https://kernel.org/ ，這是核心發布資訊的最終位置。
 
-關於內核開發有很多書：
+關於核心開發有很多書：
 
-  《Linux設備驅動程序》第三版（Jonathan Corbet、Alessandro Rubini和Greg Kroah Hartman）
-  線上版本在 http://lwn.net/kernel/ldd3/
+  《Linux設備驅動程序》第三版（Jonathan Corbet、Alessandro Rubini和Greg Kroah-Hartman）
+  線上版本在 https://lwn.net/Kernel/LDD3/
 
-  《Linux內核設計與實現》（Robert Love）
+  《Linux核心設計與實現》（Robert Love）
 
-  《深入理解Linux內核》(Daniel Bovet和Marco Cesati）
+  《深入理解Linux核心》(Daniel Bovet和Marco Cesati）
 
 然而，所有這些書都有一個共同的缺點：它們上架時就往往有些過時，而且已經上架
-一段時間了。不過，在那裏還是可以找到相當多的好信息。
+一段時間了。不過，在那裡還是可以找到相當多的好資訊。
 
-有關git的文檔，請訪問：
+有關git的文件，請造訪：
 
   https://www.kernel.org/pub/software/scm/git/docs/
 
@@ -58,16 +59,17 @@
 結論
 ====
 
-祝賀所有通過這篇冗長的文檔的人。希望它能夠幫助您理解Linux內核是如何開發的，
+祝賀所有通過這篇冗長的文件的人。希望它能夠幫助您理解Linux核心是如何開發的，
 以及您如何參與這個過程。
 
-最後，重要的是參與。任何開源軟件項目都不會超過其貢獻者投入其中的總和。Linux
-內核的發展速度和以前一樣快，因爲它得到了大量開發人員的幫助，他們都在努力使它
-變得更好。內核是一個最成功的例子，說明了當成千上萬的人爲了一個共同的目標一起
+最後，重要的是參與。任何開源軟體專案都不會超過其貢獻者投入其中的總和。Linux
+核心的發展速度和以前一樣快，因為它得到了大量開發人員的幫助，他們都在努力使它
+變得更好。核心是一個最成功的例子，說明了當成千上萬的人為了一個共同的目標一起
 工作時，可以做出什麼。
 
-不過，內核總是可以從更大的開發人員基礎中獲益。總有更多的工作要做。但是同樣
-重要的是，Linux生態系統中的大多數其他參與者可以通過爲內核做出貢獻而受益。使
-代碼進入主線是提高代碼質量、降低維護和分發成本、提高對內核開發方向的影響程度
-等的關鍵。這是一種共贏的局面。啓動你的編輯器，來加入我們吧；你會非常受歡迎的。
+不過，核心總是可以從更大的開發人員基礎中獲益。總有更多的工作要做。但是同樣
+重要的是，Linux生態系統中的大多數其他參與者可以透過為核心做出貢獻而受益。
+使程式碼進入主線是提高程式碼品質、降低維護和分發成本、提高對核心開發方向的
+影響程度等的關鍵。這是一種共贏的局面。啟動你的編輯器，來加入我們吧；你會非
+常受歡迎的。
 
diff --git a/Documentation/translations/zh_TW/process/code-of-conduct-interpretation.rst b/Documentation/translations/zh_TW/process/code-of-conduct-interpretation.rst
index fbe66b001322..897faa825d12 100644
--- a/Documentation/translations/zh_TW/process/code-of-conduct-interpretation.rst
+++ b/Documentation/translations/zh_TW/process/code-of-conduct-interpretation.rst
@@ -5,108 +5,172 @@
 :Original: :ref:`Documentation/process/code-of-conduct-interpretation.rst <code_of_conduct_interpretation>`
 :Translator: Alex Shi <alex.shi@linux.alibaba.com>
              Hu Haowen <2023002089@link.tyut.edu.cn>
+             Chen-Yu Yeh <chenyou910331@gmail.com>
 
 .. _tw_code_of_conduct_interpretation:
 
-Linux內核貢獻者契約行爲準則解釋
+Linux核心貢獻者契約行為準則解釋
 ===============================
 
-:ref:`tw_code_of_conduct` 準則是一個通用文檔，旨在爲幾乎所有開源社區提供一套規則。
-每個開源社區都是獨一無二的，Linux內核也不例外。因此，本文描述了Linux內核社區中
-如何解釋它。我們也不希望這種解釋隨着時間的推移是靜態的，並將根據需要進行調整。
+:ref:`tw_code_of_conduct` 準則是一個通用文件，旨在為幾乎所有開源社群提供一套規則。
+每個開源社群都是獨一無二的，Linux核心也不例外。因此，本文描述了Linux核心社群中
+如何解釋它。我們也不希望這種解釋隨著時間的推移是靜態的，並將根據需要進行調整。
 
-與開發軟件的“傳統”方法相比，Linux內核開發工作是一個非常個人化的過程。你的貢獻
+與開發軟體的“傳統”方法相比，Linux核心開發工作是一個非常個人化的過程。你的貢獻
 和背後的想法將被仔細審查，往往導致批判和批評。審查將幾乎總是需要改進，材料才
-能包括在內核中。要知道這是因爲所有相關人員都希望看到Linux整體成功的最佳解決方
-案。這個開發過程已經被證明可以創建有史以來最健壯的操作系統內核，我們不想做任何
-事情來導致提交質量和最終結果的下降。
+能包括在核心中。要知道這是因為所有相關人員都希望看到Linux整體成功的最佳解決方
+案。這個開發過程已經被證明可以建立有史以來最強健的作業系統核心，我們不想做任何
+事情來導致提交品質和最終結果的下降。
 
 維護者
 ------
 
-行爲準則多次使用“維護者”一詞。在內核社區中，“維護者”是負責子系統、驅動程序或
-文件的任何人，並在內核源代碼樹的維護者文件中列出。
+行為準則多次使用“維護者”一詞。在核心社群中，“維護者”是負責子系統、驅動程式或
+文件的任何人，並在核心原始程式碼樹的維護者文件中列出。
 
 責任
 ----
 
-《行爲準則》提到了維護人員的權利和責任，這需要進一步澄清。
+《行為準則》提到了維護人員的權利和責任，這需要進一步澄清。
 
-首先，最重要的是，有一個合理的期望是由維護人員通過實例來領導。
+首先，最重要的是，有一個合理的期望是由維護人員透過實例來領導。
 
-也就是說，我們的社區是廣闊的，對維護者沒有新的要求，他們單方面處理其他人在
-他們活躍的社區的行爲。這一責任由我們所有人承擔，最終《行爲準則》記錄了最終的
-上訴路徑，以防有關行爲問題的問題懸而未決。
+也就是說，我們的社群是廣闊的，對維護者沒有新的要求，他們單方面處理其他人在
+他們活躍的社群的行為。這一責任由我們所有人承擔，最終《行為準則》記錄了最終的
+上訴路徑，以防有關行為問題的問題懸而未決。
 
-維護人員應該願意在出現問題時提供幫助，並在需要時與社區中的其他人合作。如果您
+維護人員應該願意在出現問題時提供幫助，並在需要時與社群中的其他人合作。如果您
 不確定如何處理出現的情況，請不要害怕聯繫技術諮詢委員會（TAB）或其他維護人員。
-除非您願意，否則不會將其視爲違規報告。如果您不確定是否該聯繫TAB 或任何其他維
+除非您願意，否則不會將其視為違規報告。如果您不確定是否該聯繫TAB 或任何其他維
 護人員，請聯繫我們的衝突調解人 Mishi Choudhary <mishi@linux.com>。
 
-最後，“善待對方”纔是每個人的最終目標。我們知道每個人都是人，有時我們都會失敗，
-但我們所有人的首要目標應該是努力友好地解決問題。執行行爲準則將是最後的選擇。
+最後，“善待對方”才是每個人的最終目標。我們知道每個人都是人，有時我們都會失敗，
+但我們所有人的首要目標應該是努力友好地解決問題。執行行為準則將是最後的選擇。
 
-我們的目標是創建一個強大的、技術先進的操作系統，以及所涉及的技術複雜性，這自
+我們的目標是建立一個強大的、技術先進的作業系統，以及所涉及的技術複雜性，這自
 然需要專業知識和決策。
 
 所需的專業知識因貢獻領域而異。它主要由上下文和技術複雜性決定，其次由貢獻者和
 維護者的期望決定。
 
-專家的期望和決策都要經過討論，但在最後，爲了取得進展，必須能夠做出決策。這一
-特權掌握在維護人員和項目領導的手中，預計將善意使用。
+專家的期望和決策都要經過討論，但在最後，為了取得進展，必須能夠做出決策。這一
+特權掌握在維護人員和專案領導的手中，預計將善意使用。
 
-因此，設定專業知識期望、作出決定和拒絕不適當的貢獻不被視爲違反行爲準則。
+因此，設定專業知識期望、作出決定和拒絕不適當的貢獻不被視為違反行為準則。
 
 雖然維護人員一般都歡迎新來者，但他們幫助（新）貢獻者克服障礙的能力有限，因此
-他們必須確定優先事項。這也不應被視爲違反了行爲準則。內核社區意識到這一點，並
+他們必須確定優先事項。這也不應被視為違反了行為準則。核心社群意識到這一點，並
 以各種形式提供入門級節目，如 kernelnewbies.org 。
 
 範圍
 ----
 
-Linux內核社區主要在一組公共電子郵件列表上進行交互，這些列表分佈在由多個不同
-公司或個人控制的多個不同服務器上。所有這些列表都在內核源代碼樹中的
-MAINTAINERS 文件中定義。發送到這些郵件列表的任何電子郵件都被視爲包含在行爲
+Linux核心社群主要在一組公共電子郵件列表上進行交互，這些列表分佈在由多個不同
+公司或個人控制的多個不同伺服器上。所有這些列表都在核心原始程式碼樹中的
+MAINTAINERS 文件中定義。發送到這些郵件列表的任何電子郵件都被視為包含在行為
 準則中。
 
-使用 kernel.org bugzilla和其他子系統bugzilla 或bug跟蹤工具的開發人員應該遵循
-行爲準則的指導原則。Linux內核社區沒有“官方”項目電子郵件地址或“官方”社交媒體
-地址。使用kernel.org電子郵件帳戶執行的任何活動必須遵循爲kernel.org發佈的行爲
+使用 kernel.org bugzilla和其他子系統bugzilla 或bug追蹤工具的開發人員應該遵循
+行為準則的指導原則。Linux核心社群沒有“官方”專案電子郵件地址或“官方”社交媒體
+地址。使用kernel.org電子郵件帳戶執行的任何活動必須遵循為kernel.org發布的行為
 準則，就像任何使用公司電子郵件帳戶的個人必須遵循該公司的特定規則一樣。
 
-行爲準則並不禁止在郵件列表消息、內核更改日誌消息或代碼註釋中繼續包含名稱、
-電子郵件地址和相關注釋。
+行為準則並不禁止在郵件列表消息、核心更改日誌消息或程式碼註解中繼續包含名稱、
+電子郵件地址和相關註解。
 
-其他論壇中的互動包括在適用於上述論壇的任何規則中，通常不包括在行爲準則中。
+其他論壇中的互動包括在適用於上述論壇的任何規則中，通常不包括在行為準則中。
 除了在極端情況下可考慮的例外情況。
 
-提交給內核的貢獻應該使用適當的語言。在行爲準則之前已經存在的內容現在不會被
-視爲違反。然而，不適當的語言可以被視爲一個bug；如果任何相關方提交補丁，
-這樣的bug將被更快地修復。當前屬於用戶/內核API的一部分的表達式，或者反映已
-發佈標準或規範中使用的術語的表達式，不被視爲bug。
+提交給核心的貢獻應該使用適當的語言。在行為準則之前已經存在的內容現在不會被
+視為違反。然而，不適當的語言可以被視為一個bug；如果任何相關方提交補丁，
+這樣的bug將被更快地修復。當前屬於使用者/核心API的一部分的表達式，或者反映已
+發布標準或規範中使用的術語的表達式，不被視為bug。
 
 執行
 ----
 
-行爲準則中列出的地址屬於行爲準則委員會。https://kernel.org/code-of-conduct.html
-列出了在任何給定時間接收這些電子郵件的確切成員。成員不能訪問在加入委員會之前
+行為準則中列出的地址屬於行為準則委員會。https://kernel.org/code-of-conduct.html
+列出了在任何給定時間接收這些電子郵件的確切成員。成員不能存取在加入委員會之前
 或離開委員會之後所做的報告。
 
-最初的行爲準則委員會由TAB的志願者以及作爲中立第三方的專業調解人組成。委員會
-的首要任務是建立文件化的流程，並將其公開。
+行為準則委員會由TAB任命的社群志願者成員以及作為中立第三方的專業調解人組成。
+行為準則委員會處理報告所使用的流程各不相同，將取決於個別情況，但本文件可
+作為其所使用之一般流程的說明。
 
 如果報告人不希望將整個委員會納入投訴或關切，可直接聯繫委員會的任何成員，包括
 調解人。
 
-行爲準則委員會根據流程審查案例（見上文），並根據需要和適當與TAB協商，例如請求
-和接收有關內核社區的信息。
+行為準則委員會根據流程審查案例（見上文），並根據需要和適當與TAB協商，例如請求
+和接收有關核心社群的資訊。
 
-委員會做出的任何決定都將提交到表中，以便在必要時與相關維護人員一起執行。行爲
-準則委員會的決定可以通過三分之二的投票推翻。
+任何有關執法建議的決定都將提交給TAB，以便在必要時與相關維護人員一起實施
+執法。一旦TAB以參與表決成員的三分之二多數批准了禁令範圍中列出的一項或多項
+措施，行為準則委員會將執行TAB批准的措施。任何同時在TAB任職的行為準則委員會
+成員不參與對這些措施的表決。
 
-每季度，行爲準則委員會和標籤將提供一份報告，概述行爲準則委員會收到的匿名報告
-及其狀態，以及任何否決決定的細節，包括完整和可識別的投票細節。
+每季度，行為準則委員會和TAB將提供一份報告，概述行為準則委員會收到的匿名
+報告及其狀態，以及任何TAB批准之決定的細節，包括完整和可識別的投票細節。
 
-我們希望在啓動期之後爲行爲準則委員會人員配備建立一個不同的流程。發生此情況時，
-將使用該信息更新此文檔。
+由於我們對行為準則的解釋和執行會隨著時間演變，本文件將在必要時更新，以反映
+任何變化。
+
+不可接受行為之行為準則違規的執法
+--------------------------------
+
+行為準則委員會致力於確保我們的社群持續具有包容性，促進多元的討論和觀點，並
+致力於隨著時間改進這些特質。行為準則委員會收到的大多數報告，源於對開發過程
+以及維護者的角色、責任及其對程式碼接受與否的決定權的錯誤理解。這些報告透過
+澄清開發過程和行為準則的範圍來解決。
+
+不可接受的行為可能在短時間內中斷相互尊重的協作，並對社群的健康造成長期的
+負面影響。當個人在違規發生的場合承認自己的行為並加以糾正時，不可接受的行為
+通常就能得到解決。
+
+當不可接受的行為未能透過社群討論解決時，行為準則委員會會收到相關報告。當
+不可接受的行為對相互尊重的協作關係造成負面影響時，行為準則委員會會採取措施
+恢復有成效且相互尊重的協作。
+
+行為準則委員會有義務對報告和報告者的資訊保密。報告可能來自受害方，也可能
+來自目睹不可接受行為的社群成員。行為準則委員會有責任與所有相關方合作，對這
+類報告進行調查並予以處理。
+
+行為準則委員會與當事人合作，促使其理解以下事項的重要性：修復其行為對受害方
+造成的傷害，以及對社群的長期負面影響。
+
+目標是達成所有各方都能接受的解決方案。如果與當事人的合作未能達到預期的結果，
+行為準則委員會將評估其他措施，例如要求公開道歉以修復傷害。
+
+要求為違規行為公開道歉
+~~~~~~~~~~~~~~~~~~~~~~
+
+行為準則委員會在違規發生的場合公開指出該行為，要求為違規行為公開道歉。
+
+為違規行為公開道歉是重建信任的第一步。信任對於一個以信任和尊重運作的社群的
+持續成功和健康至關重要。
+
+若未為違規行為公開道歉的補救措施
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+行為準則委員會透過向TAB建議補救措施以供批准，決定恢復健康協作的下一步行動。
+
+- 禁止違規者參與核心開發過程，期限最長可達一個完整的核心開發週期。行為準則
+  委員會可以要求公開道歉作為解除禁令的條件。
+
+一段時間內禁令的範圍可能包括：
+
+    a. 拒絕其補丁貢獻和拉取請求
+    b. 透過忽略其貢獻和/或封鎖其電子郵件帳戶，暫停與違規者的協作
+    c. 限制其透過kernel.org平臺（如郵件列表和社交媒體網站）進行交流的能力
+
+一旦TAB以參與表決成員的三分之二多數批准了禁令範圍中列出的一項或多項措施，
+行為準則委員會將與社群、維護人員、子維護人員和kernel.org管理員合作，執行
+TAB批准的措施。任何同時在TAB任職的行為準則委員會成員不參與對這些措施的表決。
+
+行為準則委員會深知要求公開道歉和實施禁令可能對個人造成的負面影響。它也深知
+在發生此類嚴重的公開違規行為時不採取行動可能對社群造成的長期傷害。
+
+TAB批准的補救措施的有效性，取決於社群、維護人員、子維護人員和kernel.org
+管理員在執行這些措施時的信任與合作。
+
+行為準則委員會衷心希望，需要要求公開道歉的不可接受行為，在未來仍然極為罕見。
 
diff --git a/Documentation/translations/zh_TW/process/coding-style.rst b/Documentation/translations/zh_TW/process/coding-style.rst
index 63c78982a1af..ef7a4cdbff37 100644
--- a/Documentation/translations/zh_TW/process/coding-style.rst
+++ b/Documentation/translations/zh_TW/process/coding-style.rst
@@ -18,39 +18,40 @@
  - Li Zefan <lizf@cn.fujitsu.com>
  - Wang Chen <wangchen@cn.fujitsu.com>
  - Hu Haowen <2023002089@link.tyut.edu.cn>
+ - 葉宸佑 Chen-Yu Yeh <chenyou910331@gmail.com>
 
-Linux 內核代碼風格
-==================
+Linux 核心程式碼風格
+====================
 
-這是一個簡短的文檔，描述了 linux 內核的首選代碼風格。代碼風格是因人而異的，
-而且我不願意把自己的觀點強加給任何人，但這就像我去做任何事情都必須遵循的原則
-那樣，我也希望在絕大多數事上保持這種的態度。請 (在寫代碼時) 至少考慮一下這裏
-的代碼風格。
+這是一個簡短的文件，描述了 linux 核心的首選程式碼風格。程式碼風格是因人而
+異的，而且我不願意把自己的觀點強加給任何人，但這就像我去做任何事情都必須遵
+循的原則那樣，我也希望在絕大多數事上保持這種的態度。請 (在寫程式碼時) 至少
+考慮一下這裡的程式碼風格。
 
-首先，我建議你打印一份 GNU 代碼規範，然後不要讀。燒了它，這是一個具有重大象徵
-性意義的動作。
+首先，我建議你列印一份 GNU 程式碼規範，然後不要讀。燒了它，這是一個具有重
+大象徵性意義的動作。
 
 不管怎樣，現在我們開始：
 
 
-1) 縮進
+1) 縮排
 -------
 
-製表符是 8 個字符，所以縮進也是 8 個字符。有些異端運動試圖將縮進變爲 4 (甚至
-2！) 字符深，這幾乎相當於嘗試將圓周率的值定義爲 3。
+製表符是 8 個字元，所以縮排也是 8 個字元。有些異端運動試圖將縮排變為 4 (甚至
+2！) 字元深，這幾乎相當於嘗試將圓周率的值定義為 3。
 
-理由：縮進的全部意義就在於清楚的定義一個控制塊起止於何處。尤其是當你盯着你的
-屏幕連續看了 20 小時之後，你將會發現大一點的縮進會使你更容易分辨縮進。
+理由：縮排的全部意義就在於清楚的定義一個控制塊起止於何處。尤其是當你盯著你的
+屏幕連續看了 20 小時之後，你將會發現大一點的縮排會使你更容易分辨縮排。
 
-現在，有些人會抱怨 8 個字符的縮進會使代碼向右邊移動的太遠，在 80 個字符的終端
-屏幕上就很難讀這樣的代碼。這個問題的答案是，如果你需要 3 級以上的縮進，不管用
-何種方式你的代碼已經有問題了，應該修正你的程序。
+現在，有些人會抱怨 8 個字元的縮排會使程式碼向右邊移動的太遠，在 80 個字元
+的終端屏幕上就很難讀這樣的程式碼。這個問題的答案是，如果你需要 3 級以上的
+縮排，不管用何種方式你的程式碼已經有問題了，應該修正你的程式。
 
-簡而言之，8 個字符的縮進可以讓代碼更容易閱讀，還有一個好處是當你的函數嵌套太
+簡而言之，8 個字元的縮排可以讓程式碼更容易閱讀，還有一個好處是當你的函式嵌套太
 深的時候可以給你警告。留心這個警告。
 
-在 switch 語句中消除多級縮進的首選的方式是讓 ``switch`` 和從屬於它的 ``case``
-標籤對齊於同一列，而不要 ``兩次縮進`` ``case`` 標籤。比如：
+在 switch 語句中消除多級縮排的首選的方式是讓 ``switch`` 和從屬於它的 ``case``
+標籤對齊於同一列，而不要 ``兩次縮排`` ``case`` 標籤。比如：
 
 .. code-block:: c
 
@@ -71,7 +72,7 @@ Linux 內核代碼風格
 		break;
 	}
 
-不要把多個語句放在一行裏，除非你有什麼東西要隱藏：
+不要把多個語句放在一行裡，除非你有什麼東西要隱藏：
 
 .. code-block:: c
 
@@ -94,37 +95,38 @@ Linux 內核代碼風格
 		do_that();
 	}
 
-也不要在一行裏放多個賦值語句。內核代碼風格超級簡單。就是避免可能導致別人誤讀
+也不要在一行裡放多個賦值語句。核心程式碼風格超級簡單。就是避免可能導致別人誤讀
 的表達式。
 
-除了註釋、文檔和 Kconfig 之外，不要使用空格來縮進，前面的例子是例外，是有意爲
+除了註解、文件和 Kconfig 之外，不要使用空格來縮排，前面的例子是例外，是有意為
 之。
 
 選用一個好的編輯器，不要在行尾留空格。
 
 
-2) 把長的行和字符串打散
+2) 把長的行和字串打散
 -----------------------
 
-代碼風格的意義就在於使用平常使用的工具來維持代碼的可讀性和可維護性。
+程式碼風格的意義就在於使用平常使用的工具來維持程式碼的可讀性和可維護性。
 
 每一行的長度的限制是 80 列，我們強烈建議您遵守這個慣例。
 
 長於 80 列的語句要打散成有意義的片段。除非超過 80 列能顯著增加可讀性，並且不
-會隱藏信息。
+會隱藏資訊。
 
-子片段要明顯短於母片段，並明顯靠右。一種非常常用的樣式是將子體與函數左括號對齊。
+子片段要明顯短於母片段，並明顯靠右。一種非常常用的樣式是將子體與函式左括號
+對齊。
 
-這同樣適用於有着很長參數列表的函數頭。
+這同樣適用於有著很長參數列表的函式頭。
 
-然而，絕對不要打散對用戶可見的字符串，例如 printk 信息，因爲這樣就
+然而，絕對不要打散對使用者可見的字串，例如 printk 資訊，因為這樣就
 很難對它們 grep。
 
 
 3) 大括號和空格的放置
 ---------------------
 
-C 語言風格中另外一個常見問題是大括號的放置。和縮進大小不同，選擇或棄用某種放
+C 語言風格中另外一個常見問題是大括號的放置。和縮排大小不同，選擇或棄用某種放
 置策略並沒有多少技術上的原因，不過首選的方式，就像 Kernighan 和 Ritchie 展示
 給我們的，是把起始大括號放在行尾，而把結束大括號放在行首，所以：
 
@@ -134,7 +136,7 @@ C 語言風格中另外一個常見問題是大括號的放置。和縮進大小
 		we do y
 	}
 
-這適用於所有的非函數語句塊 (if, switch, for, while, do)。比如：
+這適用於所有的非函式語句塊 (if, switch, for, while, do)。比如：
 
 .. code-block:: c
 
@@ -149,7 +151,7 @@ C 語言風格中另外一個常見問題是大括號的放置。和縮進大小
 		return NULL;
 	}
 
-不過，有一個例外，那就是函數：函數的起始大括號放置於下一行的開頭，所以：
+不過，有一個例外，那就是函式：函式的起始大括號放置於下一行的開頭，所以：
 
 .. code-block:: c
 
@@ -159,10 +161,10 @@ C 語言風格中另外一個常見問題是大括號的放置。和縮進大小
 	}
 
 全世界的異端可能會抱怨這個不一致性是……呃……不一致，不過所有思維健全的人
-都知道 (a) K&R 是 **正確的** 並且 (b) K&R 是正確的。此外，不管怎樣函數都是特
-殊的 (C 函數是不能嵌套的)。
+都知道 (a) K&R 是 **正確的** 並且 (b) K&R 是正確的。此外，不管怎樣函式都是特
+殊的 (C 函式是不能嵌套的)。
 
-注意結束大括號獨自佔據一行，除非它後面跟着同一個語句的剩餘部分，也就是 do 語
+注意結束大括號獨自佔據一行，除非它後面跟著同一個語句的剩餘部分，也就是 do 語
 句中的 ``while`` 或者 if 語句中的 ``else`` ，像這樣：
 
 .. code-block:: c
@@ -187,7 +189,7 @@ C 語言風格中另外一個常見問題是大括號的放置。和縮進大小
 
 也請注意這種大括號的放置方式也能使空 (或者差不多空的) 行的數量最小化，同時不
 失可讀性。因此，由於你的屏幕上的新行是不可再生資源 (想想 25 行的終端屏幕)，你
-將會有更多的空行來放置註釋。
+將會有更多的空行來放置註解。
 
 當只有一個單獨的語句的時候，不用加不必要的大括號。
 
@@ -219,10 +221,10 @@ C 語言風格中另外一個常見問題是大括號的放置。和縮進大小
 3.1) 空格
 *********
 
-Linux 內核的空格使用方式 (主要) 取決於它是用於函數還是關鍵字。(大多數) 關鍵字
+Linux 核心的空格使用方式 (主要) 取決於它是用於函式還是關鍵字。(大多數) 關鍵字
 後要加一個空格。值得注意的例外是 sizeof, typeof, alignof 和 __attribute__，這
-些關鍵字某些程度上看起來更像函數 (它們在 Linux 裏也常常伴隨小括號而使用，儘管
-在 C 裏這樣的小括號不是必需的，就像 ``struct fileinfo info;`` 聲明過後的
+些關鍵字某些程度上看起來更像函式 (它們在 Linux 裡也常常伴隨小括號而使用，儘管
+在 C 裡這樣的小括號不是必需的，就像 ``struct fileinfo info;`` 宣告過後的
 ``sizeof info``)。
 
 所以在這些關鍵字之後放一個空格::
@@ -236,14 +238,14 @@ Linux 內核的空格使用方式 (主要) 取決於它是用於函數還是關�
 
 	s = sizeof(struct file);
 
-不要在小括號裏的表達式兩側加空格。這是一個 **反例** ：
+不要在小括號裡的表達式兩側加空格。這是一個 **反例** ：
 
 .. code-block:: c
 
 	s = sizeof( struct file );
 
-當聲明指針類型或者返回指針類型的函數時， ``*`` 的首選使用方式是使之靠近變量名
-或者函數名，而不是靠近類型名。例子：
+當宣告指標類型或者返回指標類型的函式時， ``*`` 的首選使用方式是使之靠近變數名
+或者函式名，而不是靠近類型名。例子：
 
 .. code-block:: c
 
@@ -269,67 +271,67 @@ Linux 內核的空格使用方式 (主要) 取決於它是用於函數還是關�
 
 ``.`` 和 ``->`` 結構體成員操作符前後不加空格。
 
-不要在行尾留空白。有些可以自動縮進的編輯器會在新行的行首加入適量的空白，然後
-你就可以直接在那一行輸入代碼。不過假如你最後沒有在那一行輸入代碼，有些編輯器
-就不會移除已經加入的空白，就像你故意留下一個只有空白的行。包含行尾空白的行就
-這樣產生了。
+不要在行尾留空白。有些可以自動縮排的編輯器會在新行的行首加入適量的空白，然
+後你就可以直接在那一行輸入程式碼。不過假如你最後沒有在那一行輸入程式碼，有
+些編輯器就不會移除已經加入的空白，就像你故意留下一個只有空白的行。包含行尾
+空白的行就這樣產生了。
 
 當 git 發現補丁包含了行尾空白的時候會警告你，並且可以應你的要求去掉行尾空白；
-不過如果你是正在打一系列補丁，這樣做會導致後面的補丁失敗，因爲你改變了補丁的
+不過如果你是正在打一系列補丁，這樣做會導致後面的補丁失敗，因為你改變了補丁的
 上下文。
 
 
 4) 命名
 -------
 
-C 是一個簡樸的語言，你的命名也應該這樣。和 Modula-2 和 Pascal 程序員不同，
-C 程序員不使用類似 ThisVariableIsATemporaryCounter 這樣華麗的名字。C 程序員會
-稱那個變量爲 ``tmp`` ，這樣寫起來會更容易，而且至少不會令其難於理解。
+C 是一個簡樸的語言，你的命名也應該這樣。和 Modula-2 和 Pascal 程式員不同，
+C 程式員不使用類似 ThisVariableIsATemporaryCounter 這樣華麗的名字。C 程式員會
+稱那個變數為 ``tmp`` ，這樣寫起來會更容易，而且至少不會令其難於理解。
 
-不過，雖然混用大小寫的名字是不提倡使用的，但是全局變量還是需要一個具描述性的
-名字。稱一個全局函數爲 ``foo`` 是一個難以饒恕的錯誤。
+不過，雖然混用大小寫的名字是不提倡使用的，但是全域變數還是需要一個具描述性的
+名字。稱一個全域函式為 ``foo`` 是一個難以饒恕的錯誤。
 
-全局變量 (只有當你 **真正** 需要它們的時候再用它) 需要有一個具描述性的名字，就
-像全局函數。如果你有一個可以計算活動用戶數量的函數，你應該叫它
+全域變數 (只有當你 **真正** 需要它們的時候再用它) 需要有一個具描述性的名字，就
+像全域函式。如果你有一個可以計算活動使用者數量的函式，你應該叫它
 ``count_active_users()`` 或者類似的名字，你不應該叫它 ``cntuser()`` 。
 
-在函數名中包含函數類型 (所謂的匈牙利命名法) 是腦子出了問題——編譯器知道那些類
-型而且能夠檢查那些類型，這樣做只能把程序員弄糊塗了。
+在函式名中包含函式類型 (所謂的匈牙利命名法) 是腦子出了問題——編譯器知道那些類
+型而且能夠檢查那些類型，這樣做只能把程式員弄糊塗了。
 
-本地變量名應該簡短，而且能夠表達相關的含義。如果你有一些隨機的整數型的循環計
-數器，它應該被稱爲 ``i`` 。叫它 ``loop_counter`` 並無益處，如果它沒有被誤解的
-可能的話。類似的， ``tmp`` 可以用來稱呼任意類型的臨時變量。
+本地變數名應該簡短，而且能夠表達相關的含義。如果你有一些隨機的整數型的迴圈計
+數器，它應該被稱為 ``i`` 。叫它 ``loop_counter`` 並無益處，如果它沒有被誤解的
+可能的話。類似的， ``tmp`` 可以用來稱呼任意類型的臨時變數。
 
-如果你怕混淆了你的本地變量名，你就遇到另一個問題了，叫做函數增長荷爾蒙失衡綜
-合徵。請看第六章 (函數)。
+如果你怕混淆了你的本地變數名，你就遇到另一個問題了，叫做函式增長荷爾蒙失衡綜
+合徵。請看第六章 (函式)。
 
-對於符號名稱和文檔，避免引入新的“master/slave”（或獨立於“master”的“slave”）
+對於符號名稱和文件，避免引入新的“master/slave”（或獨立於“master”的“slave”）
 和“blacklist/whitelist”。
 
-“master/slave”推薦替換爲：
+“master/slave”推薦替換為：
     '{primary,main} / {secondary,replica,subordinate}'
     '{initiator,requester} / {target,responder}'
     '{controller,host} / {device,worker,proxy}'
     'leader/follower'
     'director/performer'
 
-“blacklist/whitelist”推薦替換爲：
+“blacklist/whitelist”推薦替換為：
     'denylist/allowlist'
     'blocklist/passlist'
 
-引入新用法的例外情況是：維護用戶空間ABI/API，或更新現有（截至2020年）硬件或
-協議規範的代碼時要求這些術語。對於新規範，儘可能將術語的規範用法轉換爲內核
+引入新用法的例外情況是：維護使用者空間ABI/API，或更新現有（截至2020年）硬體或
+協議規範的程式碼時要求這些術語。對於新規範，儘可能將術語的規範用法轉換為核心
 編碼標準。
 
 .. warning::
-	以上主從、黑白名單規則不適用於中文文檔，請勿更改中文術語！
+	以上主從、黑白名單規則不適用於中文文件，請勿更改中文術語！
 
 5) Typedef
 ----------
 
 不要使用類似 ``vps_t`` 之類的東西。
 
-對結構體和指針使用 typedef 是一個 **錯誤** 。當你在代碼裏看到：
+對結構體和指標使用 typedef 是一個 **錯誤** 。當你在程式碼裡看到：
 
 .. code-block:: c
 
@@ -345,34 +347,34 @@ C 程序員不使用類似 ThisVariableIsATemporaryCounter 這樣華麗的名字
 
 你就知道 ``a`` 是什麼了。
 
-很多人認爲 typedef ``能提高可讀性`` 。實際不是這樣的。它們只在下列情況下有用：
+很多人認為 typedef ``能提高可讀性`` 。實際不是這樣的。它們只在下列情況下有用：
 
- (a) 完全不透明的對象 (這種情況下要主動使用 typedef 來 **隱藏** 這個對象實際上
+ (a) 完全不透明的物件 (這種情況下要主動使用 typedef 來 **隱藏** 這個物件實際上
      是什麼)。
 
-     例如： ``pte_t`` 等不透明對象，你只能用合適的訪問函數來訪問它們。
+     例如： ``pte_t`` 等不透明物件，你只能用合適的存取函式來存取它們。
 
      .. note::
 
-       不透明性和“訪問函數”本身是不好的。我們使用 pte_t 等類型的原因在於真
-       的是完全沒有任何共用的可訪問信息。
+       不透明性和“存取函式”本身是不好的。我們使用 pte_t 等類型的原因在於真
+       的是完全沒有任何共用的可存取資訊。
 
  (b) 清楚的整數類型，如此，這層抽象就可以 **幫助** 消除到底是 ``int`` 還是
      ``long`` 的混淆。
 
-     u8/u16/u32 是完全沒有問題的 typedef，不過它們更符合類別 (d) 而不是這裏。
+     u8/u16/u32 是完全沒有問題的 typedef，不過它們更符合類別 (d) 而不是這裡。
 
      .. note::
 
-       要這樣做，必須事出有因。如果某個變量是 ``unsigned long`` ，那麼沒有必要
+       要這樣做，必須事出有因。如果某個變數是 ``unsigned long`` ，那麼沒有必要
 
 	typedef unsigned long myflags_t;
 
      不過如果有一個明確的原因，比如它在某種情況下可能會是一個 ``unsigned int``
-     而在其他情況下可能爲 ``unsigned long`` ，那麼就不要猶豫，請務必使用
+     而在其他情況下可能為 ``unsigned long`` ，那麼就不要猶豫，請務必使用
      typedef。
 
- (c) 當你使用 sparse 按字面的創建一個 **新** 類型來做類型檢查的時候。
+ (c) 當你使用 sparse 按字面的建立一個 **新** 類型來做類型檢查的時候。
 
  (d) 和標準 C99 類型相同的類型，在某些例外的情況下。
 
@@ -380,45 +382,45 @@ C 程序員不使用類似 ThisVariableIsATemporaryCounter 這樣華麗的名字
      是有些人仍然拒絕使用它們。
 
      因此，Linux 特有的等同於標準類型的 ``u8/u16/u32/u64`` 類型和它們的有符號
-     類型是被允許的——儘管在你自己的新代碼中，它們不是強制要求要使用的。
+     類型是被允許的——儘管在你自己的新程式碼中，它們不是強制要求要使用的。
 
-     當編輯已經使用了某個類型集的已有代碼時，你應該遵循那些代碼中已經做出的選
+     當編輯已經使用了某個類型集的已有程式碼時，你應該遵循那些程式碼中已經做出的選
      擇。
 
- (e) 可以在用戶空間安全使用的類型。
+ (e) 可以在使用者空間安全使用的類型。
 
-     在某些用戶空間可見的結構體裏，我們不能要求 C99 類型而且不能用上面提到的
-     ``u32`` 類型。因此，我們在與用戶空間共享的所有結構體中使用 __u32 和類似
+     在某些使用者空間可見的結構體裡，我們不能要求 C99 類型而且不能用上面提到的
+     ``u32`` 類型。因此，我們在與使用者空間共享的所有結構體中使用 __u32 和類似
      的類型。
 
 可能還有其他的情況，不過基本的規則是 **永遠不要** 使用 typedef，除非你可以明
 確的應用上述某個規則中的一個。
 
-總的來說，如果一個指針或者一個結構體裏的元素可以合理的被直接訪問到，那麼它們
+總的來說，如果一個指標或者一個結構體裡的元素可以合理的被直接存取到，那麼它們
 就不應該是一個 typedef。
 
 
-6) 函數
+6) 函式
 -------
 
-函數應該簡短而漂亮，並且只完成一件事情。函數應該可以一屏或者兩屏顯示完 (我們
+函式應該簡短而漂亮，並且只完成一件事情。函式應該可以一屏或者兩屏顯示完 (我們
 都知道 ISO/ANSI 屏幕大小是 80x24)，只做一件事情，而且把它做好。
 
-一個函數的最大長度是和該函數的複雜度和縮進級數成反比的。所以，如果你有一個理
-論上很簡單的只有一個很長 (但是簡單) 的 case 語句的函數，而且你需要在每個 case
-裏做很多很小的事情，這樣的函數儘管很長，但也是可以的。
+一個函式的最大長度是和該函式的複雜度和縮排級數成反比的。所以，如果你有一個理
+論上很簡單的只有一個很長 (但是簡單) 的 case 語句的函式，而且你需要在每個 case
+裡做很多很小的事情，這樣的函式儘管很長，但也是可以的。
 
-不過，如果你有一個複雜的函數，而且你懷疑一個天分不是很高的高中一年級學生可能
-甚至搞不清楚這個函數的目的，你應該嚴格遵守前面提到的長度限制。使用輔助函數，
-併爲之取個具描述性的名字 (如果你覺得它們的性能很重要的話，可以讓編譯器內聯它
-們，這樣的效果往往會比你寫一個複雜函數的效果要好。)
+不過，如果你有一個複雜的函式，而且你懷疑一個天分不是很高的高中一年級學生可能
+甚至搞不清楚這個函式的目的，你應該嚴格遵守前面提到的長度限制。使用輔助函式，
+併為之取個具描述性的名字 (如果你覺得它們的效能很重要的話，可以讓編譯器行內它
+們，這樣的效果往往會比你寫一個複雜函式的效果要好。)
 
-函數的另外一個衡量標準是本地變量的數量。此數量不應超過 5－10 個，否則你的函數
-就有問題了。重新考慮一下你的函數，把它分拆成更小的函數。人的大腦一般可以輕鬆
-的同時跟蹤 7 個不同的事物，如果再增多的話，就會糊塗了。即便你聰穎過人，你也可
+函式的另外一個衡量標準是本地變數的數量。此數量不應超過 5－10 個，否則你的函式
+就有問題了。重新考慮一下你的函式，把它分拆成更小的函式。人的大腦一般可以輕鬆
+的同時追蹤 7 個不同的事物，如果再增多的話，就會糊塗了。即便你聰穎過人，你也可
 能會記不清你 2 個星期前做過的事情。
 
-在源文件裏，使用空行隔開不同的函數。如果該函數需要被導出，它的 **EXPORT** 宏
+在原始檔裡，使用空行隔開不同的函式。如果該函式需要被匯出，它的 **EXPORT** 巨集
 應該緊貼在它的結束大括號之下。比如：
 
 .. code-block:: c
@@ -429,37 +431,38 @@ C 程序員不使用類似 ThisVariableIsATemporaryCounter 這樣華麗的名字
 	}
 	EXPORT_SYMBOL(system_is_up);
 
-6.1) 函數原型
+6.1) 函式原型
 *************
 
-在函數原型中包含參數名和它們的數據類型。雖然 C 語言裏沒有這樣的要求，但在
-Linux 裏這是提倡的做法，因爲這樣可以很簡單的給讀者提供更多的有價值的信息。
+在函式原型中包含參數名和它們的資料類型。雖然 C 語言裡沒有這樣的要求，但在
+Linux 裡這是提倡的做法，因為這樣可以很簡單的給讀者提供更多的有價值的資訊。
 
-不要在函數聲明裏使用 ``extern`` 關鍵字，因爲這會導致代碼行變長，並且不是嚴格
+不要在函式宣告裡使用 ``extern`` 關鍵字，因為這會導致程式碼行變長，並且不是嚴格
 必需的。
 
-寫函數原型時，請保持 `元素順序規則 <https://lore.kernel.org/mm-commits/CAHk-=wiOCLRny5aifWNhr621kYrJwhfURsa0vFPeUEm8mF0ufg@mail.gmail.com/>`_ 。
-例如下列函數聲明::
+寫函式原型時，請保持 `元素順序規則 <https://lore.kernel.org/mm-commits/CAHk-=wiOCLRny5aifWNhr621kYrJwhfURsa0vFPeUEm8mF0ufg@mail.gmail.com/>`_ 。
+例如下列函式宣告::
 
  __init void * __must_check action(enum magic value, size_t size, u8 count,
 				   char *fmt, ...) __printf(4, 5) __malloc;
 
-推薦的函數原型元素順序是：
+推薦的函式原型元素順序是：
 
 - 儲存類型（下方的 ``static __always_inline`` ，注意 ``__always_inline``
   技術上來講是個屬性但被當做 ``inline`` ）
-- 儲存類型屬性（上方的 ``__init`` ——即節聲明，但也像 ``__cold`` ）
+- 儲存類型屬性（上方的 ``__init`` ——即節宣告，但也像 ``__cold`` ）
 - 返回類型（上方的 ``void *`` ）
 - 返回類型屬性（上方的 ``__must_check`` ）
-- 函數名（上方的 ``action`` ）
-- 函數參數（上方的 ``(enum magic value, size_t size, u8 count, char *fmt, ...)`` ，
-  注意必須寫上參數名）
-- 函數參數屬性（上方的 ``__printf(4, 5)`` ）
-- 函數行爲屬性（上方的 ``__malloc`` ）
+- 函式名（上方的 ``action`` ）
+- 函式參數（上方的
+  ``(enum magic value, size_t size, u8 count, char *fmt, ...)`` ，注意必須
+  寫上參數名）
+- 函式參數屬性（上方的 ``__printf(4, 5)`` ）
+- 函式行為屬性（上方的 ``__malloc`` ）
 
-請注意，對於函數 **定義** （即實際函數體），編譯器不允許在函數參數之後添加函
-數參數屬性。在這種情況下，它們應該跟隨存儲類型屬性（例如，與上面的 **聲明**
-示例相比，請注意下面的 ``__printf(4, 5)`` 的位置發生了變化）::
+請注意，對於函式 **定義** （即實際函式體），編譯器不允許在函式參數之後添加函
+數參數屬性。在這種情況下，它們應該跟隨儲存類型屬性（例如，與上面的 **宣告**
+範例相比，請注意下面的 ``__printf(4, 5)`` 的位置發生了變化）::
 
  static __always_inline __init __printf(4, 5) void * __must_check action(enum magic value,
 		size_t size, u8 count, char *fmt, ...) __malloc
@@ -467,26 +470,26 @@ Linux 裏這是提倡的做法，因爲這樣可以很簡單的給讀者提供�
 	...
  }
 
-7) 集中的函數退出途徑
+7) 集中的函式退出途徑
 ---------------------
 
 雖然被某些人聲稱已經過時，但是 goto 語句的等價物還是經常被編譯器所使用，具體
 形式是無條件跳轉指令。
 
-當一個函數從多個位置退出，並且需要做一些類似清理的常見操作時，goto 語句就很方
+當一個函式從多個位置退出，並且需要做一些類似清理的常見操作時，goto 語句就很方
 便了。如果並不需要清理操作，那麼直接 return 即可。
 
-選擇一個能夠說明 goto 行爲或它爲何存在的標籤名。如果 goto 要釋放 ``buffer``,
+選擇一個能夠說明 goto 行為或它為何存在的標籤名。如果 goto 要釋放 ``buffer``,
 一個不錯的名字可以是 ``out_free_buffer:`` 。別去使用像 ``err1:`` 和 ``err2:``
-這樣的GW_BASIC 名稱，因爲一旦你添加或刪除了 (函數的) 退出路徑，你就必須對它們
+這樣的GW_BASIC 名稱，因為一旦你添加或刪除了 (函式的) 退出路徑，你就必須對它們
 重新編號，這樣會難以去檢驗正確性。
 
 使用 goto 的理由是：
 
-- 無條件語句容易理解和跟蹤
+- 無條件語句容易理解和追蹤
 - 嵌套程度減小
 - 可以避免由於修改時忘記更新個別的退出點而導致錯誤
-- 讓編譯器省去刪除冗餘代碼的工作 ;)
+- 讓編譯器省去刪除冗餘程式碼的工作 ;)
 
 .. code-block:: c
 
@@ -521,7 +524,7 @@ Linux 裏這是提倡的做法，因爲這樣可以很簡單的給讀者提供�
 		kfree(foo);
 		return ret;
 
-這段代碼的錯誤是，在某些退出路徑上 ``foo`` 是 NULL。通常情況下，通過把它分離
+這段程式碼的錯誤是，在某些退出路徑上 ``foo`` 是 NULL。通常情況下，透過把它分離
 成兩個錯誤標籤 ``err_free_bar:`` 和 ``err_free_foo:`` 來修復這個錯誤：
 
 .. code-block:: c
@@ -535,22 +538,23 @@ Linux 裏這是提倡的做法，因爲這樣可以很簡單的給讀者提供�
 理想情況下，你應該模擬錯誤來測試所有退出路徑。
 
 
-8) 註釋
+8) 註解
 -------
 
-註釋是好的，不過有過度註釋的危險。永遠不要在註釋裏解釋你的代碼是如何運作的：
-更好的做法是讓別人一看你的代碼就可以明白，解釋寫的很差的代碼是浪費時間。
+註解是好的，不過有過度註解的危險。永遠不要在註解裡解釋你的程式碼是如何運作的：
+更好的做法是讓別人一看你的程式碼就可以明白，解釋寫的很差的程式碼是浪費時間。
 
-一般來說你用註釋告訴別人你的代碼做了什麼，而不是怎麼做的。也請你不要把
-註釋放在一個函數體內部：如果函數複雜到你需要獨立的註釋其中的一部分，你很可能
-需要回到第六章看一看。你可以做一些小注釋來註明或警告某些很聰明 (或者槽糕) 的
-做法，但不要加太多。你應該做的，是把註釋放在函數的頭部，告訴人們它做了什麼，
+一般來說你用註解告訴別人你的程式碼做了什麼，而不是怎麼做的。也請你不要把
+註解放在一個函式體內部：如果函式複雜到你需要獨立的註解其中的一部分，你很可能
+需要回到第六章看一看。你可以做一些小註解來註明或警告某些很聰明 (或者槽糕) 的
+做法，但不要加太多。你應該做的，是把註解放在函式的頭部，告訴人們它做了什麼，
 也可以加上它做這些事情的原因。
 
-當註釋內核 API 函數時，請使用 kernel-doc 格式。詳見
-Documentation/translations/zh_CN/doc-guide/index.rst 和 tools/docs/kernel-doc 。
+當註解核心 API 函式時，請使用 kernel-doc 格式。詳見
+Documentation/translations/zh_CN/doc-guide/index.rst 和
+tools/docs/kernel-doc 。
 
-長 (多行) 註釋的首選風格是：
+長 (多行) 註解的首選風格是：
 
 .. code-block:: c
 
@@ -563,7 +567,7 @@ Documentation/translations/zh_CN/doc-guide/index.rst 和 tools/docs/kernel-doc �
 	 * with beginning and ending almost-blank lines.
 	 */
 
-對於在 net/ 和 drivers/net/ 的文件，首選的長 (多行) 註釋風格有些不同。
+對於在 net/ 和 drivers/net/ 的檔案，首選的長 (多行) 註解風格有些不同。
 
 .. code-block:: c
 
@@ -574,22 +578,22 @@ Documentation/translations/zh_CN/doc-guide/index.rst 和 tools/docs/kernel-doc �
 	 * but there is no initial almost-blank line.
 	 */
 
-註釋數據也是很重要的，不管是基本類型還是衍生類型。爲了方便實現這一點，每一行
-應只聲明一個數據 (不要使用逗號來一次聲明多個數據)。這樣你就有空間來爲每個數據
-寫一段小注釋來解釋它們的用途了。
+註解資料也是很重要的，不管是基本類型還是衍生類型。為了方便實作這一點，每一行
+應只宣告一個資料 (不要使用逗號來一次宣告多個資料)。這樣你就有空間來為每個資料
+寫一段小註解來解釋它們的用途了。
 
 
 9) 你已經把事情弄糟了
 ---------------------
 
-這沒什麼，我們都是這樣。可能你長期使用 Unix 的朋友已經告訴你
-``GNU emacs`` 能自動幫你格式化 C 源代碼，而且你也注意到了，確實是這樣，不過它
-所使用的默認值和我們想要的相去甚遠 (實際上，甚至比隨機打的還要差——無數個猴子
-在 GNU emacs 裏打字永遠不會創造出一個好程序)
+這沒什麼，我們都是這樣。可能你長期使用 Unix 的朋友已經告訴你``GNU emacs``
+能自動幫你格式化 C 原始程式碼，而且你也注意到了，確實是這樣，不過它所使用
+的預設值和我們想要的相去甚遠 (實際上，甚至比隨機打的還要差——無數個猴子在
+GNU emacs 裡打字永遠不會創造出一個好程式)
 *(譯註：Infinite Monkey Theorem)*
 
 所以你要麼放棄 GNU emacs，要麼改變它讓它使用更合理的設定。要採用後一個方案，
-你可以把下面這段粘貼到你的 .emacs 文件裏。
+你可以把下面這段貼上到你的 .emacs 檔案裡。
 
 .. code-block:: elisp
 
@@ -640,31 +644,31 @@ Documentation/translations/zh_CN/doc-guide/index.rst 和 tools/docs/kernel-doc �
    (expand-file-name "~/src/linux-trees")
    'linux-kernel)
 
-這會讓 emacs 在 ``~/src/linux-trees`` 下的 C 源文件獲得更好的內核代碼風格。
+這會讓 emacs 在 ``~/src/linux-trees`` 下的 C 原始檔獲得更好的核心程式碼風格。
 
-不過就算你嘗試讓 emacs 正確的格式化代碼失敗了，也並不意味着你失去了一切：還可
-以用 ``indent`` 。
+不過就算你嘗試讓 emacs 正確的格式化程式碼失敗了，也並不意味著你失去了一切：
+還可以用 ``indent`` 。
 
 不過，GNU indent 也有和 GNU emacs 一樣有問題的設定，所以你需要給它一些命令選
-項。不過，這還不算太糟糕，因爲就算是 GNU indent 的作者也認同 K&R 的權威性
+項。不過，這還不算太糟糕，因為就算是 GNU indent 的作者也認同 K&R 的權威性
 (GNU 的人並不是壞人，他們只是在這個問題上被嚴重的誤導了)，所以你只要給 indent
-指定選項 ``-kr -i8`` (代表 ``K&R，8 字符縮進``)，或使用 ``scripts/Lindent``
-這樣就可以以最時髦的方式縮進源代碼。
+指定選項 ``-kr -i8`` (代表 ``K&R，8 字元縮排``)，或使用 ``scripts/Lindent``
+這樣就可以以最時髦的方式縮排原始程式碼。
 
-``indent`` 有很多選項，特別是重新格式化註釋的時候，你可能需要看一下它的手冊。
-不過記住： ``indent`` 不能修正壞的編程習慣。
+``indent`` 有很多選項，特別是重新格式化註解的時候，你可能需要看一下它的手冊。
+不過記住： ``indent`` 不能修正壞的程式設計習慣。
 
-請注意，您還可以使用 ``clang-format`` 工具幫助您處理這些規則，快速自動重新格
-式化部分代碼，並審閱整個文件以發現代碼風格錯誤、打字錯誤和可能的改進。它還可
-以方便地排序 ``#include`` ，對齊變量/宏，重排文本和其他類似任務。
+請注意，您還可以使用 ``clang-format`` 工具幫助您處理這些規則，快速自動重新
+格式化部分程式碼，並審閱整個檔案以發現程式碼風格錯誤、打字錯誤和可能的改進。
+它還可以方便地排序 ``#include`` ，對齊變數/巨集，重排文字和其他類似任務。
 詳見 Documentation/dev-tools/clang-format.rst 。
 
 
-10) Kconfig 配置文件
+10) Kconfig 設定檔
 --------------------
 
-對於遍佈源碼樹的所有 Kconfig* 配置文件來說，它們縮進方式有所不同。緊挨着
-``config`` 定義的行，用一個製表符縮進，然而 help 信息的縮進則額外增加 2 個空
+對於遍佈源碼樹的所有 Kconfig* 設定文件來說，它們縮排方式有所不同。緊挨著
+``config`` 定義的行，用一個製表符縮排，然而 help 資訊的縮排則額外增加 2 個空
 格。舉個例子::
 
   config AUDIT
@@ -676,7 +680,7 @@ Documentation/translations/zh_CN/doc-guide/index.rst 和 tools/docs/kernel-doc �
 	  logging of avc messages output).  Does not do system-call
 	  auditing without CONFIG_AUDITSYSCALL.
 
-而那些危險的功能 (比如某些文件系統的寫支持) 應該在它們的提示字符串裏顯著的聲
+而那些危險的功能 (比如某些檔案系統的寫支援) 應該在它們的提示字串裡顯著的聲
 明這一點::
 
   config ADFS_FS_RW
@@ -684,49 +688,50 @@ Documentation/translations/zh_CN/doc-guide/index.rst 和 tools/docs/kernel-doc �
 	depends on ADFS_FS
 	...
 
-要查看配置文件的完整文檔，請看 Documentation/kbuild/kconfig-language.rst 。
+要查看設定文件的完整文件，請看 Documentation/kbuild/kconfig-language.rst 。
 
 
-11) 數據結構
+11) 資料結構
 ------------
 
-如果一個數據結構，在創建和銷燬它的單線執行環境之外可見，那麼它必須要有一個引
-用計數器。內核裏沒有垃圾收集 (並且內核之外的垃圾收集慢且效率低下)，這意味着你
-絕對需要記錄你對這種數據結構的使用情況。
+如果一個資料結構，在建立和銷燬它的單線執行環境之外可見，那麼它必須要有一個引
+用計數器。核心裡沒有垃圾收集 (並且核心之外的垃圾收集慢且效率低下)，這意味著你
+絕對需要記錄你對這種資料結構的使用情況。
 
-引用計數意味着你能夠避免上鎖，並且允許多個用戶並行訪問這個數據結構——而不需要
-擔心這個數據結構僅僅因爲暫時不被使用就消失了，那些用戶可能不過是沉睡了一陣或
+引用計數意味著你能夠避免上鎖，並且允許多個使用者並行存取這個資料結構——而不需要
+擔心這個資料結構僅僅因為暫時不被使用就消失了，那些使用者可能不過是沉睡了一陣或
 者做了一些其他事情而已。
 
-注意上鎖 **不能** 取代引用計數。上鎖是爲了保持數據結構的一致性，而引用計數是一
-個內存管理技巧。通常二者都需要，不要把兩個搞混了。
+注意上鎖 **不能** 取代引用計數。上鎖是為了保持資料結構的一致性，而引用計數是一
+個記憶體管理技巧。通常二者都需要，不要把兩個搞混了。
 
-很多數據結構實際上有 2 級引用計數，它們通常有不同 ``類`` 的用戶。子類計數器統
-計子類用戶的數量，每當子類計數器減至零時，全局計數器減一。
+很多資料結構實際上有 2 級引用計數，它們通常有不同 ``類`` 的使用者。子類計
+數器統計子類使用者的數量，每當子類計數器減至零時，全域計數器減一。
 
-這種 ``多級引用計數`` 的例子可以在內存管理 (``struct mm_struct``: mm_users 和
-mm_count)，和文件系統 (``struct super_block``: s_count 和 s_active) 中找到。
+這種 ``多級引用計數`` 的例子可以在記憶體管理 (``struct mm_struct``:
+mm_users 和mm_count)，和檔案系統 (``struct super_block``: s_count 和
+s_active) 中找到。
 
-記住：如果另一個執行線索可以找到你的數據結構，但這個數據結構沒有引用計數器，
-這裏幾乎肯定是一個 bug。
+記住：如果另一個執行線索可以找到你的資料結構，但這個資料結構沒有引用計數器，
+這裡幾乎肯定是一個 bug。
 
 
-12) 宏，枚舉和RTL
------------------
+12) 巨集，列舉和RTL
+-------------------
 
-用於定義常量的宏的名字及枚舉裏的標籤需要大寫。
+用於定義常數的巨集的名字及列舉裡的標籤需要大寫。
 
 .. code-block:: c
 
 	#define CONSTANT 0x12345
 
-在定義幾個相關的常量時，最好用枚舉。
+在定義幾個相關的常數時，最好用列舉。
 
-宏的名字請用大寫字母，不過形如函數的宏的名字可以用小寫字母。
+巨集的名字請用大寫字母，不過形如函式的巨集的名字可以用小寫字母。
 
-通常如果能寫成內聯函數就不要寫成像函數的宏。
+通常如果能寫成行內函式就不要寫成像函式的巨集。
 
-含有多個語句的宏應該被包含在一個 do-while 代碼塊裏：
+含有多個語句的巨集應該被包含在一個 do-while 程式碼塊裡：
 
 .. code-block:: c
 
@@ -736,9 +741,9 @@ mm_count)，和文件系統 (``struct super_block``: s_count 和 s_active) 中�
 				do_this(b, c);		\
 		} while (0)
 
-使用宏的時候應避免的事情：
+使用巨集的時候應避免的事情：
 
-1) 影響控制流程的宏：
+1) 影響控制流程的巨集：
 
 .. code-block:: c
 
@@ -748,30 +753,30 @@ mm_count)，和文件系統 (``struct super_block``: s_count 和 s_active) 中�
 				return -EBUGGERED;	\
 		} while (0)
 
-**非常** 不好。它看起來像一個函數，不過卻能導致 ``調用`` 它的函數退出；不要打
-亂讀者大腦裏的語法分析器。
+**非常** 不好。它看起來像一個函式，不過卻能導致 ``呼叫`` 它的函式退出；不要打
+亂讀者大腦裡的語法分析器。
 
-2) 依賴於一個固定名字的本地變量的宏：
+2) 依賴於一個固定名字的本地變數的巨集：
 
 .. code-block:: c
 
 	#define FOO(val) bar(index, val)
 
-可能看起來像是個不錯的東西，不過它非常容易把讀代碼的人搞糊塗，而且容易導致看起
-來不相關的改動帶來錯誤。
+可能看起來像是個不錯的東西，不過它非常容易把讀程式碼的人搞糊塗，而且容易導
+致看起來不相關的改動帶來錯誤。
 
-3) 作爲左值的帶參數的宏： FOO(x) = y；如果有人把 FOO 變成一個內聯函數的話，這
+3) 作為左值的帶參數的巨集： FOO(x) = y；如果有人把 FOO 變成一個行內函式的話，這
    種用法就會出錯了。
 
-4) 忘記了優先級：使用表達式定義常量的宏必須將表達式置於一對小括號之內。帶參數
-   的宏也要注意此類問題。
+4) 忘記了優先級：使用表達式定義常數的巨集必須將表達式置於一對小括號之內。帶參數
+   的巨集也要注意此類問題。
 
 .. code-block:: c
 
 	#define CONSTANT 0x4000
 	#define CONSTEXP (CONSTANT | 3)
 
-5) 在宏裏定義類似函數的本地變量時命名衝突：
+5) 在巨集裡定義類似函式的本地變數時命名衝突：
 
 .. code-block:: c
 
@@ -782,45 +787,45 @@ mm_count)，和文件系統 (``struct super_block``: s_count 和 s_active) 中�
 		(ret);				\
 	})
 
-ret 是本地變量的通用名字—— __foo_ret 更不容易與一個已存在的變量衝突。
+ret 是本地變數的通用名字—— __foo_ret 更不容易與一個已存在的變數衝突。
 
-cpp 手冊對宏的講解很詳細。gcc internals 手冊也詳細講解了 RTL，內核裏的彙編語
+cpp 手冊對巨集的講解很詳細。gcc internals 手冊也詳細講解了 RTL，核心裡的組譯語
 言經常用到它。
 
 
-13) 打印內核消息
+13) 列印核心訊息
 ----------------
 
-內核開發者應該看起來有文化。請一定注意內核信息的拼寫，以給人良好的印象。
+核心開發者應該看起來有文化。請一定注意核心資訊的拼寫，以給人良好的印象。
 不要用不規範的單詞比如 ``dont``，而要用 ``do not`` 或者 ``don't`` 。保證這些信
 息簡單明瞭、無歧義。
 
-內核信息不必以英文句號結束。
+核心資訊不必以英文句號結束。
 
-在小括號裏打印數字 (%d) 沒有任何價值，應該避免這樣做。
+在小括號裡列印數字 (%d) 沒有任何價值，應該避免這樣做。
 
-<linux/device.h> 裏有一些驅動模型診斷宏，你應該使用它們，以確保信息對應於正確
-的設備和驅動，並且被標記了正確的消息級別。這些宏有：dev_err(), dev_warn(),
-dev_info() 等等。對於那些不和某個特定設備相關連的信息，<linux/printk.h> 定義
-了 pr_notice(), pr_info(), pr_warn(), pr_err() 和其他。
+<linux/device.h> 裡有一些驅動模型診斷巨集，你應該使用它們，以確保資訊對應
+於正確的設備和驅動，並且被標記了正確的訊息級別。這些巨集有：dev_err(),
+dev_warn(),dev_info() 等等。對於那些不和某個特定設備相關連的資訊，
+<linux/printk.h> 定義了 pr_notice(), pr_info(), pr_warn(), pr_err() 和其他。
 
-寫出好的調試信息可以是一個很大的挑戰；一旦你寫出後，這些信息在遠程除錯時能提
-供極大的幫助。然而打印調試信息的處理方式同打印非調試信息不同。其他 pr_XXX()
-函數能無條件地打印，pr_debug() 卻不；默認情況下它不會被編譯，除非定義了 DEBUG
-或設定了 CONFIG_DYNAMIC_DEBUG。實際這同樣是爲了 dev_dbg()，一個相關約定是在一
-個已經開啓了 DEBUG 時，使用 VERBOSE_DEBUG 來添加 dev_vdbg()。
+寫出好的除錯資訊可以是一個很大的挑戰；一旦你寫出後，這些資訊在遠端除錯時能提
+供極大的幫助。然而列印除錯資訊的處理方式同列印非除錯資訊不同。其他 pr_XXX()
+函式能無條件地列印，pr_debug() 卻不；預設情況下它不會被編譯，除非定義了 DEBUG
+或設定了 CONFIG_DYNAMIC_DEBUG。實際這同樣是為了 dev_dbg()，一個相關約定是在一
+個已經開啟了 DEBUG 時，使用 VERBOSE_DEBUG 來添加 dev_vdbg()。
 
-許多子系統擁有 Kconfig 調試選項來開啓對應 Makefile 裏面的 -DDEBUG；在其他
-情況下，特殊文件使用 #define DEBUG。當一條調試信息需要被無條件打印時，例如，
-如果已經包含一個調試相關的 #ifdef 條件，printk(KERN_DEBUG ...) 就可被使用。
+許多子系統擁有 Kconfig 除錯選項來開啟對應 Makefile 裡面的 -DDEBUG；在其他
+情況下，特定檔案使用 #define DEBUG。當一條除錯資訊需要被無條件列印時，例如，
+如果已經包含一個除錯相關的 #ifdef 條件，printk(KERN_DEBUG ...) 就可被使用。
 
 
-14) 分配內存
-------------
+14) 分配記憶體
+--------------
 
-內核提供了下面的一般用途的內存分配函數：
-kmalloc(), kzalloc(), kmalloc_array(), kcalloc(), vmalloc() 和 vzalloc()。
-請參考 API 文檔以獲取有關它們的詳細信息：
+核心提供了下面的一般用途的記憶體分配函式：
+kmalloc(), kzalloc(), kmalloc_objs(), kzalloc_objs(), vmalloc() 和 vzalloc()。
+請參考 API 文件以獲取有關它們的詳細資訊：
 Documentation/translations/zh_CN/core-api/memory-allocation.rst 。
 
 傳遞結構體大小的首選形式是這樣的：
@@ -830,103 +835,106 @@ Documentation/translations/zh_CN/core-api/memory-allocation.rst 。
 	p = kmalloc_obj(*p, ...);
 
 另外一種傳遞方式中，sizeof 的操作數是結構體的名字，這樣會降低可讀性，並且可能
-會引入 bug。有可能指針變量類型被改變時，而對應的傳遞給內存分配函數的 sizeof
+會引入 bug。有可能指標變數類型被改變時，而對應的傳遞給記憶體分配函式的 sizeof
 的結果不變。
 
-強制轉換一個 void 指針返回值是多餘的。C 語言本身保證了從 void 指針到其他任何
-指針類型的轉換是沒有問題的。
+強制轉換一個 void 指標回傳值是多餘的。C 語言本身保證了從 void 指標到其他任何
+指標類型的轉換是沒有問題的。
 
-分配一個數組的首選形式是這樣的：
+分配一個陣列的首選形式是這樣的：
 
 .. code-block:: c
 
-	p = kmalloc_array(n, sizeof(...), ...);
+	p = kmalloc_objs(*p, n, ...);
 
-分配一個零長數組的首選形式是這樣的：
+分配一個零長陣列的首選形式是這樣的：
 
 .. code-block:: c
 
-	p = kcalloc(n, sizeof(...), ...);
+	p = kzalloc_objs(*p, n, ...);
+
+這兩種形式都會檢查分配大小 n * sizeof(...) 是否溢位，如果發生溢位則回傳
+NULL。
 
-兩種形式都會檢查分配 n * sizeof(...) 大小時內存的溢出，如果溢出返回 NULL。
+兩種形式都會檢查分配 n * sizeof(...) 大小時記憶體的溢出，如果溢出返回 NULL。
 
-在沒有 __GFP_NOWARN 的情況下使用時，這些通用分配函數都會在失敗時發起堆棧轉儲，
-因此當返回NULL時，沒有必要發出額外的失敗消息。
+在沒有 __GFP_NOWARN 的情況下使用時，這些通用分配函式都會在失敗時發起堆疊轉儲，
+因此當返回NULL時，沒有必要發出額外的失敗訊息。
 
-15) 內聯弊病
+15) 行內弊病
 ------------
 
-有一個常見的誤解是 ``內聯`` 是 gcc 提供的可以讓代碼運行更快的一個選項。雖然使
-用內聯函數有時候是恰當的 (比如作爲一種替代宏的方式，請看第十二章)，不過很多情
-況下不是這樣。inline 的過度使用會使內核變大，從而使整個系統運行速度變慢。
-因爲體積大內核會佔用更多的指令高速緩存，而且會導致 pagecache 的可用內存減少。
-想象一下，一次 pagecache 未命中就會導致一次磁盤尋址，將耗時 5 毫秒。5 毫秒的
-時間內 CPU 能執行很多很多指令。
-
-一個基本的原則是如果一個函數有 3 行以上，就不要把它變成內聯函數。這個原則的一
-個例外是，如果你知道某個參數是一個編譯時常量，而且因爲這個常量你確定編譯器在
-編譯時能優化掉你的函數的大部分代碼，那仍然可以給它加上 inline 關鍵字。
-kmalloc() 內聯函數就是一個很好的例子。
-
-人們經常主張給 static 的而且只用了一次的函數加上 inline，如此不會有任何損失，
-因爲沒有什麼好權衡的。雖然從技術上說這是正確的，但是實際上這種情況下即使不加
-inline gcc 也可以自動使其內聯。而且其他用戶可能會要求移除 inline，由此而來的
+有一個常見的誤解是 ``行內`` 是 gcc 提供的可以讓程式碼執行更快的一個選項。
+雖然使用行內函式有時候是恰當的 (比如作為一種替代巨集的方式，請看第十二章)，
+不過很多情況下不是這樣。inline 的過度使用會使核心變大，從而使整個系統執行
+速度變慢。因為體積大核心會佔用更多的指令高速快取，而且會導致 pagecache 的
+可用記憶體減少。想象一下，一次 pagecache 未命中就會導致一次磁碟尋址，將耗
+時 5 毫秒。5 毫秒的時間內 CPU 能執行很多很多指令。
+
+一個基本的原則是如果一個函式有 3 行以上，就不要把它變成行內函式。這個原則的一
+個例外是，如果你知道某個參數是一個編譯時常數，而且因為這個常數你確定編譯器在
+編譯時能最佳化掉你的函式的大部分程式碼，那仍然可以給它加上 inline 關鍵字。
+kmalloc() 行內函式就是一個很好的例子。
+
+人們經常主張給 static 的而且只用了一次的函式加上 inline，如此不會有任何損失，
+因為沒有什麼好權衡的。雖然從技術上說這是正確的，但是實際上這種情況下即使不加
+inline gcc 也可以自動使其行內。而且其他使用者可能會要求移除 inline，由此而來的
 爭論會抵消 inline 自身的潛在價值，得不償失。
 
 
-16) 函數返回值及命名
+16) 函式回傳值及命名
 --------------------
 
-函數可以返回多種不同類型的值，最常見的一種是表明函數執行成功或者失敗的值。這樣
-的一個值可以表示爲一個錯誤代碼整數 (-Exxx＝失敗，0＝成功) 或者一個 ``成功``
-布爾值 (0＝失敗，非0＝成功)。
+函式可以返回多種不同類型的值，最常見的一種是表明函式執行成功或者失敗的值。這樣
+的一個值可以表示為一個錯誤程式碼整數 (-Exxx＝失敗，0＝成功) 或者一個 ``成功``
+布林值 (0＝失敗，非0＝成功)。
 
 混合使用這兩種表達方式是難於發現的 bug 的來源。如果 C 語言本身嚴格區分整形和
-布爾型變量，那麼編譯器就能夠幫我們發現這些錯誤... 不過 C 語言不區分。爲了避免
+布林型變數，那麼編譯器就能夠幫我們發現這些錯誤... 不過 C 語言不區分。為了避免
 產生這種 bug，請遵循下面的慣例::
 
-	如果函數的名字是一個動作或者強制性的命令，那麼這個函數應該返回錯誤代
-	碼整數。如果是一個判斷，那麼函數應該返回一個“成功”布爾值。
+	如果函式的名字是一個動作或者強制性的命令，那麼這個函式應該返回錯誤代
+	碼整數。如果是一個判斷，那麼函式應該返回一個“成功”布林值。
 
 比如， ``add work`` 是一個命令，所以 add_work() 在成功時返回 0，在失敗時返回
--EBUSY。類似的，因爲 ``PCI device present`` 是一個判斷，所以 pci_dev_present()
+-EBUSY。類似的，因為 ``PCI device present`` 是一個判斷，所以 pci_dev_present()
 在成功找到一個匹配的設備時應該返回 1，如果找不到時應該返回 0。
 
-所有 EXPORTed 函數都必須遵守這個慣例，所有的公共函數也都應該如此。私有
-(static) 函數不需要如此，但是我們也推薦這樣做。
+所有 EXPORTed 函式都必須遵守這個慣例，所有的公共函式也都應該如此。私有
+(static) 函式不需要如此，但是我們也推薦這樣做。
 
-返回值是實際計算結果而不是計算是否成功的標誌的函數不受此慣例的限制。通常
-他們通過返回一些正常值範圍之外的結果來表示出錯。典型的例子是返回指針的函數，
+回傳值是實際計算結果而不是計算是否成功的標誌的函式不受此慣例的限制。通常
+他們透過返回一些正常值範圍之外的結果來表示出錯。典型的例子是返回指標的函式，
 他們使用 NULL 或者 ERR_PTR 機制來報告錯誤。
 
-17) 使用布爾類型
+17) 使用布林類型
 ----------------
 
-Linux內核布爾（bool）類型是C99 _Bool類型的別名。布爾值只能爲0或1，而對布爾的
-隱式或顯式轉換將自動將值轉換爲true或false。在使用布爾類型時 **不需要** 構造，
+Linux核心布林（bool）類型是C99 _Bool類型的別名。布林值只能為0或1，而對布林的
+隱式或顯式轉換將自動將值轉換為true或false。在使用布林類型時 **不需要** 構造，
 它會消除一類錯誤。
 
-使用布爾值時，應使用true和false定義，而不是1和0。
+使用布林值時，應使用true和false定義，而不是1和0。
 
-布爾函數返回類型和堆棧變量總是可以在適當的時候使用。鼓勵使用布爾來提高可讀性，
-並且布爾值在存儲時通常比“int”更好。
+布林函式返回類型和堆疊變數總是可以在適當的時候使用。鼓勵使用布林來提高可讀性，
+並且布林值在儲存時通常比“int”更好。
 
-如果緩存行佈局或值的大小很重要，請不要使用布爾，因爲其大小和對齊方式根據編譯
-的體系結構而不同。針對對齊和大小進行優化的結構體不應使用布爾。
+如果快取行佈局或值的大小很重要，請不要使用布林，因為其大小和對齊方式根據編譯
+的體系結構而不同。針對對齊和大小進行最佳化的結構體不應使用布林。
 
-如果一個結構體有多個true/false值，請考慮將它們合併爲具有1比特成員的位域，或使
+如果一個結構體有多個true/false值，請考慮將它們合併為具有1比特成員的位域，或使
 用適當的固定寬度類型，如u8。
 
-類似地，對於函數參數，多個true/false值可以合併爲單個按位的“標誌”參數，如果調
-用點具有裸true/false常量，“標誌”參數通常是更具可讀性的替代方法。
+類似地，對於函式參數，多個true/false值可以合併為單個按位的“標誌”參數，如果調
+用點具有裸true/false常數，“標誌”參數通常是更具可讀性的替代方法。
 
-總之，在結構體和參數中有限地使用布爾可以提高可讀性。
+總之，在結構體和參數中有限地使用布林可以提高可讀性。
 
-18) 不要重新發明內核宏
-----------------------
+18) 不要重新發明核心巨集
+------------------------
 
-頭文件 include/linux/kernel.h 包含了一些宏，你應該使用它們，而不要自己寫一些
-它們的變種。比如，如果你需要計算一個數組的長度，使用這個宏
+標頭檔 include/linux/kernel.h 包含了一些巨集，你應該使用它們，而不要自己寫一些
+它們的變種。比如，如果你需要計算一個陣列的長度，使用這個巨集
 
 .. code-block:: c
 
@@ -938,15 +946,15 @@ Linux內核布爾（bool）類型是C99 _Bool類型的別名。布爾值只能�
 
 	#define sizeof_field(t, f) (sizeof(((t*)0)->f))
 
-還有可以做嚴格的類型檢查的 min() 和 max() 宏，如果你需要可以使用它們。你可以
-自己看看那個頭文件裏還定義了什麼你可以拿來用的東西，如果有定義的話，你就不應
-在你的代碼裏自己重新定義。
+還有可以做嚴格的類型檢查的 min() 和 max() 巨集，如果你需要可以使用它們。你可以
+自己看看那個標頭檔裡還定義了什麼你可以拿來用的東西，如果有定義的話，你就不應
+在你的程式碼裡自己重新定義。
 
 
 19) 編輯器模式行和其他需要羅嗦的事情
 ------------------------------------
 
-有一些編輯器可以解釋嵌入在源文件裏的由一些特殊標記標明的配置信息。比如，emacs
+有一些編輯器可以解釋嵌入在原始檔裡的由一些特殊標記標明的設定資訊。比如，emacs
 能夠解析被標記成這樣的行：
 
 .. code-block:: c
@@ -969,29 +977,29 @@ Vim 能夠解析這樣的標記：
 
 	/* vim:set sw=8 noet */
 
-不要在源代碼中包含任何這樣的內容。每個人都有他自己的編輯器配置，你的源文件不
-應該覆蓋別人的配置。這包括有關縮進和模式配置的標記。人們可以使用他們自己定製
-的模式，或者使用其他可以產生正確的縮進的巧妙方法。
+不要在原始程式碼中包含任何這樣的內容。每個人都有他自己的編輯器設定，你的原
+始檔不應該覆蓋別人的設定。這包括有關縮排和模式設定的標記。人們可以使用他們
+自己定製的模式，或者使用其他可以產生正確的縮排的巧妙方法。
 
 
-20) 內聯彙編
+20) 行內組譯
 ------------
 
-在特定架構的代碼中，你可能需要內聯彙編與 CPU 和平臺相關功能連接。需要這麼做時
-就不要猶豫。然而，當 C 可以完成工作時，不要平白無故地使用內聯彙編。在可能的情
-況下，你可以並且應該用 C 和硬件溝通。
+在特定架構的程式碼中，你可能需要行內組譯與 CPU 和平臺相關功能連接。需要這
+麼做時就不要猶豫。然而，當 C 可以完成工作時，不要平白無故地使用行內組譯。
+在可能的情況下，你可以並且應該用 C 和硬體溝通。
 
-請考慮去寫捆綁通用位元 (wrap common bits) 的內聯彙編的簡單輔助函數，別去重複
-地寫下只有細微差異內聯彙編。記住內聯彙編可以使用 C 參數。
+請考慮去寫捆綁通用位元 (wrap common bits) 的行內組譯的簡單輔助函式，別去重複
+地寫下只有細微差異行內組譯。記住行內組譯可以使用 C 參數。
 
-大型，有一定複雜度的彙編函數應該放在 .S 文件內，用相應的 C 原型定義在 C 頭文
-件中。彙編函數的 C 原型應該使用 ``asmlinkage`` 。
+大型，有一定複雜度的組譯函式應該放在 .S 檔案內，用相應的 C 原型定義在 C 標頭
+檔中。組譯函式的 C 原型應該使用 ``asmlinkage`` 。
 
-你可能需要把彙編語句標記爲 volatile，用來阻止 GCC 在沒發現任何副作用後就把它
-移除了。你不必總是這樣做，儘管，這不必要的舉動會限制優化。
+你可能需要把組譯語句標記為 volatile，用來阻止 GCC 在沒發現任何副作用後就把它
+移除了。你不必總是這樣做，儘管，這不必要的舉動會限制最佳化。
 
-在寫一個包含多條指令的單個內聯彙編語句時，把每條指令用引號分割而且各佔一行，
-除了最後一條指令外，在每個指令結尾加上 ``\n\t`` ，讓彙編輸出時可以正確地縮進
+在寫一個包含多條指令的單個行內組譯語句時，把每條指令用引號分割而且各佔一行，
+除了最後一條指令外，在每個指令結尾加上 ``\n\t`` ，讓組譯輸出時可以正確地縮排
 下一條指令：
 
 .. code-block:: c
@@ -1004,21 +1012,21 @@ Vim 能夠解析這樣的標記：
 21) 條件編譯
 ------------
 
-只要可能，就不要在 .c 文件裏面使用預處理條件 (#if, #ifdef)；這樣做會讓代碼更難
-閱讀並且更難去跟蹤邏輯。替代方案是，在頭文件中用預處理條件提供給那些 .c 文件
-使用，再給 #else 提供一個空樁 (no-op stub) 版本，然後在 .c 文件內無條件地調用
-那些 (定義在頭文件內的) 函數。這樣做，編譯器會避免爲樁函數 (stub) 的調用生成
-任何代碼，產生的結果是相同的，但邏輯將更加清晰。
+只要可能，就不要在 .c 檔案裡面使用預處理條件 (#if, #ifdef)；這樣做會讓程式
+碼更難閱讀並且更難去追蹤邏輯。替代方案是，在標頭檔中用預處理條件提供給那些
+.c 檔案使用，再給 #else 提供一個空樁 (no-op stub) 版本，然後在 .c 檔案內無
+條件地呼叫那些 (定義在標頭檔內的) 函式。這樣做，編譯器會避免為樁函式 (stub
+) 的呼叫產生任何程式碼，產生的結果是相同的，但邏輯將更加清晰。
 
-最好傾向於編譯整個函數，而不是函數的一部分或表達式的一部分。與其放一個 ifdef
-在表達式內，不如分解出部分或全部表達式，放進一個單獨的輔助函數，並應用預處理
-條件到這個輔助函數內。
+最好傾向於編譯整個函式，而不是函式的一部分或表達式的一部分。與其放一個 ifdef
+在表達式內，不如分解出部分或全部表達式，放進一個單獨的輔助函式，並應用預處理
+條件到這個輔助函式內。
 
-如果你有一個在特定配置中，可能變成未使用的函數或變量，編譯器會警告它定義了但
-未使用，請把它標記爲 __maybe_unused 而不是將它包含在一個預處理條件中。(然而，
-如果一個函數或變量總是未使用，就直接刪除它。)
+如果你有一個在特定設定中，可能變成未使用的函式或變數，編譯器會警告它定義了但
+未使用，請把它標記為 __maybe_unused 而不是將它包含在一個預處理條件中。(然而，
+如果一個函式或變數總是未使用，就直接刪除它。)
 
-在代碼中，儘可能地使用 IS_ENABLED 宏來轉化某個 Kconfig 標記爲 C 的布爾
+在程式碼中，儘可能地使用 IS_ENABLED 巨集來轉化某個 Kconfig 標記為 C 的布林
 表達式，並在一般的 C 條件中使用它：
 
 .. code-block:: c
@@ -1027,13 +1035,13 @@ Vim 能夠解析這樣的標記：
 		...
 	}
 
-編譯器會做常量摺疊，然後就像使用 #ifdef 那樣去包含或排除代碼塊，所以這不會帶
-來任何運行時開銷。然而，這種方法依舊允許 C 編譯器查看塊內的代碼，並檢查它的正
-確性 (語法，類型，符號引用，等等)。因此，如果條件不滿足，代碼塊內的引用符號就
-不存在時，你還是必須去用 #ifdef。
+編譯器會做常數摺疊，然後就像使用 #ifdef 那樣去包含或排除程式碼塊，所以這不
+會帶來任何執行時開銷。然而，這種方法依舊允許 C 編譯器查看塊內的程式碼，並
+檢查它的正確性 (語法，類型，符號引用，等等)。因此，如果條件不滿足，程式碼
+塊內的引用符號就不存在時，你還是必須去用 #ifdef。
 
 在任何有意義的 #if 或 #ifdef 塊的末尾 (超過幾行的)，在 #endif 同一行的後面寫下
-註解，註釋這個條件表達式。例如：
+註解，註解這個條件表達式。例如：
 
 .. code-block:: c
 
@@ -1052,7 +1060,7 @@ ISBN 0-13-110362-8 (平裝), 0-13-110370-9 (精裝).
 
 .. note::
 
-    《C程序設計語言（第2版）》
+    《C程式設計語言（第2版）》
     作者：[美] Brian W. Kernighan / [美] Dennis M. Ritchie
     譯者：徐寶文 / 李志 / 尤晉元（審校）
     出版社：機械工業出版社，2019
@@ -1065,23 +1073,23 @@ ISBN 0-201-61586-X.
 
 .. note::
 
-    《程序設計實踐》
+    《程式設計實踐》
     作者：[美] Brian W. Kernighan / [美] Rob Pike
     出版社：機械工業出版社，2005
     ISBN：9787111091578
 
-    《程序設計實踐》
+    《程式設計實踐》
     作者：[美] Brian W. Kernighan / Rob Pike
     譯者：裘宗燕
     出版社：機械工業出版社，2000
     ISBN：9787111075738
 
-GNU 手冊 - 遵循 K&R 標準和此文本 - cpp, gcc, gcc internals and indent,
+GNU 手冊 - 遵循 K&R 標準和此文字 - cpp, gcc, gcc internals and indent,
 都可以從 https://www.gnu.org/manual/ 找到
 
 WG14 是 C 語言的國際標準化工作組，URL: http://www.open-std.org/JTC1/SC22/WG14/
 
-內核文檔 Documentation/process/coding-style.rst，
+核心文件 Documentation/process/coding-style.rst，
 作者 greg@kroah.com 發表於 OLS 2002：
 http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/
 
diff --git a/Documentation/translations/zh_TW/process/email-clients.rst b/Documentation/translations/zh_TW/process/email-clients.rst
index 4543c447d797..4fae2fdbb3bf 100644
--- a/Documentation/translations/zh_TW/process/email-clients.rst
+++ b/Documentation/translations/zh_TW/process/email-clients.rst
@@ -16,87 +16,89 @@
  - Xiaochen Wang <wangxiaochen0@gmail.com>
  - yaxinsn <yaxinsn@163.com>
  - Hu Haowen <2023002089@link.tyut.edu.cn>
+ - Chen-Yu Yeh <chenyou910331@gmail.com>
 
-Linux郵件客戶端配置信息
+Linux郵件客戶端設定資訊
 =======================
 
 Git
 ---
 
 現在大多數開發人員使用 ``git send-email`` 而不是常規的電子郵件客戶端。這方面
-的手冊非常好。在接收端，維護人員使用 ``git am`` 加載補丁。
+的手冊非常好。在接收端，維護人員使用 ``git am`` 載入補丁。
 
-如果你是 ``git`` 新手，那麼把你的第一個補丁發送給你自己。將其保存爲包含所有
-標題的原始文本。運行 ``git am raw_email.txt`` ，然後使用 ``git log`` 查看更
+如果你是 ``git`` 新手，那麼把你的第一個補丁發送給你自己。將其保存為包含所有
+標題的原始文字。執行 ``git am raw_email.txt`` ，然後使用 ``git log`` 查看更
 改日誌。如果工作正常，再將補丁發送到相應的郵件列表。
 
 
-通用配置
+通用設定
 --------
 
-Linux內核補丁是通過郵件被提交的，最好把補丁作爲郵件體的內嵌文本。有些維護者
+Linux核心補丁是透過郵件被提交的，最好把補丁作為郵件體的內嵌文字。有些維護者
 接收附件，但是附件的內容格式應該是"text/plain"。然而，附件一般是不贊成的，
-因爲這會使補丁的引用部分在評論過程中變的很困難。
+因為這會使補丁的引用部分在評論過程中變得很困難。
 
-同時也強烈建議在補丁或其他郵件的正文中使用純文本格式。https://useplaintext.email
-有助於瞭解如何配置你喜歡的郵件客戶端，並在您還沒有首選的情況下列出一些推薦的
+同時也強烈建議在補丁或其他郵件的正文中使用純文字格式。https://useplaintext.email
+有助於瞭解如何設定你喜歡的郵件客戶端，並在您還沒有首選的情況下列出一些推薦的
 客戶端。
 
-用來發送Linux內核補丁的郵件客戶端在發送補丁時應該處於文本的原始狀態。例如，
+用來發送Linux核心補丁的郵件客戶端在發送補丁時應該處於文字的原始狀態。例如，
 他們不能改變或者刪除製表符或者空格，甚至是在每一行的開頭或者結尾。
 
-不要通過"format=flowed"模式發送補丁。這樣會引起不可預期以及有害的斷行。
+不要透過"format=flowed"模式發送補丁。這樣會引起不可預期以及有害的斷行。
 
 不要讓你的郵件客戶端進行自動換行。這樣也會破壞你的補丁。
 
-郵件客戶端不能改變文本的字符集編碼方式。要發送的補丁只能是ASCII或者UTF-8編碼
-方式，如果你使用UTF-8編碼方式發送郵件，那麼你將會避免一些可能發生的字符集問題。
+郵件客戶端不能改變文字的字元集編碼方式。要發送的補丁只能是ASCII或者UTF-8編
+碼方式，如果你使用UTF-8編碼方式發送郵件，那麼你將會避免一些可能發生的字元
+集問題。
 
-郵件客戶端應該生成並且保持“References:”或者“In-Reply-To:”郵件頭，這樣郵件會話
+郵件客戶端應該產生並且保持“References:”或者“In-Reply-To:”郵件頭，這樣郵件會話
 就不會中斷。
 
-複製粘帖(或者剪貼粘帖)通常不能用於補丁，因爲製表符會轉換爲空格。使用xclipboard,
-xclip或者xcutsel也許可以，但是最好測試一下或者避免使用複製粘帖。
+複製貼上(或者剪貼貼上)通常不能用於補丁，因為製表符會轉換為空格。使用
+xclipboard,xclip或者xcutsel也許可以，但是最好測試一下或者避免使用複製貼上。
 
 不要在使用PGP/GPG簽名的郵件中包含補丁。這樣會使得很多腳本不能讀取和適用於你的
 補丁。（這個問題應該是可以修復的）
 
-在給內核郵件列表發送補丁之前，給自己發送一個補丁是個不錯的主意，保存接收到的
-郵件，將補丁用'patch'命令打上，如果成功了，再給內核郵件列表發送。
+在給核心郵件列表發送補丁之前，給自己發送一個補丁是個不錯的主意，保存接收到的
+郵件，將補丁用'patch'命令打上，如果成功了，再給核心郵件列表發送。
 
 
 一些郵件客戶端提示
 ------------------
 
-這裏給出一些詳細的MUA配置提示，可以用於給Linux內核發送補丁。這些並不意味是
-所有的軟件包配置總結。
+這裡給出一些詳細的MUA設定提示，可以用於給Linux核心發送補丁。這些並不意味是
+所有的軟體套件設定總結。
 
 說明：
 
-- TUI = 以文本爲基礎的用戶接口
-- GUI = 圖形界面用戶接口
+- TUI = 以文字為基礎的使用者介面
+- GUI = 圖形介面使用者介面
 
 Alpine (TUI)
 ************
 
-配置選項：
+設定選項：
 
-在 :menuselection:`Sending Preferences` 菜單：
+在 :menuselection:`Sending Preferences` 選單：
 
-- :menuselection:`Do Not Send Flowed Text` 必須開啓
+- :menuselection:`Do Not Send Flowed Text` 必須開啟
 - :menuselection:`Strip Whitespace Before Sending` 必須關閉
 
-當寫郵件時，光標應該放在補丁會出現的地方，然後按下 `CTRL-R` 組合鍵，使指
-定的補丁文件嵌入到郵件中。
+當寫郵件時，游標應該放在補丁會出現的地方，然後按下 `CTRL-R` 組合鍵，使指
+定的補丁檔案嵌入到郵件中。
 
 Claws Mail (GUI)
 ****************
 
 可以用，有人用它成功地發過補丁。
 
-用 :menuselection:`Message-->Insert File` (`CTRL-I`) 或外置編輯器插入補丁。
+用 :menuselection:`Message-->Insert File` (`CTRL-I`) 或外部編輯器插入補丁。
 
-若要在Claws編輯窗口重修改插入的補丁，需關閉
+若要在Claws編輯視窗重修改插入的補丁，需關閉
 :menuselection:`Configuration-->Preferences-->Compose-->Wrapping`
 的 `Auto wrapping` 。
 
@@ -107,49 +109,49 @@ Evolution (GUI)
 
 撰寫郵件時：
 從 :menuselection:`格式-->段落樣式-->預格式化` (`CTRL-7`)
-或工具欄選擇 :menuselection:`預格式化` ；
+或工具列選擇 :menuselection:`預格式化` ；
 
 然後使用：
-:menuselection:`插入-->文本文件...` (`ALT-N x`) 插入補丁文件。
+:menuselection:`插入-->文字檔...` (`ALT-N x`) 插入補丁檔案。
 
 你還可以 ``diff -Nru old.c new.c | xclip`` ，選擇 :menuselection:`預格式化` ，
-然後使用鼠標中鍵進行粘帖。
+然後使用滑鼠中鍵進行貼上。
 
 Kmail (GUI)
 ***********
 
 一些開發者成功的使用它發送補丁。
 
-默認撰寫設置禁用HTML格式是合適的；不要啓用它。
+預設撰寫設定禁用HTML格式是合適的；不要啟用它。
 
 當書寫一封郵件的時候，在選項下面不要選擇自動換行。唯一的缺點就是你在郵件中輸
-入的任何文本都不會被自動換行，因此你必須在發送補丁之前手動換行。最簡單的方法
-就是啓用自動換行來書寫郵件，然後把它保存爲草稿。一旦你在草稿中再次打開它，它
+入的任何文字都不會被自動換行，因此你必須在發送補丁之前手動換行。最簡單的方法
+就是啟用自動換行來書寫郵件，然後把它保存為草稿。一旦你在草稿中再次開啟它，它
 已經全部自動換行了，那麼你的郵件雖然沒有選擇自動換行，但是還不會失去已有的自
 動換行。
 
-在郵件的底部，插入補丁之前，放上常用的補丁定界符：三個連字符(``---``)。
+在郵件的底部，插入補丁之前，放上常用的補丁定界符：三個連字元(``---``)。
 
-然後在 :menuselection:`信件` 菜單，選擇 :menuselection:`插入文本文件` ，接
-着選取你的補丁文件。還有一個額外的選項，你可以通過它配置你的創建新郵件工具欄，
-加上 :menuselection:`插入文本文件` 圖標。
+然後在 :menuselection:`信件` 選單，選擇 :menuselection:`插入文字檔` ，接
+著選取你的補丁檔案。還有一個額外的選項，你可以透過它設定你的建立新郵件工具列，
+加上 :menuselection:`插入文字檔` 圖示。
 
-將編輯器窗口拉到足夠寬避免折行。對於KMail 1.13.5 (KDE 4.5.4)，它會在發送郵件
-時對編輯器窗口中顯示折行的地方自動換行。在選項菜單中取消自動換行仍不能解決。
-因此，如果你的補丁中有非常長的行，必須在發送之前把編輯器窗口拉得非常寬。
+將編輯器視窗拉到足夠寬避免折行。對於KMail 1.13.5 (KDE 4.5.4)，它會在發送郵件
+時對編輯器視窗中顯示折行的地方自動換行。在選項選單中取消自動換行仍不能解決。
+因此，如果你的補丁中有非常長的行，必須在發送之前把編輯器視窗拉得非常寬。
 參見：https://bugs.kde.org/show_bug.cgi?id=174034
 
-你可以安全地用GPG簽名附件，但是內嵌補丁最好不要使用GPG簽名它們。作爲內嵌文本
+你可以安全地用GPG簽名附件，但是內嵌補丁最好不要使用GPG簽名它們。作為內嵌文字
 插入的簽名補丁將使其難以從7-bit編碼中提取。
 
 如果你非要以附件的形式發送補丁，那麼就右鍵點擊附件，然後選擇
-:menuselection:`屬性` ，打開 :menuselection:`建議自動顯示` ，使附件內聯更容
+:menuselection:`屬性` ，開啟 :menuselection:`建議自動顯示` ，使附件內聯更容
 易讓讀者看到。
 
-當你要保存將要發送的內嵌文本補丁，你可以從消息列表窗格選擇包含補丁的郵件，然
-後右鍵選擇 :menuselection:`另存爲` 。如果整個電子郵件的組成正確，您可直接將
-其作爲補丁使用。電子郵件以當前用戶可讀寫權限保存，因此您必須 ``chmod`` ，以
-使其在複製到別處時用戶組和其他人可讀。
+當你要保存將要發送的內嵌文字補丁，你可以從訊息列表窗格選擇包含補丁的郵件，然
+後右鍵選擇 :menuselection:`另存新檔` 。如果整個電子郵件的組成正確，您可直接將
+其作為補丁使用。電子郵件以當前使用者可讀寫權限保存，因此您必須 ``chmod`` ，以
+使其在複製到別處時使用者組和其他人可讀。
 
 Lotus Notes (GUI)
 *****************
@@ -167,9 +169,9 @@ Mutt (TUI)
 很多Linux開發人員使用mutt客戶端，這證明它肯定工作得非常漂亮。
 
 Mutt不自帶編輯器，所以不管你使用什麼編輯器，不自動斷行就行。大多數編輯器都有
-:menuselection:`插入文件` 選項，它可以在不改變文件內容的情況下插入文件。
+:menuselection:`插入檔案` 選項，它可以在不改變檔案內容的情況下插入檔案。
 
-用 ``vim`` 作爲mutt的編輯器::
+用 ``vim`` 作為mutt的編輯器::
 
   set editor="vi"
 
@@ -181,21 +183,21 @@ Mutt不自帶編輯器，所以不管你使用什麼編輯器，不自動斷行�
 
   :r filename
 
-把補丁插入爲內嵌文本。
-在未設置  ``set paste`` 時(a)ttach工作的很好。
+把補丁插入為內嵌文字。
+在未設定  ``set paste`` 時(a)ttach工作的很好。
 
-你可以通過 ``git format-patch`` 生成補丁，然後用 Mutt發送它們::
+你可以透過 ``git format-patch`` 產生補丁，然後用 Mutt發送它們::
 
     $ mutt -H 0001-some-bug-fix.patch
 
-配置選項：
+設定選項：
 
-它應該以默認設置的形式工作。
-然而，把 ``send_charset`` 設置一下也是一個不錯的主意::
+它應該以預設設定的形式工作。
+然而，把 ``send_charset`` 設定一下也是一個不錯的主意::
 
   set send_charset="us-ascii:utf-8"
 
-Mutt 是高度可配置的。 這裏是個使用mutt通過 Gmail 發送的補丁的最小配置::
+Mutt 是高度可設定的。 這裡是個使用mutt透過 Gmail 發送的補丁的最小設定::
 
   # .muttrc
   # ================  IMAP ====================
@@ -222,7 +224,7 @@ Mutt 是高度可配置的。 這裏是個使用mutt通過 Gmail 發送的補丁
   set from = "username@gmail.com"
   set use_from = yes
 
-Mutt文檔含有更多信息：
+Mutt文件含有更多資訊：
 
     https://gitlab.com/muttmua/mutt/-/wikis/UseCases/Gmail
 
@@ -235,7 +237,7 @@ Pine過去有一些空格刪減問題，但是這些現在應該都被修復了�
 
 如果可以，請使用alpine（pine的繼承者）。
 
-配置選項：
+設定選項：
 
 - 最近的版本需要 ``quell-flowed-text``
 - ``no-strip-whitespace-before-send`` 選項也是需要的。
@@ -244,23 +246,23 @@ Pine過去有一些空格刪減問題，但是這些現在應該都被修復了�
 Sylpheed (GUI)
 **************
 
-- 內嵌文本可以很好的工作（或者使用附件）。
+- 內嵌文字可以很好的工作（或者使用附件）。
 - 允許使用外部的編輯器。
 - 收件箱較多時非常慢。
-- 如果通過non-SSL連接，無法使用TLS SMTP授權。
-- 撰寫窗口的標尺很有用。
+- 如果透過non-SSL連接，無法使用TLS SMTP授權。
+- 撰寫視窗的標尺很有用。
 - 將地址添加到通訊簿時無法正確理解顯示的名稱。
 
 Thunderbird (GUI)
 *****************
 
-Thunderbird是Outlook的克隆版本，它很容易損壞文本，但也有一些方法強制修正。
+Thunderbird是Outlook的翻版，它很容易損壞文字，但也有一些方法強制修正。
 
-在完成修改後（包括安裝擴展），您需要重新啓動Thunderbird。
+在完成修改後（包括安裝擴展），您需要重新啟動Thunderbird。
 
 - 允許使用外部編輯器：
 
-  使用Thunderbird發補丁最簡單的方法是使用擴展來打開您最喜歡的外部編輯器。
+  使用Thunderbird發補丁最簡單的方法是使用擴展來開啟您最喜歡的外部編輯器。
 
   下面是一些能夠做到這一點的擴展樣例。
 
@@ -270,43 +272,50 @@ Thunderbird是Outlook的克隆版本，它很容易損壞文本，但也有一�
 
     https://addons.thunderbird.net/en-GB/thunderbird/addon/external-editor-revived/
 
-    它需要安裝“本地消息主機（native messaging host）”。
-    參見以下文檔:
+    它需要安裝“本地訊息主機（native messaging host）”。
+    參見以下文件:
     https://github.com/Frederick888/external-editor-revived/wiki
 
   - “External Editor”
 
     https://github.com/exteditor/exteditor
 
-    下載並安裝此擴展，然後打開 :menuselection:`新建消息` 窗口, 用
-    :menuselection:`查看-->工具欄-->自定義...` 給它增加一個按鈕，直接點擊此
-    按鈕即可使用外置編輯器。
+    下載並安裝此擴展，然後開啟 :menuselection:`新增訊息` 視窗, 用
+    :menuselection:`查看-->工具列-->自訂...` 給它增加一個按鈕，直接點擊此
+    按鈕即可使用外部編輯器。
 
     請注意，“External Editor”要求你的編輯器不能fork，換句話說，編輯器必須在
-    關閉前不返回。你可能需要傳遞額外的參數或修改編輯器設置。最值得注意的是，
-    如果您使用的是gvim，那麼您必須將 :menuselection:`external editor` 設置的
-    編輯器字段設置爲 ``/usr/bin/gvim --nofork"`` （假設可執行文件在
+    關閉前不返回。你可能需要傳遞額外的參數或修改編輯器設定。最值得注意的是，
+    如果您使用的是gvim，那麼您必須將 :menuselection:`external editor` 設定的
+    編輯器欄位設定為 ``/usr/bin/gvim --nofork"`` （假設可執行檔在
     ``/usr/bin`` ），以傳遞 ``-f`` 參數。如果您正在使用其他編輯器，請閱讀其
     手冊瞭解如何處理。
 
 若要修正內部編輯器，請執行以下操作：
 
-- 修改你的Thunderbird設置，不要使用 ``format=flowed`` ！
-  回到主窗口，按照
-  :menuselection:`主菜單-->首選項-->常規-->配置編輯器...`
-  打開Thunderbird的配置編輯器。
+- 修改你的Thunderbird設定，不要使用 ``format=flowed`` ！
+  回到主視窗，按照
+  :menuselection:`主選單-->偏好設定-->常規-->設定編輯器...`
+  開啟Thunderbird的設定編輯器。
 
-  - 將 ``mailnews.send_plaintext_flowed`` 設爲 ``false``
+  - 將 ``mailnews.send_plaintext_flowed`` 設為 ``false``
 
-  - 將 ``mailnews.wraplength`` 從 ``72`` 改爲 ``0``
+  - 將 ``mailnews.wraplength`` 從 ``72`` 改為 ``0`` ，**或者** 安裝
+    “Toggle Line Wrap”擴展
+
+    https://github.com/jan-kiszka/togglelinewrap
+
+    https://addons.thunderbird.net/thunderbird/addon/toggle-line-wrap
+
+    以便即時控制此設定項。
 
 - 不要寫HTML郵件！
-  回到主窗口，打開
-  :menuselection:`主菜單-->賬戶設置-->你的@郵件.地址-->通訊錄/編寫&地址簿` ，
-  關掉 ``以HTML格式編寫消息`` 。
+  回到主視窗，開啟
+  :menuselection:`主選單-->帳戶設定-->你的@郵件.地址-->通訊錄/編寫&地址簿` ，
+  關掉 ``以HTML格式編寫訊息`` 。
 
-- 只用純文本格式查看郵件！
-  回到主窗口， :menuselection:`主菜單-->查看-->消息體爲-->純文本` ！
+- 只用純文字格式查看郵件！
+  回到主視窗， :menuselection:`主選單-->查看-->訊息體為-->純文字` ！
 
 TkRat (GUI)
 ***********
@@ -318,12 +327,12 @@ Gmail (Web GUI)
 
 不要使用它發送補丁。
 
-Gmail網頁客戶端自動地把製表符轉換爲空格。
+Gmail網頁客戶端自動地把製表符轉換為空格。
 
-雖然製表符轉換爲空格問題可以被外部編輯器解決，但它同時還會使用回車換行把每行
-拆分爲78個字符。
+雖然製表符轉換為空格問題可以被外部編輯器解決，但它同時還會使用回車換行把每行
+拆分為78個字元。
 
-另一個問題是Gmail還會把任何含有非ASCII的字符的消息改用base64編碼，如歐洲人的
+另一個問題是Gmail還會把任何含有非ASCII的字元的訊息改用base64編碼，如歐洲人的
 名字。
 
 
diff --git a/Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst b/Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst
index 93d21fd88910..611247c816f4 100644
--- a/Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst
+++ b/Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst
@@ -5,115 +5,119 @@
 :Original: :ref:`Documentation/process/embargoed-hardware-issues.rst <embargoed_hardware_issues>`
 :Translator: Alex Shi <alex.shi@linux.alibaba.com>
              Hu Haowen <2023002089@link.tyut.edu.cn>
+             Chen-Yu Yeh <chenyou910331@gmail.com>
 
-被限制的硬件問題
+被限制的硬體問題
 ================
 
 範圍
 ----
 
-導致安全問題的硬件問題與隻影響Linux內核的純軟件錯誤是不同的安全錯誤類別。
+導致安全問題的硬體問題與只影響Linux核心的純軟體錯誤是不同的安全錯誤類別。
 
-必須區別對待諸如熔燬(Meltdown)、Spectre、L1TF等硬件問題，因爲它們通常會影響
-所有操作系統（“OS”），因此需要在不同的OS供應商、發行版、硬件供應商和其他各方
-之間進行協調。對於某些問題，軟件緩解可能依賴於微碼或固件更新，這需要進一步的
-協調。
+必須區別對待諸如熔毀(Meltdown)、Spectre、L1TF等硬體問題，因為它們通常會影
+響所有作業系統（“OS”），因此需要在不同的OS供應商、發行版、晶片供應商、硬體
+整合商和其他各方之間進行協調。對於某些問題，軟體緩解可能依賴於微碼或韌體更
+新，這需要進一步的協調。
 
 .. _tw_Contact:
 
 接觸
 ----
 
-Linux內核硬件安全小組獨立於普通的Linux內核安全小組。
+Linux核心硬體安全小組獨立於普通的Linux核心安全小組。
 
-該小組只負責協調被限制的硬件安全問題。Linux內核中純軟件安全漏洞的報告不由該
-小組處理，報告者將被引導至常規Linux內核安全小組(:ref:`Documentation/admin-guide/
-<securitybugs>`)聯繫。
+該小組只負責協調被限制的硬體安全問題。Linux核心中純軟體安全漏洞的報告不由
+該小組處理，報告者將被引導至常規Linux核心安全小組(
+:ref:`Documentation/admin-guide/<securitybugs>`)聯繫。
 
-可以通過電子郵件 <hardware-security@kernel.org> 與小組聯繫。這是一份私密的安全
-官名單，他們將幫助您根據我們的文檔化流程協調問題。
+可以透過電子郵件 <hardware-security@kernel.org> 與小組聯繫。這是一份私密的安全
+官名單，他們將幫助您根據我們的文件化流程協調問題。
 
-郵件列表是加密的，發送到列表的電子郵件可以通過PGP或S/MIME加密，並且必須使用報告
-者的PGP密鑰或S/MIME證書籤名。該列表的PGP密鑰和S/MIME證書可從
-https://www.kernel.org/.... 獲得。
+郵件列表是加密的，發送到列表的電子郵件可以透過PGP或S/MIME加密，並且必須使
+用報告者的PGP密鑰或S/MIME證書籤名。該列表的PGP密鑰和S/MIME證書可從以下URL
+獲得：
 
-雖然硬件安全問題通常由受影響的硬件供應商處理，但我們歡迎發現潛在硬件缺陷的研究
+  - PGP: https://www.kernel.org/static/files/hardware-security.asc
+  - S/MIME: https://www.kernel.org/static/files/hardware-security.crt
+
+雖然硬體安全問題通常由受影響的晶片供應商處理，但我們歡迎發現潛在硬體缺陷的研究
 人員或個人與我們聯繫。
 
-硬件安全官
+硬體安全官
 ^^^^^^^^^^
 
-目前的硬件安全官小組:
+目前的硬體安全官小組:
 
   - Linus Torvalds（Linux基金會院士）
-  - Greg Kroah Hartman（Linux基金會院士）
+  - Greg Kroah-Hartman（Linux基金會院士）
   - Thomas Gleixner（Linux基金會院士）
 
 郵件列表的操作
 ^^^^^^^^^^^^^^
 
-處理流程中使用的加密郵件列表託管在Linux Foundation的IT基礎設施上。通過提供這項
-服務，Linux基金會的IT基礎設施安全總監在技術上有能力訪問被限制的信息，但根據他
-的僱傭合同，他必須保密。Linux基金會的IT基礎設施安全總監還負責 kernel.org 基礎
-設施。
+處理流程中使用的加密郵件列表託管在Linux基金會的IT基礎設施上。透過提供這項
+服務，Linux基金會IT營運人員在技術上有能力存取被限制的資訊，但根據其僱傭
+合約必須保密。Linux基金會的IT人員還負責營運和管理kernel.org的其餘基礎設施。
 
-Linux基金會目前的IT基礎設施安全總監是 Konstantin Ryabitsev。
+Linux基金會目前的IT專案基礎設施總監是 Konstantin Ryabitsev。
 
 保密協議
 --------
 
-Linux內核硬件安全小組不是正式的機構，因此無法簽訂任何保密協議。核心社區意識到
+Linux核心硬體安全小組不是正式的機構，因此無法簽訂任何保密協議。核心社群意識到
 這些問題的敏感性，並提供了一份諒解備忘錄。
 
 諒解備忘錄
 ----------
 
-Linux內核社區深刻理解在不同操作系統供應商、發行商、硬件供應商和其他各方之間
-進行協調時，保持硬件安全問題處於限制狀態的要求。
+Linux核心社群深刻理解在不同作業系統供應商、發行商、晶片供應商和其他各方之間
+進行協調時，保持硬體安全問題處於限制狀態的要求。
 
-Linux內核社區在過去已經成功地處理了硬件安全問題，並且有必要的機制允許在限制
-限制下進行符合社區的開發。
+Linux核心社群在過去已經成功地處理了硬體安全問題，並且有必要的機制允許在限制
+限制下進行符合社群的開發。
 
-Linux內核社區有一個專門的硬件安全小組負責初始聯繫，並監督在限制規則下處理
+Linux核心社群有一個專門的硬體安全小組負責初始聯繫，並監督在限制規則下處理
 此類問題的過程。
 
-硬件安全小組確定開發人員（領域專家），他們將組成特定問題的初始響應小組。最初
+硬體安全小組確定開發人員（領域專家），他們將組成特定問題的初始響應小組。最初
 的響應小組可以引入更多的開發人員（領域專家）以最佳的技術方式解決這個問題。
 
-所有相關開發商承諾遵守限制規定，並對收到的信息保密。違反承諾將導致立即從當前
-問題中排除，並從所有相關郵件列表中刪除。此外，硬件安全小組還將把違反者排除在
-未來的問題之外。這一後果的影響在我們社區是一種非常有效的威懾。如果發生違規
-情況，硬件安全小組將立即通知相關方。如果您或任何人發現潛在的違規行爲，請立即
-向硬件安全人員報告。
+所有相關開發商承諾遵守限制規定，並對收到的資訊保密。違反承諾將導致立即從當前
+問題中排除，並從所有相關郵件列表中刪除。此外，硬體安全小組還將把違反者排除在
+未來的問題之外。這一後果的影響在我們社群是一種非常有效的威懾。如果發生違規
+情況，硬體安全小組將立即通知相關方。如果您或任何人發現潛在的違規行為，請立即
+向硬體安全人員報告。
 
 流程
 ^^^^
 
-由於Linux內核開發的全球分佈式特性，面對面的會議幾乎不可能解決硬件安全問題。
+由於Linux核心開發的全球分散式特性，面對面的會議幾乎不可能解決硬體安全問題。
 由於時區和其他因素，電話會議很難協調，只能在絕對必要時使用。加密電子郵件已被
 證明是解決此類問題的最有效和最安全的通信方法。
 
 開始披露
 """"""""
 
-披露內容首先通過電子郵件聯繫Linux內核硬件安全小組。此初始聯繫人應包含問題的
-描述和任何已知受影響硬件的列表。如果您的組織製造或分發受影響的硬件，我們建議
-您也考慮哪些其他硬件可能會受到影響。
+披露首先按照上述聯繫方式一節，透過電子郵件聯繫Linux核心硬體安全小組。此
+初始聯繫應包含問題的描述和任何已知受影響晶片的列表。如果您的組織製造或分發
+受影響的硬體，我們建議您也考慮哪些其他硬體可能會受到影響。披露方有責任及時
+聯繫受影響的晶片供應商。
 
-硬件安全小組將提供一個特定於事件的加密郵件列表，用於與報告者進行初步討論、
+硬體安全小組將提供一個特定於事件的加密郵件列表，用於與報告者進行初步討論、
 進一步披露和協調。
 
-硬件安全小組將向披露方提供一份開發人員（領域專家）名單，在與開發人員確認他們
-將遵守本諒解備忘錄和文件化流程後，應首先告知開發人員有關該問題的信息。這些開發
-人員組成初始響應小組，並在初始接觸後負責處理問題。硬件安全小組支持響應小組，
+硬體安全小組將向披露方提供一份開發人員（領域專家）名單，在與開發人員確認他們
+將遵守本諒解備忘錄和文件化流程後，應首先告知開發人員有關該問題的資訊。這些開發
+人員組成初始響應小組，並在初始接觸後負責處理問題。硬體安全小組支援響應小組，
 但不一定參與緩解開發過程。
 
-雖然個別開發人員可能通過其僱主受到保密協議的保護，但他們不能以Linux內核開發
-人員的身份簽訂個別保密協議。但是，他們將同意遵守這一書面程序和諒解備忘錄。
+雖然個別開發人員可能透過其僱主受到保密協議的保護，但他們不能以Linux核心開發
+人員的身份簽訂個別保密協議。但是，他們將同意遵守這一書面程式和諒解備忘錄。
 
 披露方應提供已經或應該被告知該問題的所有其他實體的聯繫人名單。這有幾個目的:
 
-  - 披露的實體列表允許跨行業通信，例如其他操作系統供應商、硬件供應商等。
+  - 披露的實體列表允許跨行業通信，例如其他作業系統供應商、硬體供應商等。
 
   - 可聯繫已披露的實體，指定應參與緩解措施開發的專家。
 
@@ -123,67 +127,97 @@ Linux內核社區有一個專門的硬件安全小組負責初始聯繫，並監
 披露
 """"
 
-披露方通過特定的加密郵件列表向初始響應小組提供詳細信息。
+披露方透過特定的加密郵件列表向初始響應小組提供詳細資訊。
 
-根據我們的經驗，這些問題的技術文檔通常是一個足夠的起點，最好通過電子郵件進行
+根據我們的經驗，這些問題的技術文件通常是一個足夠的起點，最好透過電子郵件進行
 進一步的技術澄清。
 
 緩解開發
 """"""""
 
-初始響應小組設置加密郵件列表，或在適當的情況下重新修改現有郵件列表。
+初始響應小組設定加密郵件列表，或在適當的情況下重新修改現有郵件列表。
 
-使用郵件列表接近於正常的Linux開發過程，並且在過去已經成功地用於爲各種硬件安全
+使用郵件列表接近於正常的Linux開發過程，並且在過去已經成功地用於為各種硬體安全
 問題開發緩解措施。
 
-郵件列表的操作方式與正常的Linux開發相同。發佈、討論和審查修補程序，如果同意，
-則應用於非公共git存儲庫，參與開發人員只能通過安全連接訪問該存儲庫。存儲庫包含
-針對主線內核的主開發分支，並根據需要爲穩定的內核版本提供向後移植分支。
+郵件列表的操作方式與正常的Linux開發相同。發布、討論和審查修補程式，如果同意，
+則應用於非公共git儲存庫，參與開發人員只能透過安全連接存取該儲存庫。儲存庫包含
+針對主線核心的主開發分支，並根據需要為穩定的核心版本提供向後移植分支。
+
+最初的響應小組將根據需要從Linux核心開發人員社群中確定更多的專家。任何相關
+方都可以建議增補專家，每位專家都須符合上述相同的要求。
 
-最初的響應小組將根據需要從Linux內核開發人員社區中確定更多的專家。引進專家可以
-在開發過程中的任何時候發生，需要及時處理。
+引進專家可以在開發過程中的任何時候發生，需要及時處理。
 
 如果專家受僱於披露方提供的披露清單上的實體或其成員，則相關實體將要求其參與。
 
 否則，披露方將被告知專家參與的情況。諒解備忘錄涵蓋了專家，要求披露方確認參與。
 如果披露方有令人信服的理由提出異議，則必須在五個工作日內提出異議，並立即與事件
-小組解決。如果披露方在五個工作日內未作出回應，則視爲默許。
+小組解決。如果披露方在五個工作日內未作出回應，則視為默許。
 
 在確認或解決異議後，專家由事件小組披露，並進入開發過程。
 
+列表參與者不得在私有郵件列表之外交流該問題。列表參與者在處理補丁時不得使用
+任何共享資源（例如僱主的建置農場、CI系統等）。
+
+提前取得
+""""""""
+
+在列表上討論和開發的補丁，既不能分發給任何非響應小組成員的個人，也不能分發
+給任何其他組織。
+
+為了讓受影響的晶片供應商能夠與其內部團隊和產業夥伴合作進行測試、驗證和
+後勤工作，提供了以下例外：
+
+	受影響晶片供應商的指定代表可以在任何時候將補丁移交給該晶片供應商
+	的響應小組。該代表必須將移交一事通知核心響應小組。受影響的晶片
+	供應商必須為與其響應小組共享的任何補丁，制定並維護自己的、與本
+	政策一致的文件化安全流程。
+
+	晶片供應商的響應小組可以依照該晶片供應商的文件化安全流程，將這些
+	補丁分發給其產業夥伴及其內部團隊。來自產業夥伴的反饋會回到晶片
+	供應商，並由晶片供應商轉達給核心響應小組。
+
+	移交給晶片供應商的響應小組後，因晶片供應商的內部團隊或產業夥伴的
+	參與而發生的過早披露，核心響應小組不再承擔任何責任或義務。晶片
+	供應商透過同意本流程來保證這一責任免除。
+
 協調發布
 """"""""
 
-有關各方將協商限制結束的日期和時間。此時，準備好的緩解措施集成到相關的內核樹中
+有關各方將協商限制結束的日期和時間。此時，準備好的緩解措施整合到相關的核心樹中
 併發布。
 
-雖然我們理解硬件安全問題需要協調限制時間，但限制時間應限制在所有有關各方制定、
-測試和準備緩解措施所需的最短時間內。人爲地延長限制時間以滿足會議討論日期或其他
-非技術原因，會給相關的開發人員和響應小組帶來了更多的工作和負擔，因爲補丁需要
-保持最新，以便跟蹤正在進行的上游內核開發，這可能會造成衝突的更改。
+雖然我們理解硬體安全問題需要協調限制時間，但限制時間應限制在所有有關各方制定、
+測試和準備緩解措施所需的最短時間內。人為地延長限制時間以滿足會議討論日期或其他
+非技術原因，會給相關的開發人員和響應小組帶來了更多的工作和負擔，因為補丁需要
+保持最新，以便追蹤正在進行的上游核心開發，這可能會造成衝突的更改。
 
 CVE分配
 """""""
 
-硬件安全小組和初始響應小組都不分配CVE，開發過程也不需要CVE。如果CVE是由披露方
-提供的，則可用於文檔中。
+硬體安全小組和初始響應小組都不分配CVE，開發過程也不需要CVE。如果CVE是由披露方
+提供的，則可用於文件記錄目的。
 
 流程專使
 --------
 
-爲了協助這一進程，我們在各組織設立了專使，他們可以回答有關報告流程和進一步處理
+為了協助這一流程，我們在各組織設立了專使，他們可以回答有關報告流程和進一步處理
 的問題或提供指導。專使不參與特定問題的披露，除非響應小組或相關披露方提出要求。
 現任專使名單:
 
   ============= ========================================================
-  ARM
   AMD		Tom Lendacky <thomas.lendacky@amd.com>
-  IBM
+  Ampere	Darren Hart <darren@os.amperecomputing.com>
+  ARM		Catalin Marinas <catalin.marinas@arm.com>
+  IBM Power	Madhavan Srinivasan <maddy@linux.ibm.com>
+  IBM Z		Christian Borntraeger <borntraeger@de.ibm.com>
   Intel		Tony Luck <tony.luck@intel.com>
   Qualcomm	Trilok Soni <quic_tsoni@quicinc.com>
+  RISC-V	Palmer Dabbelt <palmer@dabbelt.com>
+  Samsung	Javier González <javier.gonz@samsung.com>
 
-  Microsoft	Sasha Levin <sashal@kernel.org>
-  VMware
+  Microsoft	James Morris <jamorris@linux.microsoft.com>
   Xen		Andrew Cooper <andrew.cooper3@citrix.com>
 
   Canonical	John Johansen <john.johansen@canonical.com>
@@ -192,27 +226,28 @@ CVE分配
   Red Hat	Josh Poimboeuf <jpoimboe@redhat.com>
   SUSE		Jiri Kosina <jkosina@suse.cz>
 
-  Amazon
   Google	Kees Cook <keescook@chromium.org>
+
+  LLVM		Nick Desaulniers <ndesaulniers@google.com>
   ============= ========================================================
 
-如果要將您的組織添加到專使名單中，請與硬件安全小組聯繫。被提名的專使必須完全
-理解和支持我們的過程，並且在Linux內核社區中很容易聯繫。
+如果要將您的組織添加到專使名單中，請與硬體安全小組聯繫。被提名的專使必須完全
+理解和支援我們的過程，並且在Linux核心社群中很容易聯繫。
 
 加密郵件列表
 ------------
 
 我們使用加密郵件列表進行通信。這些列表的工作原理是，發送到列表的電子郵件使用
-列表的PGP密鑰或列表的/MIME證書進行加密。郵件列表軟件對電子郵件進行解密，並
-使用訂閱者的PGP密鑰或S/MIME證書爲每個訂閱者分別對其進行重新加密。有關郵件列表
-軟件和用於確保列表安全和數據保護的設置的詳細信息，請訪問:
-https://www.kernel.org/....
+列表的PGP密鑰或列表的S/MIME證書進行加密。郵件列表軟體對電子郵件進行解密，並
+使用訂閱者的PGP密鑰或S/MIME證書為每個訂閱者分別對其進行重新加密。有關郵件列表
+軟體和用於確保列表安全和資料保護的設定的詳細資訊，請見：
+https://korg.wiki.kernel.org/userdoc/remail.
 
-關鍵點
-^^^^^^
+列表密鑰
+^^^^^^^^
 
-初次接觸見 :ref:`zh_Contact`. 對於特定於事件的郵件列表，密鑰和S/MIME證書通過
-特定列表發送的電子郵件傳遞給訂閱者。
+初次接觸見上面的 :ref:`tw_Contact` 一節。 對於特定於事件的郵件列表，密鑰和
+S/MIME證書透過特定列表發送的電子郵件傳遞給訂閱者。
 
 訂閱事件特定列表
 ^^^^^^^^^^^^^^^^
@@ -220,13 +255,13 @@ https://www.kernel.org/....
 訂閱由響應小組處理。希望參與通信的披露方將潛在訂戶的列表發送給響應組，以便
 響應組可以驗證訂閱請求。
 
-每個訂戶都需要通過電子郵件向響應小組發送訂閱請求。電子郵件必須使用訂閱服務器
-的PGP密鑰或S/MIME證書籤名。如果使用PGP密鑰，則必須從公鑰服務器獲得該密鑰，
-並且理想情況下該密鑰連接到Linux內核的PGP信任網。另請參見:
+每個訂戶都需要透過電子郵件向響應小組發送訂閱請求。電子郵件必須使用訂閱者
+的PGP密鑰或S/MIME證書籤名。如果使用PGP密鑰，則必須從公鑰伺服器獲得該密鑰，
+並且理想情況下該密鑰連接到Linux核心的PGP信任網。另請參見:
 https://www.kernel.org/signature.html.
 
-響應小組驗證訂閱者，並將訂閱者添加到列表中。訂閱後，訂閱者將收到來自郵件列表
-的電子郵件，該郵件列表使用列表的PGP密鑰或列表的/MIME證書籤名。訂閱者的電子郵件
-客戶端可以從簽名中提取PGP密鑰或S/MIME證書，以便訂閱者可以向列表發送加密電子
-郵件。
+響應小組驗證訂閱者，並將訂閱者添加到列表中。訂閱後，訂閱者將收到來自郵件列
+表的電子郵件，該郵件列表使用列表的PGP密鑰或列表的S/MIME證書籤名。訂閱者的
+電子郵件客戶端可以從簽名中提取PGP密鑰或S/MIME證書，以便訂閱者可以向列表發
+送加密電子郵件。
 
diff --git a/Documentation/translations/zh_TW/process/howto.rst b/Documentation/translations/zh_TW/process/howto.rst
index 80c416483e73..8466f6af96cc 100644
--- a/Documentation/translations/zh_TW/process/howto.rst
+++ b/Documentation/translations/zh_TW/process/howto.rst
@@ -17,13 +17,14 @@
                    陳琦  Maggie Chen <chenqi@beyondsoft.com>
                    王聰  Wang Cong <xiyou.wangcong@gmail.com>
                    胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
+                   葉宸佑 Chen-Yu Yeh <chenyou910331@gmail.com>
 
-如何參與Linux內核開發
+如何參與Linux核心開發
 =====================
 
-這是一篇將如何參與Linux內核開發的相關問題一網打盡的終極祕笈。它將指導你
-成爲一名Linux內核開發者，並且學會如何同Linux內核開發社區合作。它儘可能不
-包括任何關於內核編程的技術細節，但會給你指引一條獲得這些知識的正確途徑。
+這是一篇將如何參與Linux核心開發的相關問題一網打盡的終極祕笈。它將指導你
+成為一名Linux核心開發者，並且學會如何同Linux核心開發社群合作。它儘可能不
+包括任何關於核心程式設計的技術細節，但會給你指引一條獲得這些知識的正確途徑。
 
 如果這篇文章中的任何內容不再適用，請給文末列出的文件維護者發送補丁。
 
@@ -31,15 +32,15 @@
 入門
 ----
 
-你想了解如何成爲一名Linux內核開發者？或者老闆吩咐你「給這個設備寫個Linux
-驅動程序」？這篇文章的目的就是教會你達成這些目標的全部訣竅，它將描述你需
-要經過的流程以及給出如何同內核社區合作的一些提示。它還將試圖解釋內核社區
-爲何這樣運作。
+你想了解如何成為一名Linux核心開發者？或者老闆吩咐你「給這個設備寫個Linux
+驅動程式」？這篇文章的目的就是教會你達成這些目標的全部訣竅，它將描述你需
+要經過的流程以及給出如何同核心社群合作的一些提示。它還將試圖解釋核心社群
+為何這樣運作。
 
-Linux內核大部分是由C語言寫成的，一些體系結構相關的代碼用到了彙編語言。要
-參與內核開發，你必須精通C語言。除非你想爲某個架構開發底層代碼，否則你並
-不需要了解（任何體系結構的）彙編語言。下面列舉的書籍雖然不能替代紮實的C
-語言教育和多年的開發經驗，但如果需要的話，做爲參考還是不錯的：
+Linux核心大部分是由C語言寫成的，一些體系結構相關的程式碼用到了組譯語言。要
+參與核心開發，你必須精通C語言。除非你想為某個架構開發底層程式碼，否則你並
+不需要了解（任何體系結構的）組譯語言。下面列舉的書籍雖然不能替代紮實的C
+語言教育和多年的開發經驗，但如果需要的話，做為參考還是不錯的：
 
  - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
    《C程序設計語言（第2版·新版）》（徐寶文 李志 譯）[機械工業出版社]
@@ -48,67 +49,67 @@ Linux內核大部分是由C語言寫成的，一些體系結構相關的代碼�
  - "C:  A Reference Manual" by Harbison and Steele [Prentice Hall]
    《C語言參考手冊（原書第5版）》（邱仲潘 等譯）[機械工業出版社]
 
-Linux內核使用GNU C和GNU工具鏈開發。雖然它遵循ISO C11標準，但也用到了一些
-標準中沒有定義的擴展。內核是自給自足的C環境，不依賴於標準C庫的支持，所以
-並不支持C標準中的部分定義。比如long long類型的大數除法和浮點運算就不允許
-使用。有時候確實很難弄清楚內核對工具鏈的要求和它所使用的擴展，不幸的是目
-前還沒有明確的參考資料可以解釋它們。請查閱gcc信息頁（使用「info gcc」命令
-顯示）獲得一些這方面信息。
+Linux核心使用GNU C和GNU工具鏈開發。雖然它遵循ISO C11標準，但也用到了一些
+標準中沒有定義的擴展。核心是自給自足的C環境，不依賴於標準C庫的支援，所以
+並不支援C標準中的部分定義。比如long long類型的大數除法和浮點運算就不允許
+使用。有時候確實很難弄清楚核心對工具鏈的要求和它所使用的擴展，不幸的是目
+前還沒有明確的參考資料可以解釋它們。請查閱gcc資訊頁（使用「info gcc」命令
+顯示）獲得一些這方面資訊。
 
-請記住你是在學習怎麼和已經存在的開發社區打交道。它由一羣形形色色的人組成，
-他們對代碼、風格和過程有著很高的標準。這些標準是在長期實踐中總結出來的，
+請記住你是在學習怎麼和已經存在的開發社群打交道。它由一羣形形色色的人組成，
+他們對程式碼、風格和過程有著很高的標準。這些標準是在長期實踐中總結出來的，
 適應於地理上分散的大型開發團隊。它們已經被很好得整理成檔，建議你在開發
-之前儘可能多的學習這些標準，而不要期望別人來適應你或者你公司的行爲方式。
+之前儘可能多的學習這些標準，而不要期望別人來適應你或者你公司的行為方式。
 
 
 法律問題
 --------
 
-Linux內核原始碼都是在GPL（通用公共許可證）的保護下發布的。要了解這種許可
-的細節請查看原始碼主目錄下的COPYING文件。Linux內核許可準則和如何使用
+Linux核心原始碼都是在GPL（通用公共許可證）的保護下發布的。要了解這種許可
+的細節請查看原始碼主目錄下的COPYING檔案。Linux核心許可準則和如何使用
 `SPDX <https://spdx.org/>` 標誌符說明在這個文件中
 :ref:`Documentation/translations/zh_TW/process/license-rules.rst <tw_kernel_licensing>`
-如果你對它還有更深入問題請聯繫律師，而不要在Linux內核郵件組上提問。因爲
+如果你對它還有更深入問題請聯繫律師，而不要在Linux核心郵件組上提問。因為
 郵件組裡的人並不是律師，不要期望他們的話有法律效力。
 
-對於GPL的常見問題和解答，請訪問以下連結：
+對於GPL的常見問題和解答，請造訪以下連結：
 	https://www.gnu.org/licenses/gpl-faq.html
 
 
-文檔
+文件
 ----
 
-Linux內核代碼中包含有大量的文檔。這些文檔對於學習如何與內核社區互動有著
-不可估量的價值。當一個新的功能被加入內核，最好把解釋如何使用這個功能的文
-檔也放進內核。當內核的改動導致面向用戶空間的接口發生變化時，最好將相關信
-息或手冊頁(manpages)的補丁發到mtk.manpages@gmail.com，以向手冊頁(manpages)
+Linux核心程式碼中包含有大量的文件。這些文件對於學習如何與核心社群互動有著
+不可估量的價值。當一個新的功能被加入核心，最好把解釋如何使用這個功能的文
+檔也放進核心。當核心的改動導致面向使用者空間的介面發生變化時，最好將相關信
+息或手冊頁(manpages)的補丁發到alx@kernel.org，以向手冊頁(manpages)
 的維護者解釋這些變化。
 
-以下是內核代碼中需要閱讀的文檔：
+以下是核心程式碼中需要閱讀的文件：
   :ref:`Documentation/admin-guide/README.rst <readme>`
-    文件簡要介紹了Linux內核的背景，並且描述了如何配置和編譯內核。內核的
-    新用戶應該從這裡開始。
+    文件簡要介紹了Linux核心的背景，並且描述了如何設定和編譯核心。核心的
+    新使用者應該從這裡開始。
 
 
   :ref:`Documentation/process/changes.rst <changes>`
-    文件給出了用來編譯和使用內核所需要的最小軟體包列表。
+    文件給出了用來編譯和使用核心所需要的最小軟體套件列表。
 
   :ref:`Documentation/translations/zh_TW/process/coding-style.rst <tw_codingstyle>`
-    描述Linux內核的代碼風格和理由。所有新代碼需要遵守這篇文檔中定義的規
+    描述Linux核心的程式碼風格和理由。所有新程式碼需要遵守這篇文件中定義的規
     范。大多數維護者只會接收符合規定的補丁，很多人也只會幫忙檢查符合風格
-    的代碼。
+    的程式碼。
 
   :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
 
-    這兩份文檔明確描述如何創建和發送補丁，其中包括（但不僅限於)：
+    這兩份文件明確描述如何建立和發送補丁，其中包括（但不僅限於)：
        - 郵件內容
        - 郵件格式
        - 選擇收件人
 
-    遵守這些規定並不能保證提交成功（因爲所有補丁需要通過嚴格的內容和風格
+    遵守這些規定並不能保證提交成功（因為所有補丁需要透過嚴格的內容和風格
     審查），但是忽視他們幾乎就意味著失敗。
 
-    其他關於如何正確地生成補丁的優秀文檔包括：
+    其他關於如何正確地產生補丁的優秀文件包括：
     "The Perfect Patch"
 
         https://www.ozlabs.org/~akpm/stuff/tpp.txt
@@ -118,78 +119,78 @@ Linux內核代碼中包含有大量的文檔。這些文檔對於學習如何與
         https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html
 
   :ref:`Documentation/translations/zh_TW/process/stable-api-nonsense.rst <tw_stable_api_nonsense>`
-    論證內核爲什麼特意不包括穩定的內核內部API，也就是說不包括像這樣的特
+    論證核心為什麼特意不包括穩定的核心內部API，也就是說不包括像這樣的特
     性：
 
-       - 子系統中間層（爲了兼容性？）
-       - 在不同作業系統間易於移植的驅動程序
-       - 減緩（甚至阻止）內核代碼的快速變化
+       - 子系統中間層（為了相容性？）
+       - 在不同作業系統間易於移植的驅動程式
+       - 減緩（甚至阻止）核心程式碼的快速變化
 
-    這篇文檔對於理解Linux的開發哲學至關重要。對於將開發平台從其他操作系
+    這篇文件對於理解Linux的開發哲學至關重要。對於將開發平台從其他操作系
     統轉移到Linux的人來說也很重要。
 
   :ref:`Documentation/process/security-bugs.rst <securitybugs>`
-    如果你認爲自己發現了Linux內核的安全性問題，請根據這篇文檔中的步驟來
-    提醒其他內核開發者並幫助解決這個問題。
+    如果你認為自己發現了Linux核心的安全性問題，請根據這篇文件中的步驟來
+    提醒其他核心開發者並幫助解決這個問題。
 
   :ref:`Documentation/translations/zh_TW/process/management-style.rst <tw_managementstyle>`
 
-    描述內核維護者的工作方法及其共有特點。這對於剛剛接觸內核開發（或者對
-    它感到好奇）的人來說很重要，因爲它解釋了很多對於內核維護者獨特行爲的
+    描述核心維護者的工作方法及其共有特點。這對於剛剛接觸核心開發（或者對
+    它感到好奇）的人來說很重要，因為它解釋了很多對於核心維護者獨特行為的
     普遍誤解與迷惑。
 
   :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
-    解釋了穩定版內核發布的規則，以及如何將改動放入這些版本的步驟。
+    解釋了穩定版核心發布的規則，以及如何將改動放入這些版本的步驟。
 
   :ref:`Documentation/process/kernel-docs.rst <kernel_docs>`
-    有助於內核開發的外部文檔列表。如果你在內核自帶的文檔中沒有找到你想找
-    的內容，可以查看這些文檔。
+    有助於核心開發的外部文件列表。如果你在核心自帶的文件中沒有找到你想找
+    的內容，可以查看這些文件。
 
   :ref:`Documentation/process/applying-patches.rst <applying_patches>`
-    關於補丁是什麼以及如何將它打在不同內核開發分支上的好介紹
+    關於補丁是什麼以及如何將它打在不同核心開發分支上的好介紹
 
-內核還擁有大量從代碼自動生成或者從 ReStructuredText(ReST) 標記生成的文檔，
-比如這個文檔，它包含內核內部API的全面介紹以及如何妥善處理加鎖的規則。所有
-這些文檔都可以通過運行以下命令從內核代碼中生成爲PDF或HTML文檔::
+核心還擁有大量從程式碼自動產生或者從 ReStructuredText(ReST) 標記產生的文件，
+比如這個文件，它包含核心內部API的全面介紹以及如何妥善處理加鎖的規則。所有
+這些文件都可以透過執行以下命令從核心程式碼中產生為PDF或HTML文件::
 
     make pdfdocs
     make htmldocs
 
-ReST格式的文檔會生成在 Documentation/output. 目錄中。
-它們也可以用下列命令生成 LaTeX 和 ePub 格式文檔::
+ReST格式的文件會產生在 Documentation/output. 目錄中。
+它們也可以用下列命令產生 LaTeX 和 ePub 格式文件::
 
     make latexdocs
     make epubdocs
 
-如何成爲內核開發者
+如何成為核心開發者
 ------------------
-如果你對Linux內核開發一無所知，你應該訪問「Linux內核新手」計劃：
+如果你對Linux核心開發一無所知，你應該造訪「Linux核心新手」計劃：
 
 	https://kernelnewbies.org
 
-它擁有一個可以問各種最基本的內核開發問題的郵件列表（在提問之前一定要記得
+它擁有一個可以問各種最基本的核心開發問題的郵件列表（在提問之前一定要記得
 查找已往的郵件，確認是否有人已經回答過相同的問題）。它還擁有一個可以獲得
-實時反饋的IRC聊天頻道，以及大量對於學習Linux內核開發相當有幫助的文檔。
+實時反饋的IRC聊天頻道，以及大量對於學習Linux核心開發相當有幫助的文件。
 
-網站簡要介紹了原始碼組織結構、子系統劃分以及目前正在進行的項目（包括內核
-中的和單獨維護的）。它還提供了一些基本的幫助信息，比如如何編譯內核和打補
-丁。
+網站簡要介紹了原始碼組織結構、子系統劃分以及目前正在進行的專案（包括核心
+中的和單獨維護的）。它還提供了一些基本的幫助資訊，比如如何編譯核心和打補丁
+。
 
-如果你想加入內核開發社區並協助完成一些任務，卻找不到從哪裡開始，可以訪問
-「Linux內核房管員」計劃：
+如果你想加入核心開發社群並協助完成一些任務，卻找不到從哪裡開始，可以造訪
+「Linux核心房管員」計劃：
 
 	https://kernelnewbies.org/KernelJanitors
 
-這是極佳的起點。它提供一個相對簡單的任務列表，列出內核代碼中需要被重新
-整理或者改正的地方。通過和負責這個計劃的開發者們一同工作，你會學到將補丁
-集成進內核的基本原理。如果還沒有決定下一步要做什麼的話，你還可能會得到方
+這是極佳的起點。它提供一個相對簡單的任務列表，列出核心程式碼中需要被重新
+整理或者改正的地方。透過和負責這個計劃的開發者們一同工作，你會學到將補丁
+整合進核心的基本原理。如果還沒有決定下一步要做什麼的話，你還可能會得到方
 向性的指點。
 
-在真正動手修改內核代碼之前，理解要修改的代碼如何運作是必需的。要達到這個
-目的，沒什麼辦法比直接讀代碼更有效了（大多數花招都會有相應的注釋），而且
-一些特製的工具還可以提供幫助。例如，「Linux代碼交叉引用」項目就是一個值得
+在真正動手修改核心程式碼之前，理解要修改的程式碼如何運作是必需的。要達到這個
+目的，沒什麼辦法比直接讀程式碼更有效了（大多數花招都會有相應的註解），而且
+一些特製的工具還可以提供幫助。例如，「Linux程式碼交叉引用」專案就是一個值得
 特別推薦的幫助工具，它將原始碼顯示在有編目和索引的網頁上。其中一個更新及
-時的內核源碼庫，可以通過以下地址訪問：
+時的核心源碼庫，可以透過以下地址造訪：
 
         https://elixir.bootlin.com/
 
@@ -197,158 +198,159 @@ ReST格式的文檔會生成在 Documentation/output. 目錄中。
 開發流程
 --------
 
-目前Linux內核開發流程包括幾個「主內核分支」和很多子系統相關的內核分支。這
+目前Linux核心開發流程包括幾個「主核心分支」和很多子系統相關的核心分支。這
 些分支包括：
 
-  - Linus 的內核源碼樹
-  - 多個主要版本的穩定版內核樹
-  - 子系統相關的內核樹
-  - linux-next 集成測試樹
+  - Linus 的核心源碼樹
+  - 多個主要版本的穩定版核心樹
+  - 子系統相關的核心樹
+  - linux-next 整合測試樹
 
 
 主線樹
 ------
-主線樹是由Linus Torvalds 維護的。你可以在https://kernel.org 網站或者代碼
+主線樹是由Linus Torvalds 維護的。你可以在https://kernel.org 網站或者程式碼
 庫中下找到它。它的開發遵循以下步驟：
 
-  - 每當一個新版本的內核被發布，爲期兩周的集成窗口將被打開。在這段時間裡
-    維護者可以向Linus提交大段的修改，通常這些修改已經被放到-mm內核中幾個
-    星期了。提交大量修改的首選方式是使用git工具（內核的代碼版本管理工具
-    ，更多的信息可以在 https://git-scm.com/ 獲取），不過使用普通補丁也是
+  - 每當一個新版本的核心被發布，為期兩周的整合視窗將被開啟。在這段時間裡
+    維護者可以向Linus提交大段的修改，通常這些修改已經被放到-mm核心中幾個
+    星期了。提交大量修改的首選方式是使用git工具（核心的程式碼版本管理工具
+    ，更多的資訊可以在 https://git-scm.com/ 獲取），不過使用普通補丁也是
     可以的。
-  - 兩個星期以後-rc1版本內核發布。之後只有不包含可能影響整個內核穩定性的
-    新功能的補丁才可能被接受。請注意一個全新的驅動程序（或者文件系統）有
-    可能在-rc1後被接受是因爲這樣的修改完全獨立，不會影響其他的代碼，所以
-    沒有造成內核退步的風險。在-rc1以後也可以用git向Linus提交補丁，不過所
+  - 兩個星期以後-rc1版本核心發布。之後只有不包含可能影響整個核心穩定性的
+    新功能的補丁才可能被接受。請注意一個全新的驅動程式（或者檔案系統）有
+    可能在-rc1後被接受是因為這樣的修改完全獨立，不會影響其他的程式碼，所以
+    沒有造成核心退步的風險。在-rc1以後也可以用git向Linus提交補丁，不過所
     有的補丁需要同時被發送到相應的公衆郵件列表以徵詢意見。
-  - 當Linus認爲當前的git源碼樹已經達到一個合理健全的狀態足以發布供人測試
+  - 當Linus認為當前的git源碼樹已經達到一個合理健全的狀態足以發布供人測試
     時，一個新的-rc版本就會被發布。計劃是每周都發布新的-rc版本。
-  - 這個過程一直持續下去直到內核被認爲達到足夠穩定的狀態，持續時間大概是
+  - 這個過程一直持續下去直到核心被認為達到足夠穩定的狀態，持續時間大概是
     6個星期。
 
-關於內核發布，值得一提的是Andrew Morton在linux-kernel郵件列表中如是說：
-	「沒有人知道新內核何時會被發布，因爲發布是根據已知bug的情況來決定
+關於核心發布，值得一提的是Andrew Morton在linux-kernel郵件列表中如是說：
+	「沒有人知道新核心何時會被發布，因為發布是根據已知bug的情況來決定
 	的，而不是根據一個事先制定好的時間表。」
 
 子系統特定樹
 ------------
 
-各種內核子系統的維護者——以及許多內核子系統開發人員——在原始碼庫中公開了他們
-當前的開發狀態。這樣，其他人就可以看到內核的不同區域發生了什麼。在開發速度
-很快的領域，可能會要求開發人員將提交的內容建立在這樣的子系統內核樹上，這樣
+各種核心子系統的維護者——以及許多核心子系統開發人員——在原始碼庫中公開了他們
+當前的開發狀態。這樣，其他人就可以看到核心的不同區域發生了什麼。在開發速度
+很快的領域，可能會要求開發人員將提交的內容建立在這樣的子系統核心樹上，這樣
 就避免了提交與其他已經進行的工作之間的衝突。
 
-這些存儲庫中的大多數都是Git樹，但是也有其他的scm在使用，或者補丁隊列被發布
-爲Quilt系列。這些子系統存儲庫的地址列在MAINTAINERS文件中。其中許多可以在
+這些儲存庫中的大多數都是Git樹，但是也有其他的scm在使用，或者補丁佇列被發布
+為Quilt系列。這些子系統儲存庫的地址列在MAINTAINERS檔案中。其中許多可以在
 https://git.kernel.org/上瀏覽。
 
 在將一個建議的補丁提交到這樣的子系統樹之前，需要對它進行審查，審查主要發生
-在郵件列表上（請參見下面相應的部分）。對於幾個內核子系統，這個審查過程是通
-過工具補丁跟蹤的。Patchwork提供了一個Web界面，顯示補丁發布、對補丁的任何評
-論或修訂，維護人員可以將補丁標記爲正在審查、接受或拒絕。大多數補丁網站都列
+在郵件列表上（請參見下面相應的部分）。對於幾個核心子系統，這個審查過程是通
+過工具補丁追蹤的。Patchwork提供了一個Web介面，顯示補丁發布、對補丁的任何評
+論或修訂，維護人員可以將補丁標記為正在審查、接受或拒絕。大多數補丁網站都列
 在 https://patchwork.kernel.org/
 
-Linux-next 集成測試樹
+Linux-next 整合測試樹
 ---------------------
 
-在將子系統樹的更新合併到主線樹之前，需要對它們進行集成測試。爲此，存在一個
-特殊的測試存儲庫，其中幾乎每天都會提取所有子系統樹：
+在將子系統樹的更新合併到主線樹之前，需要對它們進行整合測試。為此，存在一個
+特殊的測試儲存庫，其中幾乎每天都會提取所有子系統樹：
 
-        https://git.kernel.org/？p=linux/kernel/git/next/linux-next.git
+        https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
 
-通過這種方式，Linux-next 對下一個合併階段將進入主線內核的內容給出了一個概要
-展望。非常歡冒險的測試者運行測試Linux-next。
+透過這種方式，Linux-next 對下一個合併階段將進入主線核心的內容給出了一個概要
+展望。非常歡迎冒險的測試者對linux-next進行執行時測試。
 
-多個主要版本的穩定版內核樹
+多個主要版本的穩定版核心樹
 -----------------------------------
-由3個數字組成的內核版本號說明此內核是-stable版本。它們包含內核的相對較小且
-至關重要的修補，這些修補針對安全性問題或者嚴重的內核退步。
+由3個數字組成的核心版本號說明此核心是-stable版本。它們包含核心的相對較小且
+至關重要的修補，這些修補針對安全性問題或者嚴重的核心退步。
 
-這種版本的內核適用於那些期望獲得最新的穩定版內核並且不想參與測試開發版或
-者實驗版的用戶。
+這種版本的核心適用於那些期望獲得最新的穩定版核心並且不想參與測試開發版或
+者實驗版的使用者。
 
-穩定版內核樹版本由「穩定版」小組（郵件地址<stable@vger.kernel.org>）維護，一般
+穩定版核心樹版本由「穩定版」小組（郵件地址<stable@vger.kernel.org>）維護，一般
 隔周發布新版本。
 
-內核源碼中的 :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
-文件具體描述了可被穩定版內核接受的修改類型以及發布的流程。
+核心源碼中的
+:ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
+文件具體描述了可被穩定版核心接受的修改類型以及發布的流程。
 
 
 報告bug
 -------
 
-bugzilla.kernel.org是Linux內核開發者們用來跟蹤內核Bug的網站。我們鼓勵用
-戶在這個工具中報告找到的所有bug。如何使用內核bugzilla的細節請訪問：
+bugzilla.kernel.org是Linux核心開發者們用來追蹤核心Bug的網站。我們鼓勵用
+戶在這個工具中報告找到的所有bug。如何使用核心bugzilla的細節請造訪：
 
 	http://test.kernel.org/bugzilla/faq.html
 
-內核源碼主目錄中的:ref:`admin-guide/reporting-bugs.rst <reportingbugs>`
-文件里有一個很好的模板。它指導用戶如何報告可能的內核bug以及需要提供哪些信息
-來幫助內核開發者們找到問題的根源。
+核心源碼主目錄中的:ref:`admin-guide/reporting-bugs.rst <reportingbugs>`
+文件裡有一個很好的模板。它指導使用者如何報告可能的核心bug以及需要提供哪些資訊
+來幫助核心開發者們找到問題的根源。
 
 
 利用bug報告
 -----------
 
-練習內核開發技能的最好辦法就是修改其他人報告的bug。你不光可以幫助內核變
+練習核心開發技能的最好辦法就是修改其他人報告的bug。你不光可以幫助核心變
 得更加穩定，還可以學會如何解決實際問題從而提高自己的技能，並且讓其他開發
-者感受到你的存在。修改bug是贏得其他開發者讚譽的最好辦法，因爲並不是很多
+者感受到你的存在。修改bug是贏得其他開發者讚譽的最好辦法，因為並不是很多
 人都喜歡浪費時間去修改別人報告的bug。
 
-要嘗試修改已知的bug，請訪問 http://bugzilla.kernel.org 網址。
+要嘗試修改已知的bug，請造訪 http://bugzilla.kernel.org 網址。
 
 
 郵件列表
 --------
 
-正如上面的文檔所描述，大多數的骨幹內核開發者都加入了Linux Kernel郵件列
+正如上面的文件所描述，大多數的骨幹核心開發者都加入了Linux Kernel郵件列
 表。如何訂閱和退訂列表的細節可以在這裡找到：
 
-	http://vger.kernel.org/vger-lists.html#linux-kernel
+	https://subspace.kernel.org/subscribing.html
 
 網上很多地方都有這個郵件列表的存檔(archive)。可以使用搜尋引擎來找到這些
 存檔。比如：
 
-	https://lore.kernel.org/lkml/
+	https://lore.kernel.org/linux-kernel/
 
 在發信之前，我們強烈建議你先在存檔中搜索你想要討論的問題。很多已經被詳細
 討論過的問題只在郵件列表的存檔中可以找到。
 
-大多數內核子系統也有自己獨立的郵件列表來協調各自的開發工作。從
-MAINTAINERS文件中可以找到不同話題對應的郵件列表。
+大多數核心子系統也有自己獨立的郵件列表來協調各自的開發工作。從
+MAINTAINERS檔案中可以找到不同話題對應的郵件列表。
 
-很多郵件列表架設在kernel.org伺服器上。這些列表的信息可以在這裡找到：
+很多郵件列表架設在kernel.org伺服器上。這些列表的資訊可以在這裡找到：
 
-	http://vger.kernel.org/vger-lists.html
+	https://subspace.kernel.org
 
-在使用這些郵件列表時，請記住保持良好的行爲習慣。下面的連結提供了與這些列
+在使用這些郵件列表時，請記住保持良好的行為習慣。下面的連結提供了與這些列
 表（或任何其它郵件列表）交流的一些簡單規則，雖然內容有點濫竽充數。
 
-	http://www.albion.com/netiquette/
+	https://subspace.kernel.org/etiquette.html
 
 當有很多人回覆你的郵件時，郵件的抄送列表會變得很長。請不要將任何人從抄送
 列表中刪除，除非你有足夠的理由這麼做。也不要只回復到郵件列表。請習慣於同
-一封郵件接收兩次（一封來自發送者一封來自郵件列表），而不要試圖通過添加一
+一封郵件接收兩次（一封來自發送者一封來自郵件列表），而不要試圖透過添加一
 些奇特的郵件頭來解決這個問題，人們不會喜歡的。
 
 記住保留你所回復內容的上下文和源頭。在你回覆郵件的頂部保留「某某某說到……」
 這幾行。將你的評論加在被引用的段落之間而不要放在郵件的頂部。
 
-如果你在郵件中附帶補丁，請確認它們是可以直接閱讀的純文本（如
+如果你在郵件中附帶補丁，請確認它們是可以直接閱讀的純文字（如
 :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
-文檔中所述）。內核開發者們不希望遇到附件或者被壓縮了的補丁。只有這樣才能
-保證他們可以直接評論你的每行代碼。請確保你使用的郵件發送程序不會修改空格
+文件中所述）。核心開發者們不希望遇到附件或者被壓縮了的補丁。只有這樣才能
+保證他們可以直接評論你的每行程式碼。請確保你使用的郵件發送程式不會修改空格
 和制表符。一個防範性的測試方法是先將郵件發送給自己，然後自己嘗試是否可以
-順利地打上收到的補丁。如果測試不成功，請調整或者更換你的郵件發送程序直到
-它正確工作爲止。
+順利地打上收到的補丁。如果測試不成功，請調整或者更換你的郵件發送程式直到
+它正確工作為止。
 
 總而言之，請尊重其他的郵件列表訂閱者。
 
 
-同內核社區合作
+同核心社群合作
 ----------------
 
-內核社區的目標就是提供盡善盡美的內核。所以當你提交補丁期望被接受進內核的
+核心社群的目標就是提供盡善盡美的核心。所以當你提交補丁期望被接受進核心的
 時候，它的技術價值以及其他方面都將被評審。那麼你可能會得到什麼呢？
 
   - 批評
@@ -357,9 +359,9 @@ MAINTAINERS文件中可以找到不同話題對應的郵件列表。
   - 要求證明修改的必要性
   - 沉默
 
-要記住，這些是把補丁放進內核的正常情況。你必須學會聽取對補丁的批評和評論，
+要記住，這些是把補丁放進核心的正常情況。你必須學會聽取對補丁的批評和評論，
 從技術層面評估它們，然後要麼重寫你的補丁要麼簡明扼要地論證修改是不必要
-的。如果你發的郵件沒有得到任何回應，請過幾天後再試一次，因爲有時信件會湮
+的。如果你發的郵件沒有得到任何回應，請過幾天後再試一次，因為有時信件會湮
 沒在茫茫信海中。
 
 你不應該做的事情：
@@ -369,8 +371,8 @@ MAINTAINERS文件中可以找到不同話題對應的郵件列表。
   - 忽略別人的評論
   - 沒有按照別人的要求做任何修改就重新提交
 
-在一個努力追尋最好技術方案的社區里，對於一個補丁有多少好處總會有不同的見
-解。你必須要抱著合作的態度，願意改變自己的觀點來適應內核的風格。或者至少
+在一個努力追尋最好技術方案的社群裡，對於一個補丁有多少好處總會有不同的見
+解。你必須要抱著合作的態度，願意改變自己的觀點來適應核心的風格。或者至少
 願意去證明你的想法是有價值的。記住，犯錯誤是允許的，只要你願意朝著正確的
 方案去努力。
 
@@ -378,36 +380,36 @@ MAINTAINERS文件中可以找到不同話題對應的郵件列表。
 不會被接受，也不意味著有人和你作對。你只需要改正所有提出的問題然後重新發
 送你的補丁。
 
-內核社區和公司文化的差異
+核心社群和公司文化的差異
 ------------------------
 
-內核社區的工作模式同大多數傳統公司開發隊伍的工作模式並不相同。下面這些例
+核心社群的工作模式同大多數傳統公司開發隊伍的工作模式並不相同。下面這些例
 子，可以幫助你避免某些可能發生問題：
 用這些話介紹你的修改提案會有好處：
 
     - 它同時解決了多個問題
-    - 它刪除了2000行代碼
+    - 它刪除了2000行程式碼
     - 這是補丁，它已經解釋了我想要說明的
     - 我在5種不同的體系結構上測試過它……
     - 這是一系列小補丁用來……
-    - 這個修改提高了普通機器的性能……
+    - 這個修改提高了普通機器的效能……
 
 應該避免如下的說法：
 
     - 我們在AIX/ptx/Solaris就是這麼做的，所以這麼做肯定是好的……
     - 我做這行已經20年了，所以……
-    - 爲了我們公司賺錢考慮必須這麼做
+    - 為了我們公司賺錢考慮必須這麼做
     - 這是我們的企業產品線所需要的
-    - 這裡是描述我觀點的1000頁設計文檔
+    - 這裡是描述我觀點的1000頁設計文件
     - 這是一個5000行的補丁用來……
-    - 我重寫了現在亂七八糟的代碼，這就是……
+    - 我重寫了現在亂七八糟的程式碼，這就是……
     - 我被規定了最後期限，所以這個補丁需要立刻被接受
 
-另外一個內核社區與大部分傳統公司的軟體開發隊伍不同的地方是無法面對面地交
-流。使用電子郵件和IRC聊天工具做爲主要溝通工具的一個好處是性別和種族歧視
-將會更少。Linux內核的工作環境更能接受婦女和少數族羣，因爲每個人在別人眼
-里只是一個郵件地址。國際化也幫助了公平的實現，因爲你無法通過姓名來判斷人
-的性別。男人有可能叫李麗，女人也有可能叫王剛。大多數在Linux內核上工作過
+另外一個核心社群與大部分傳統公司的軟體開發隊伍不同的地方是無法面對面地交
+流。使用電子郵件和IRC聊天工具做為主要溝通工具的一個好處是性別和種族歧視
+將會更少。Linux核心的工作環境更能接受婦女和少數族羣，因為每個人在別人眼
+里只是一個郵件地址。國際化也幫助了公平的實作，因為你無法透過姓名來判斷人
+的性別。男人有可能叫李麗，女人也有可能叫王剛。大多數在Linux核心上工作過
 並表達過看法的女性對在linux上工作的經歷都給出了正面的評價。
 
 對於一些不習慣使用英語的人來說，語言可能是一個引起問題的障礙。在郵件列表
@@ -418,61 +420,61 @@ MAINTAINERS文件中可以找到不同話題對應的郵件列表。
 拆分修改
 --------
 
-Linux內核社區並不喜歡一下接收大段的代碼。修改需要被恰當地介紹、討論並且
+Linux核心社群並不喜歡一下接收大段的程式碼。修改需要被恰當地介紹、討論並且
 拆分成獨立的小段。這幾乎完全和公司中的習慣背道而馳。你的想法應該在開發最
 開始的階段就讓大家知道，這樣你就可以及時獲得對你正在進行的開發的反饋。這
-樣也會讓社區覺得你是在和他們協作，而不是僅僅把他們當作傾銷新功能的對象。
+樣也會讓社群覺得你是在和他們協作，而不是僅僅把他們當作傾銷新功能的物件。
 無論如何，你不要一次性地向郵件列表發送50封信，你的補丁序列應該永遠用不到
 這麼多。
 
 將補丁拆開的原因如下：
 
-1) 小的補丁更有可能被接受，因爲它們不需要太多的時間和精力去驗證其正確性。
+1) 小的補丁更有可能被接受，因為它們不需要太多的時間和精力去驗證其正確性。
    一個5行的補丁，可能在維護者看了一眼以後就會被接受。而500行的補丁則
    需要數個小時來審查其正確性（所需時間隨補丁大小增加大約呈指數級增長）。
 
-   當出了問題的時候，小的補丁也會讓調試變得非常容易。一個一個補丁地回溯
+   當出了問題的時候，小的補丁也會讓除錯變得非常容易。一個一個補丁地回溯
    將會比仔細剖析一個被打上的大補丁（這個補丁破壞了其他東西）容易得多。
 
 2）不光發送小的補丁很重要，在提交之前重新編排、化簡（或者僅僅重新排列）
    補丁也是很重要的。
 
-這裡有內核開發者Al Viro打的一個比方：
-	「想像一個老師正在給學生批改數學作業。老師並不希望看到學生爲了得
+這裡有核心開發者Al Viro打的一個比方：
+	「想像一個老師正在給學生批改數學作業。老師並不希望看到學生為了得
 	到正確解法所進行的嘗試和產生的錯誤。他希望看到的是最乾淨最優雅的
 	解答。好學生了解這點，絕不會把最終解決之前的中間方案提交上去。」
 
-	內核開發也是這樣。維護者和評審者不希望看到一個人在解決問題時的思
+	核心開發也是這樣。維護者和評審者不希望看到一個人在解決問題時的思
 	考過程。他們只希望看到簡單和優雅的解決方案。
 
-直接給出一流的解決方案，和社區一起協作討論尚未完成的工作，這兩者之間似乎
+直接給出一流的解決方案，和社群一起協作討論尚未完成的工作，這兩者之間似乎
 很難找到一個平衡點。所以最好儘早開始收集有利於你進行改進的反饋；同時也要
-保證修改分成很多小塊，這樣在整個項目都準備好被包含進內核之前，其中的一部
+保證修改分成很多小塊，這樣在整個專案都準備好被包含進核心之前，其中的一部
 分可能會先被接收。
 
-必須了解這樣做是不可接受的：試圖將未完成的工作提交進內核，然後再找時間修
+必須了解這樣做是不可接受的：試圖將未完成的工作提交進核心，然後再找時間修
 復。
 
 
 證明修改的必要性
 ----------------
-除了將補丁拆成小塊，很重要的一點是讓Linux社區了解他們爲什麼需要這樣修改。
+除了將補丁拆成小塊，很重要的一點是讓Linux社群了解他們為什麼需要這樣修改。
 你必須證明新功能是有人需要的並且是有用的。
 
 
 記錄修改
 --------
 
-當你發送補丁的時候，需要特別留意郵件正文的內容。因爲這裡的信息將會做爲補
-丁的修改記錄(ChangeLog)，會被一直保留以備大家查閱。它需要完全地描述補丁，
+當你發送補丁的時候，需要特別留意郵件正文的內容。因為這裡的資訊將會做為補丁
+的修改記錄(ChangeLog)，會被一直保留以備大家查閱。它需要完全地描述補丁，
 包括：
 
-  - 爲什麼需要這個修改
+  - 為什麼需要這個修改
   - 補丁的總體設計
-  - 實現細節
+  - 實作細節
   - 測試結果
 
-想了解它具體應該看起來像什麼，請查閱以下文檔中的「ChangeLog」章節：
+想了解它具體應該看起來像什麼，請查閱以下文件中的「ChangeLog」章節：
   「The Perfect Patch」
   	 https://www.ozlabs.org/~akpm/stuff/tpp.txt
 
@@ -490,7 +492,7 @@ Dunlap和Gerrit Huizenga完善了應該說和不該說的列表。感謝Pat Moch
 Linder, Randy Dunlap, Kay Sievers, Vojtech Pavlik, Jan Kara, Josh Boyer,
 Kees Cook, Andrew Morton, Andi Kleen, Vadim Lobanov, Jesper Juhl, Adrian
 Bunk, Keri Harris, Frans Pop, David A. Wheeler, Junio Hamano, Michael
-Kerrisk和Alex Shepard的評審、建議和貢獻。沒有他們的幫助，這篇文檔是不可
+Kerrisk和Alex Shepard的評審、建議和貢獻。沒有他們的幫助，這篇文件是不可
 能完成的。
 
 
diff --git a/Documentation/translations/zh_TW/process/index.rst b/Documentation/translations/zh_TW/process/index.rst
index 65922d9faa20..3f84437a2ca9 100644
--- a/Documentation/translations/zh_TW/process/index.rst
+++ b/Documentation/translations/zh_TW/process/index.rst
@@ -10,53 +10,121 @@
 :Original: :ref:`Documentation/process/index.rst <process_index>`
 :Translator: Alex Shi <alex.shi@linux.alibaba.com>
              Hu Haowen <2023002089@link.tyut.edu.cn>
+             Chen-Yu Yeh <chenyou910331@gmail.com>
 
 .. _tw_process_index:
 
 ========================
-與Linux 內核社區一起工作
+與Linux核心社群一起工作
 ========================
 
-你想成爲Linux內核開發人員嗎？歡迎之至！在學習許多關於內核的技術知識的同時，
-瞭解我們社區的工作方式也很重要。閱讀這些文檔可以讓您以更輕鬆的、麻煩更少的
-方式將更改合併到內核。
+你想成為Linux核心開發人員嗎？歡迎之至！在學習許多關於核心的技術知識的同時，
+瞭解我們社群的工作方式也很重要。閱讀這些文件可以讓您以更輕鬆的、麻煩更少的
+方式將更改合併到核心。
 
-以下是每位開發人員都應閱讀的基本指南：
+核心開發如何運作的介紹
+----------------------
+
+請先閱讀這些文件：理解這裡的內容將使你更順利地進入核心社群。
 
 .. toctree::
    :maxdepth: 1
 
    howto
-   code-of-conduct
-   code-of-conduct-interpretation
+   development-process
    submitting-patches
+   submit-checklist
+
+核心開發者的工具與技術指南
+--------------------------
+
+這是核心開發者應該熟悉的材料集合。
+
+.. toctree::
+   :maxdepth: 1
+
    programming-language
    coding-style
-   development-process
    email-clients
-   license-rules
-   kernel-enforcement-statement
-   kernel-driver-statement
+   volatile-considered-harmful
+
+TODOList:
 
-其它大多數開發人員感興趣的社區指南：
+* changes
+* maintainer-pgp-guide
+* applying-patches
+* backporting
+* adding-syscalls
+* botching-up-ioctls
 
+政策指南與開發者聲明
+--------------------
+
+這些是我們在核心社群（以及更廣範圍）中努力遵循的規則。
 
 .. toctree::
    :maxdepth: 1
 
-   submit-checklist
+   license-rules
+   code-of-conduct
+   code-of-conduct-interpretation
+   kernel-enforcement-statement
+   kernel-driver-statement
    stable-api-nonsense
    stable-kernel-rules
    management-style
+
+TODOList:
+
+* contribution-maturity-model
+* researcher-guidelines
+* generated-content
+* coding-assistants
+* conclave
+
+處理缺陷
+--------
+
+缺陷是無法避免的；正確地處理它們非常重要。下面的文件提供了關於除錯的一般
+建議，並描述了我們處理幾類特殊缺陷——迴歸和安全問題——的政策。
+
+.. toctree::
+   :maxdepth: 1
+
    embargoed-hardware-issues
 
-這些是一些總體性技術指南，由於不大好分類而放在這裏：
+TODOList:
+
+* debugging/index
+* handling-regressions
+* security-bugs
+* threat-model
+* cve
+
+維護者資訊
+----------
+
+如何找到會接受你補丁的人。
+
+TODOList:
+
+* maintainer-handbooks
+* maintainers
+
+其他材料
+--------
+
+這裡是一些大多數開發者會感興趣的其他社群指南：
 
 .. toctree::
    :maxdepth: 1
 
    magic-number
-   volatile-considered-harmful
+
+TODOList:
+
+* kernel-docs
+* deprecated
 
 .. only::  subproject and html
 
@@ -64,4 +132,3 @@
    ====
 
    * :ref:`genindex`
-
diff --git a/Documentation/translations/zh_TW/process/license-rules.rst b/Documentation/translations/zh_TW/process/license-rules.rst
index 594255856b68..d9054cff505c 100644
--- a/Documentation/translations/zh_TW/process/license-rules.rst
+++ b/Documentation/translations/zh_TW/process/license-rules.rst
@@ -5,21 +5,22 @@
 :Original: :ref:`Documentation/process/license-rules.rst <kernel_licensing>`
 :Translator: Alex Shi <alex.shi@linux.alibaba.com>
              Hu Haowen <2023002089@link.tyut.edu.cn>
+             Chen-Yu Yeh <chenyou910331@gmail.com>
 
 .. _tw_kernel_licensing:
 
-Linux內核許可規則
+Linux核心許可規則
 =================
 
-Linux內核根據LICENSES/preferred/GPL-2.0中提供的GNU通用公共許可證版本2
+Linux核心根據LICENSES/preferred/GPL-2.0中提供的GNU通用公共許可證版本2
 （GPL-2.0）的條款提供，並在LICENSES/exceptions/Linux-syscall-note中顯式
-描述了例外的系統調用，如COPYING文件中所述。
+描述了例外的系統呼叫，如COPYING檔案中所述。
 
-此文檔文件提供瞭如何對每個源文件進行註釋以使其許可證清晰明確的說明。
-它不會取代內核的許可證。
+本文件提供了如何對每個原始檔進行註解以使其許可證清晰明確的說明。
+它不會取代核心的許可證。
 
-內核源代碼作爲一個整體適用於COPYING文件中描述的許可證，但是單個源文件可以
-具有不同的與GPL-20兼容的許可證::
+核心原始程式碼作為一個整體適用於COPYING檔案中描述的許可證，但是單個原始檔可以
+具有不同的與GPL-2.0相容的許可證::
 
     GPL-1.0+ : GNU通用公共許可證v1.0或更高版本
     GPL-2.0+ : GNU通用公共許可證v2.0或更高版本
@@ -28,43 +29,47 @@ Linux內核根據LICENSES/preferred/GPL-2.0中提供的GNU通用公共許可證�
     LGPL-2.1 : 僅限GNU寬通用公共許可證v2.1
     LGPL-2.1+: GNU寬通用公共許可證v2.1或更高版本
 
-除此之外，個人文件可以在雙重許可下提供，例如一個兼容的GPL變體，或者BSD，
+除此之外，個人檔案可以在雙重許可下提供，例如一個相容的GPL變體，或者BSD，
 MIT等許可。
 
-用戶空間API（UAPI）頭文件描述了用戶空間程序與內核的接口，這是一種特殊情況。
-根據內核COPYING文件中的註釋，syscall接口是一個明確的邊界，它不會將GPL要求
-擴展到任何使用它與內核通信的軟件。由於UAPI頭文件必須包含在創建在Linux內核
-上運行的可執行文件的任何源文件中，因此此例外必須記錄在特別的許可證表述中。
+使用者空間API（UAPI）標頭檔描述了使用者空間程式與核心的介面，這是一種特殊
+情況。根據核心COPYING檔案中的註解，syscall介面是一個明確的邊界，它不會將
+GPL要求擴展到任何使用它與核心通信的軟體。由於UAPI標頭檔必須包含在建立在
+Linux核心上執行的可執行檔案的任何原始檔中，因此此例外必須記錄在特別的許可
+證表述中。
 
-表達源文件許可證的常用方法是將匹配的樣板文本添加到文件的頂部註釋中。由於
-格式，拼寫錯誤等，這些“樣板”很難通過那些在上下文中使用的驗證許可證合規性
+表達原始檔許可證的常用方法是將匹配的樣板文本添加到檔案的頂部註解中。由於
+格式，拼寫錯誤等，這些“樣板”很難透過那些在上下文中使用的驗證許可證合規性
 的工具。
 
-樣板文本的替代方法是在每個源文件中使用軟件包數據交換（SPDX）許可證標識符。
-SPDX許可證標識符是機器可解析的，並且是用於提供文件內容的許可證的精確縮寫。
-SPDX許可證標識符由Linux 基金會的SPDX 工作組管理，並得到了整個行業，工具
-供應商和法律團隊的合作伙伴的一致同意。有關詳細信息，請參閱
+樣板文本的替代方法是在每個原始檔中使用軟體套件資料交換（SPDX）許可證識別碼。
+SPDX許可證識別碼是機器可解析的，並且是用於提供檔案內容的許可證的精確縮寫。
+SPDX許可證識別碼由Linux 基金會的SPDX 工作組管理，並得到了整個行業，工具
+供應商和法律團隊的合作夥伴的一致同意。有關詳細資訊，請參閱
 https://spdx.org/
 
-Linux內核需要所有源文件中的精確SPDX標識符。內核中使用的有效標識符在
-`許可標識符`_ 一節中進行了解釋，並且已可以在
+Linux核心需要所有原始檔中的精確SPDX識別碼。核心中使用的有效識別碼在
+`許可識別碼`_ 一節中進行了解釋，並且已可以在
 https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶許可證
 文本。
 
-許可標識符語法
+許可識別碼語法
 --------------
 
 1.安置:
 
-   內核文件中的SPDX許可證標識符應添加到可包含註釋的文件中的第一行。對於大多
-   數文件，這是第一行，除了那些在第一行中需要'#!PATH_TO_INTERPRETER'的腳本。
-   對於這些腳本，SPDX標識符進入第二行。
+   核心檔案中的SPDX許可證識別碼應添加到可包含註解的檔案中的第一行。對於大多
+   數檔案，這是第一行，除了那些在第一行中需要'#!PATH_TO_INTERPRETER'的腳本。
+   對於這些腳本，SPDX許可證識別碼進入第二行。
+
+   如有需要，許可證識別碼行之後可以接上一行或多行SPDX-FileCopyrightText
+   行。
 
 |
 
 2. 風格:
 
-   SPDX許可證標識符以註釋的形式添加。註釋樣式取決於文件類型::
+   SPDX許可證識別碼以註解的形式添加。註解樣式取決於檔案類型::
 
       C source:	// SPDX-License-Identifier: <SPDX License Expression>
       C header:	/* SPDX-License-Identifier: <SPDX License Expression> */
@@ -73,44 +78,44 @@ https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶�
       .rst:	.. SPDX-License-Identifier: <SPDX License Expression>
       .dts{i}:	// SPDX-License-Identifier: <SPDX License Expression>
 
-   如果特定工具無法處理標準註釋樣式，則應使用工具接受的相應註釋機制。這是在
-   C 頭文件中使用“/\*\*/”樣式註釋的原因。過去在使用生成的.lds文件中觀察到
-   構建被破壞，其中'ld'無法解析C++註釋。現在已經解決了這個問題，但仍然有較
-   舊的彙編程序工具無法處理C++樣式的註釋。
+   如果特定工具無法處理標準註解樣式，則應使用工具接受的相應註解機制。這是在
+   C 標頭檔中使用“/\*\*/”樣式註解的原因。過去在使用產生的.lds檔案中觀察到
+   建置被破壞，其中'ld'無法解析C++註解。現在已經解決了這個問題，但仍然有較
+   舊的組譯器工具無法處理C++樣式的註解。
 
 |
 
 3. 句法:
 
-   <SPDX許可證表達式>是SPDX許可證列表中的SPDX短格式許可證標識符，或者在許可
-   證例外適用時由“WITH”分隔的兩個SPDX短格式許可證標識符的組合。當應用多個許
+   <SPDX許可證表達式>是SPDX許可證列表中的SPDX短格式許可證識別碼，或者在許可
+   證例外適用時由“WITH”分隔的兩個SPDX短格式許可證識別碼的組合。當應用多個許
    可證時，表達式由分隔子表達式的關鍵字“AND”，“OR”組成，並由“（”，“）”包圍。
 
-   帶有“或更高”選項的[L]GPL等許可證的許可證標識符通過使用“+”來表示“或更高”
-   選項來構建。::
+   帶有“或更高”選項的[L]GPL等許可證的許可證識別碼透過使用“+”來表示“或更高”
+   選項來建置。::
 
       // SPDX-License-Identifier: GPL-2.0+
       // SPDX-License-Identifier: LGPL-2.1+
 
-   當需要修正的許可證時，應使用WITH。 例如，linux內核UAPI文件使用表達式::
+   當需要修正的許可證時，應使用WITH。 例如，linux核心UAPI檔案使用表達式::
 
       // SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
       // SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note
 
-   其它在內核中使用WITH例外的事例如下::
+   其它在核心中使用WITH例外的事例如下::
 
       // SPDX-License-Identifier: GPL-2.0 WITH mif-exception
       // SPDX-License-Identifier: GPL-2.0+ WITH GCC-exception-2.0
 
-   例外只能與特定的許可證標識符一起使用。有效的許可證標識符列在異常文本文件
-   的標記中。有關詳細信息，請參閱 `許可標識符`_ 一章中的 `例外`_ 。
+   例外只能與特定的許可證識別碼一起使用。有效的許可證識別碼列在異常文本檔案
+   的標記中。有關詳細資訊，請參閱 `許可識別碼`_ 一章中的 `例外`_ 。
 
-   如果文件是雙重許可且只選擇一個許可證，則應使用OR。例如，一些dtsi文件在雙
+   如果檔案是雙重許可且只選擇一個許可證，則應使用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
@@ -119,8 +124,8 @@ https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶�
       // 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。例如，
-   如果代碼是從另一個項目繼承的，並且已經授予了將其放入內核的權限，但原始
+   如果檔案具有多個許可證，其條款全部適用於使用該檔案，則應使用AND。例如，
+   如果程式碼是從另一個專案繼承的，並且已經授予了將其放入核心的權限，但原始
    許可條款需要保持有效::
 
       // SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) AND MIT
@@ -129,20 +134,20 @@ https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶�
 
       // SPDX-License-Identifier: GPL-1.0+ AND LGPL-2.1+
 
-許可標識符
+許可識別碼
 ----------
 
-當前使用的許可證以及添加到內核的代碼許可證可以分解爲：
+當前使用的許可證以及添加到核心的程式碼許可證可以分解為：
 
 1. _`優先許可`:
 
-   應儘可能使用這些許可證，因爲它們已知完全兼容並廣泛使用。這些許可證在內核
+   應儘可能使用這些許可證，因為它們已知完全相容並廣泛使用。這些許可證在核心
    目錄::
 
       LICENSES/preferred/
 
-   此目錄中的文件包含完整的許可證文本和 `元標記`_ 。文件名與SPDX許可證標識
-   符相同，後者應用於源文件中的許可證。
+   此目錄中的檔案包含完整的許可證文本和 `元標記`_ 。檔名與SPDX許可證識別碼
+   相同，後者應用於原始檔中的許可證。
 
    例如::
 
@@ -156,28 +161,28 @@ https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶�
 
    _`元標記`:
 
-   許可證文件中必須包含以下元標記：
+   許可證檔案中必須包含以下元標記：
 
    - Valid-License-Identifier:
 
-     一行或多行, 聲明那些許可標識符在項目內有效, 以引用此特定許可的文本。通
-     常這是一個有效的標識符，但是例如對於帶有'或更高'選項的許可證，兩個標識
+     一行或多行, 聲明那些許可識別碼在專案內有效, 以引用此特定許可的文本。通
+     常這是一個有效的識別碼，但是例如對於帶有'或更高'選項的許可證，兩個識別碼
      符都有效。
 
    - SPDX-URL:
 
-     SPDX頁面的URL，其中包含與許可證相關的其他信息.
+     SPDX頁面的URL，其中包含與許可證相關的其他資訊.
 
    - Usage-Guidance:
 
-     使用建議的自由格式文本。該文本必須包含SPDX許可證標識符的正確示例，因爲
-     它們應根據 `許可標識符語法`_ 指南放入源文件中。
+     使用建議的自由格式文本。該文本必須包含SPDX許可證識別碼的正確範例，因為
+     它們應根據 `許可識別碼語法`_ 指南放入原始檔中。
 
    - License-Text:
 
-     此標記之後的所有文本都被視爲原始許可文本
+     此標記之後的所有文本都被視為原始許可文本
 
-   文件格式示例::
+   檔案格式範例::
 
       Valid-License-Identifier: GPL-2.0
       Valid-License-Identifier: GPL-2.0+
@@ -209,12 +214,12 @@ https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶�
 
 2. 不推薦的許可證:
 
-   這些許可證只應用於現有代碼或從其他項目導入代碼。這些許可證在內核目錄::
+   這些許可證只應用於現有程式碼或從其他專案導入程式碼。這些許可證在核心目錄::
 
       LICENSES/other/
 
-   此目錄中的文件包含完整的許可證文本和 `元標記`_ 。文件名與SPDX許可證標識
-   符相同，後者應用於源文件中的許可證。
+   此目錄中的檔案包含完整的許可證文本和 `元標記`_ 。檔名與SPDX許可證識別碼
+   相同，後者應用於原始檔中的許可證。
 
    例如::
 
@@ -230,7 +235,7 @@ https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶�
 
    “其他”許可證的元標籤要求與 `優先許可`_ 的要求相同。
 
-   文件格式示例::
+   檔案格式範例::
 
       Valid-License-Identifier: ISC
       SPDX-URL: https://spdx.org/licenses/ISC.html
@@ -250,50 +255,50 @@ https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶�
 3. _`例外`:
 
    某些許可證可以修改，並允許原始許可證不具有的某些例外權利。這些例外在
-   內核目錄::
+   核心目錄::
 
       LICENSES/exceptions/
 
-   此目錄中的文件包含完整的例外文本和所需的 `例外元標記`_ 。
+   此目錄中的檔案包含完整的例外文本和所需的 `例外元標記`_ 。
 
    例如::
 
       LICENSES/exceptions/Linux-syscall-note
 
-   包含Linux內核的COPYING文件中記錄的Linux系統調用例外，該文件用於UAPI
-   頭文件。例如::
+   包含Linux核心的COPYING檔案中記錄的Linux系統呼叫例外，該檔案用於UAPI
+   標頭檔。例如::
 
       LICENSES/exceptions/GCC-exception-2.0
 
-   包含GCC'鏈接例外'，它允許獨立於其許可證的任何二進制文件與標記有此例外的
-   文件的編譯版本鏈接。這是從GPL不兼容源代碼創建可運行的可執行文件所必需的。
+   包含GCC'連結例外'，它允許獨立於其許可證的任何二進位檔案與標記有此例外的
+   檔案的編譯版本連結。這是從GPL不相容原始程式碼建立可執行的可執行檔案所必需的。
 
    _`例外元標記`:
 
-   以下元標記必須在例外文件中可用：
+   以下元標記必須在例外檔案中可用：
 
    - SPDX-Exception-Identifier:
 
-     一個可與SPDX許可證標識符一起使用的例外標識符。
+     一個可與SPDX許可證識別碼一起使用的例外識別碼。
 
    - SPDX-URL:
 
-     SPDX頁面的URL，其中包含與例外相關的其他信息。
+     SPDX頁面的URL，其中包含與例外相關的其他資訊。
 
    - SPDX-Licenses:
 
-     以逗號分隔的例外可用的SPDX許可證標識符列表。
+     以逗號分隔的例外可用的SPDX許可證識別碼列表。
 
    - Usage-Guidance:
 
-     使用建議的自由格式文本。必須在文本後面加上SPDX許可證標識符的正確示例，
-     因爲它們應根據 `許可標識符語法`_ 指南放入源文件中。
+     使用建議的自由格式文本。必須在文本後面加上SPDX許可證識別碼的正確範例，
+     因為它們應根據 `許可識別碼語法`_ 指南放入原始檔中。
 
    - Exception-Text:
 
-     此標記之後的所有文本都被視爲原始異常文本
+     此標記之後的所有文本都被視為原始異常文本
 
-   文件格式示例::
+   檔案格式範例::
 
       SPDX-Exception-Identifier: Linux-syscall-note
       SPDX-URL: https://spdx.org/licenses/Linux-syscall-note.html
@@ -324,49 +329,51 @@ https://spdx.org/licenses/ 上的官方SPDX許可證列表中檢索，並附帶�
         Full exception text
 
 
-所有SPDX許可證標識符和例外都必須在LICENSES子目錄中具有相應的文件。這是允許
+所有SPDX許可證識別碼和例外都必須在LICENSES子目錄中具有相應的檔案。這是允許
 工具驗證（例如checkpatch.pl）以及準備好從源讀取和提取許可證所必需的, 這是
 各種FOSS組織推薦的，例如 `FSFE REUSE initiative <https://reuse.software/>`_.
 
-_`模塊許可`
+_`模組許可`
 -----------------
 
-   可加載內核模塊還需要MODULE_LICENSE（）標記。此標記既不替代正確的源代碼
-   許可證信息（SPDX-License-Identifier），也不以任何方式表示或確定提供模塊
-   源代碼的確切許可證。
+   可載入核心模組還需要MODULE_LICENSE（）標記。此標記既不替代正確的原始程式碼
+   許可證資訊（SPDX-License-Identifier），也不以任何方式表示或確定提供模組
+   原始程式碼的確切許可證。
 
-   此標記的唯一目的是提供足夠的信息，該模塊是否是自由軟件或者是內核模塊加
-   載器和用戶空間工具的專有模塊。
+   此標記的唯一目的是提供足夠的資訊，該模組是否是自由軟體或者是核心模組加
+   載器和使用者空間工具的專有模組。
 
-   MODULE_LICENSE（）的有效許可證字符串是:
+   MODULE_LICENSE（）的有效許可證字串是:
 
     ============================= =============================================
-    "GPL"			  模塊是根據GPL版本2許可的。這並不表示僅限於
+    "GPL"			  模組是根據GPL版本2許可的。這並不表示僅限於
                                   GPL-2.0或GPL-2.0或更高版本之間的任何區別。
-                                  最正確許可證信息只能通過相應源文件中的許可證
-                                  信息來確定
+                                  最正確許可證資訊只能透過相應原始檔中的許可證
+                                  資訊來確定
 
-    "GPL v2"			  和"GPL"相同，它的存在是因爲歷史原因。
+    "GPL v2"			  和"GPL"相同，它的存在是因為歷史原因。
 
-    "GPL and additional rights"   表示模塊源在GPL v2變體和MIT許可下雙重許可的
-                                  歷史變體。請不要在新代碼中使用。
+    "GPL and additional rights"   表示模組源在GPL v2變體和MIT許可下雙重許可的
+                                  歷史變體。請不要在新程式碼中使用。
 
-    "Dual MIT/GPL"		  表達該模塊在GPL v2變體或MIT許可證選擇下雙重
+    "Dual MIT/GPL"		  表達該模組在GPL v2變體或MIT許可證選擇下雙重
                                   許可的正確方式。
 
-    "Dual BSD/GPL"		  該模塊根據GPL v2變體或BSD許可證選擇進行雙重
-                                  許可。 BSD許可證的確切變體只能通過相應源文件
-                                  中的許可證信息來確定。
+    "Dual BSD/GPL"		  該模組根據GPL v2變體或BSD許可證選擇進行雙重
+                                  許可。 BSD許可證的確切變體只能透過相應原始檔
+                                  中的許可證資訊來確定。
 
-    "Dual MPL/GPL"		  該模塊根據GPL v2變體或Mozilla Public License
+    "Dual MPL/GPL"		  該模組根據GPL v2變體或Mozilla Public License
                                   （MPL）選項進行雙重許可。 MPL許可證的確切變體
-                                  只能通過相應的源文件中的許可證信息來確定。
-
-    "Proprietary"		  該模塊屬於專有許可。此字符串僅用於專有的第三
-                                  方模塊，不能用於在內核樹中具有源代碼的模塊。
-                                  以這種方式標記的模塊在加載時會使用'P'標記污
-                                  染內核，並且內核模塊加載器拒絕將這些模塊鏈接
-                                  到使用EXPORT_SYMBOL_GPL（）導出的符號。
+                                  只能透過相應的原始檔中的許可證資訊來確定。
+
+    "Proprietary"		  該模組屬於非GPL2相容的許可。“Proprietary
+                                  （專有）”應僅理解為“該許可證與GPLv2不相容”。
+                                  此字串僅用於非GPL2相容的第三方模組，不能用
+                                  於在核心樹中具有原始程式碼的模組。以這種方式
+                                  標記的模組在載入時會使用'P'標記污染核心，並
+                                  且核心模組載入器拒絕將這些模組連結到使用
+                                  EXPORT_SYMBOL_GPL（）匯出的符號。
     ============================= =============================================
 
 
diff --git a/Documentation/translations/zh_TW/process/programming-language.rst b/Documentation/translations/zh_TW/process/programming-language.rst
index d2c64a5599e8..a5466047b90c 100644
--- a/Documentation/translations/zh_TW/process/programming-language.rst
+++ b/Documentation/translations/zh_TW/process/programming-language.rst
@@ -5,71 +5,59 @@
 :Original: :ref:`Documentation/process/programming-language.rst <programming_language>`
 :Translator: Alex Shi <alex.shi@linux.alibaba.com>
              Hu Haowen <2023002089@link.tyut.edu.cn>
+             Chen-Yu Yeh <chenyou910331@gmail.com>
 
 .. _tw_programming_language:
 
-程序設計語言
-============
+程式語言
+========
 
-內核是用C語言 :ref:`c-language <tw_c-language>` 編寫的。更準確地說，內核通常是用 :ref:`gcc <tw_gcc>`
-在 ``-std=gnu11`` :ref:`gcc-c-dialect-options <tw_gcc-c-dialect-options>` 下編譯的：ISO C11的 GNU 方言
+Linux核心是用C程式語言 [zh_tw_c-language]_ 編寫的。更準確地說，核心通常使
+用``gcc`` [zh_tw_gcc]_ 編譯，並且使用 ``-std=gnu11``
+[zh_tw_gcc-c-dialect-options]_：這是 ISO C11 的 GNU 方言。``clang``
+[zh_tw_clang]_ 也得到了支援，詳見文件：
+:ref:`使用 Clang/LLVM 建置 Linux <kbuild_llvm>`。
 
-這種方言包含對語言 :ref:`gnu-extensions <tw_gnu-extensions>` 的許多擴展，當然，它們許多都在內核中使用。
-
-對於一些體系結構，有一些使用 :ref:`clang <tw_clang>` 和 :ref:`icc <tw_icc>` 編譯內核
-的支持，儘管在編寫此文檔時還沒有完成，仍需要第三方補丁。
+這種方言包含對C語言的許多擴展 [zh_tw_gnu-extensions]_，當然，它們許多都在核心
+中使用。
 
 屬性
 ----
 
-在整個內核中使用的一個常見擴展是屬性（attributes） :ref:`gcc-attribute-syntax <tw_gcc-attribute-syntax>`
-屬性允許將實現定義的語義引入語言實體（如變量、函數或類型），而無需對語言進行
-重大的語法更改（例如添加新關鍵字） :ref:`n2049 <tw_n2049>`
-
-在某些情況下，屬性是可選的（即不支持這些屬性的編譯器仍然應該生成正確的代碼，
-即使其速度較慢或執行的編譯時檢查/診斷次數不夠）
-
-內核定義了僞關鍵字（例如， ``pure`` ），而不是直接使用GNU屬性語法（例如,
-``__attribute__((__pure__))`` ），以檢測可以使用哪些關鍵字和/或縮短代碼, 具體
-請參閱 ``include/linux/compiler_attributes.h``
-
-.. _tw_c-language:
-
-c-language
-   http://www.open-std.org/jtc1/sc22/wg14/www/standards
-
-.. _tw_gcc:
-
-gcc
-   https://gcc.gnu.org
-
-.. _tw_clang:
-
-clang
-   https://clang.llvm.org
+在整個核心中使用的一個常見擴展是屬性（attributes）
+[zh_tw_gcc-attribute-syntax]_。屬性允許將實作定義的語義引入語言實體（如變
+數、函式或型別），而無需對語言進行重大的語法更改（例如添加新關鍵字）
+[zh_tw_n2049]_。
 
-.. _tw_icc:
+在某些情況下，屬性是可選的（即不支援這些屬性的編譯器仍然應該產生正確的程式碼，
+即使其速度較慢或執行的編譯時檢查/診斷次數不夠）。
 
-icc
-   https://software.intel.com/en-us/c-compilers
+核心定義了偽關鍵字（例如， ``__pure`` ），而不是直接使用GNU屬性語法（例如,
+``__attribute__((__pure__))`` ），以檢測可以使用哪些關鍵字和/或縮短程式碼，
+具體請參閱 ``include/linux/compiler_attributes.h``
 
-.. _tw_gcc-c-dialect-options:
-
-c-dialect-options
-   https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html
-
-.. _tw_gnu-extensions:
-
-gnu-extensions
-   https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html
-
-.. _tw_gcc-attribute-syntax:
-
-gcc-attribute-syntax
-   https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html
-
-.. _tw_n2049:
-
-n2049
-   http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2049.pdf
+Rust
+----
 
+核心支援 Rust 程式語言 [zh_tw_rust-language]_，並可以透過設定選項
+``CONFIG_RUST`` 來啟用。Rust 程式碼使用 ``rustc`` [zh_tw_rustc]_ 編譯器在
+``--edition=2021`` [zh_tw_rust-editions]_ 選項下進行編譯。版本（Editions）是
+一種在語言中引入非後向相容的小型變更的方式。
+
+除此之外，核心中還使用了一些不穩定的特性 [zh_tw_rust-unstable-features]_。
+這些不穩定的特性將來可能會發生變化，因此，一個重要的目標是達到僅使用穩定特性
+的程度。
+
+具體請參閱 Documentation/rust/index.rst
+
+.. [zh_tw_c-language] http://www.open-std.org/jtc1/sc22/wg14/www/standards
+.. [zh_tw_gcc] https://gcc.gnu.org
+.. [zh_tw_clang] https://clang.llvm.org
+.. [zh_tw_gcc-c-dialect-options] https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html
+.. [zh_tw_gnu-extensions] https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html
+.. [zh_tw_gcc-attribute-syntax] https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html
+.. [zh_tw_n2049] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2049.pdf
+.. [zh_tw_rust-language] https://www.rust-lang.org
+.. [zh_tw_rustc] https://doc.rust-lang.org/rustc/
+.. [zh_tw_rust-editions] https://doc.rust-lang.org/edition-guide/editions/
+.. [zh_tw_rust-unstable-features] https://github.com/Rust-for-Linux/linux/issues/2
diff --git a/Documentation/translations/zh_TW/process/stable-kernel-rules.rst b/Documentation/translations/zh_TW/process/stable-kernel-rules.rst
index 2f8f064f8629..7d286ad54f2e 100644
--- a/Documentation/translations/zh_TW/process/stable-kernel-rules.rst
+++ b/Documentation/translations/zh_TW/process/stable-kernel-rules.rst
@@ -6,7 +6,7 @@
 
 :Original: :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
 
-如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文
+如果想評論或更新本文的內容，請直接聯繫原文件的維護者。如果你使用英文
 交流有困難的話，也可以向中文版維護者求助。如果本翻譯更新不及時或者翻
 譯存在問題，請聯繫中文版維護者::
 
@@ -16,53 +16,213 @@
             - 李陽  Li Yang <leoyang.li@nxp.com>
             - Kangkai Yin <e12051@motorola.com>
             - 胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
+            - 葉宸佑 Chen-Yu Yeh <chenyou910331@gmail.com>
 
-所有你想知道的事情 - 關於linux穩定版發佈
-========================================
-
-關於Linux 2.6穩定版發佈，所有你想知道的事情。
-
-關於哪些類型的補丁可以被接收進入穩定版代碼樹，哪些不可以的規則：
-----------------------------------------------------------------
-
-  - 必須是顯而易見的正確，並且經過測試的。
-  - 連同上下文，不能大於100行。
-  - 必須只修正一件事情。
-  - 必須修正了一個給大家帶來麻煩的真正的bug（不是“這也許是一個問題...”
-    那樣的東西）。
-  - 必須修正帶來如下後果的問題：編譯錯誤（對被標記爲CONFIG_BROKEN的例外），
-    內核崩潰，掛起，數據損壞，真正的安全問題，或者一些類似“哦，這不
-    好”的問題。簡短的說，就是一些致命的問題。
-  - 沒有“理論上的競爭條件”，除非能給出競爭條件如何被利用的解釋。
-  - 不能存在任何的“瑣碎的”修正（拼寫修正，去掉多餘空格之類的）。
-  - 必須被相關子系統的維護者接受。
-  - 必須遵循Documentation/translations/zh_CN/process/submitting-patches.rst裏的規則。
-
-向穩定版代碼樹提交補丁的過程：
-------------------------------
-
-  - 在確認了補丁符合以上的規則後，將補丁發送到stable@vger.kernel.org。
-  - 如果補丁被接受到隊列裏，發送者會收到一個ACK回覆，如果沒有被接受，收
-    到的是NAK回覆。回覆需要幾天的時間，這取決於開發者的時間安排。
-  - 被接受的補丁會被加到穩定版本隊列裏，等待其他開發者的審查。
-  - 安全方面的補丁不要發到這個列表，應該發送到security@kernel.org。
-
-審查週期：
-----------
+所有你想知道的事情 - 關於Linux -stable 版本發布
+===============================================
+
+關於哪些類型的補丁會被接收進入 "-stable" 樹、哪些不會被接收的規則：
+
+- 該補丁或一個等效的修復必須已經存在於Linux主線（上游）。
+- 它必須是顯而易見正確的，並且經過測試的。
+- 連同上下文，它不能大於100行。
+- 它必須遵循
+  :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
+  裡的規則。
+- 它必須要麼修復一個困擾人們的真實的缺陷，要麼只是添加一個裝置ID。
+  對於前者，詳細來說：
+
+  - 它修復的問題，像是oops、當機、資料損壞、真實的安全問題、硬體怪癖
+    （hardware quirk）、建置錯誤（但不包括標記為CONFIG_BROKEN的東西），
+    或者一些“喔，這可不好”之類的問題。
+  - 發行版核心的使用者所報告的嚴重問題，如果修復的是顯著的效能或互動性
+    問題，也可以被考慮。由於這些修復不那麼顯而易見，並且有較高的風險引入
+    不易察覺的迴歸，它們應該只由發行版核心的維護者提交，並附上補充說明，
+    給出指向bugzilla條目（如果存在）的連結，以及關於使用者可見影響的額外
+    資訊。
+  - 不接受“這可能是一個問題...”之類的東西，比如“理論上的競爭條件”，除非
+    同時提供了缺陷如何被利用的解釋。
+  - 不接受對使用者沒有好處的“瑣碎”修復（拼寫更改、空白清理等）。
+
+
+向 -stable 樹提交補丁的流程
+---------------------------
+
+.. note::
+
+   安全補丁不應（只）由 -stable 審查流程處理，而應遵循
+   :ref:`Documentation/process/security-bugs.rst <securitybugs>`
+   的流程。
+
+要向 -stable 樹提交更改，有三個選項：
+
+1. 在你隨後提交到主線的補丁的描述中，加上一個“stable標籤”。
+2. 請求穩定版團隊撿取一個已經合併到主線的補丁。
+3. 向穩定版團隊提交一個與已合併到主線的更改等效的補丁。
+
+以下小節更詳細地描述每個選項。
+
+:ref:`tw_option_1` 是 **強烈** 推薦的做法，它最簡單也最常見。
+:ref:`tw_option_2` 主要用於提交時沒有考慮向後移植的更改。 :ref:`tw_option_3`
+是前兩個選項之外的替代方案，用於已合併到主線的補丁需要調整才能套用到較舊系列
+的情況（例如由於API變化）。
+
+使用選項2或3時，可以要求將你的更改包含到特定的穩定版系列中。這麼做時，要確保
+該修復或等效修復適用於、已提交到、或已經存在於所有仍在維護的較新穩定版樹中。
+這是為了防止使用者日後更新時可能遇到的迴歸，例如一個合併於5.19-rc1的修復被
+向後移植到5.10.y，卻沒有移植到5.15.y。
+
+.. _tw_option_1:
+
+選項1
+*****
+
+要讓你提交到主線的補丁之後被自動撿取到穩定版樹，請在簽署（sign-off）區加上
+這個標籤::
+
+  Cc: stable@vger.kernel.org
+
+當修復未公開的漏洞時，請改用 ``Cc: stable@kernel.org``：它可以降低透過
+'git send-email' 意外將修復公開的機會，因為發送到該地址的郵件不會被投遞到
+任何地方。
+
+補丁合併到主線後，它將被套用到穩定版樹，而無需作者或子系統維護者再做任何
+事情。
+
+要向穩定版團隊發送額外的指示，可使用shell風格的行內註解來傳遞任意的或預定義
+的備註：
+
+* 指明揀選（cherry pick）所需的額外補丁前置條件::
+
+    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>
+
+  上面標籤序列的含義為::
+
+    git cherry-pick a1f84a3
+    git cherry-pick 1b9508f
+    git cherry-pick fd21073
+    git cherry-pick <this commit>
+
+  注意，對於一個補丁系列，你不必把系列中已有的補丁列為前置條件。例如，如果
+  你有如下補丁系列::
+
+    patch1
+    patch2
+
+  其中patch2依賴patch1，如果你已經把patch1標記為穩定版收錄，就不必再把它列
+  為patch2的前置條件。
+
+* 指出核心版本的前置條件::
+
+    Cc: <stable@vger.kernel.org> # 3.3.x
+
+  該標籤的含義為::
+
+    git cherry-pick <this commit>
+
+  對每個從指定版本開始的“-stable”樹執行。
+
+  注意，如果穩定版團隊可以從Fixes:標籤推導出適當的版本，則無需這樣標記。
+
+* 延遲補丁的撿取::
 
-  - 當穩定版的維護者決定開始一個審查週期，補丁將被髮送到審查委員會，以
-    及被補丁影響的領域的維護者（除非提交者就是該領域的維護者）並且抄送
-    到linux-kernel郵件列表。
-  - 審查委員會有48小時的時間，用來決定給該補丁回覆ACK還是NAK。
-  - 如果委員會中有成員拒絕這個補丁，或者linux-kernel列表上有人反對這個
-    補丁，並提出維護者和審查委員會之前沒有意識到的問題，補丁會從隊列中
-    丟棄。
-  - 在審查週期結束的時候，那些得到ACK回應的補丁將會被加入到最新的穩定版
-    發佈中，一個新的穩定版發佈就此產生。
-  - 安全性補丁將從內核安全小組那裏直接接收到穩定版代碼樹中，而不是通過
-    通常的審查週期。請聯繫內核安全小組以獲得關於這個過程的更多細節。
-
-審查委員會：
-------------
-  - 由一些自願承擔這項任務的內核開發者，和幾個非志願的組成。
+    Cc: <stable@vger.kernel.org> # after -rc3
+
+* 指出已知的問題::
+
+    Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for <= 6.3
+
+此外，stable標籤還有一種變體，可以讓穩定版團隊的向後移植工具（例如AUTOSEL
+或尋找含有'Fixes:'標籤的提交的腳本）忽略一個更改::
+
+     Cc: <stable+noautosel@kernel.org> # reason goes here, and must be present
+
+.. _tw_option_2:
+
+選項2
+*****
+
+如果補丁已經合併到主線，請發送一封電子郵件到stable@vger.kernel.org，內容
+包含補丁的標題、提交ID、你認為它應該被套用的原因，以及你希望它被套用到哪些
+核心版本。
+
+.. _tw_option_3:
+
+選項3
+*****
+
+在確認補丁符合上述規則後，將補丁發送到stable@vger.kernel.org，並註明你希望
+它被套用到的核心版本。這麼做時，你必須在你所提交補丁的更改日誌中註明上游的
+提交ID，並在提交說明文字上方以單獨一行標註，像這樣::
+
+  commit <sha1> upstream.
+
+或者::
+
+  [ Upstream commit <sha1> ]
+
+如果提交的補丁與原始的上游補丁有出入（例如因為需要為較舊的API調整），則必須
+在補丁描述中非常清楚地記錄並說明理由。
+
+
+提交之後
+--------
+
+當補丁被接受進入佇列後，發送者會收到一個ACK；如果補丁被拒絕，則會收到NAK。
+這個回覆可能需要幾天時間，取決於穩定版團隊成員的日程安排。
+
+如果被接受，補丁將被加入 -stable 佇列，供其他開發人員和相關子系統維護者
+審查。
+
+
+審查週期
+--------
+
+- 當 -stable 維護者決定進行審查週期時，補丁將被發送到審查委員會，以及補丁
+  影響領域的維護者（除非提交者就是該領域的維護者），並抄送到linux-kernel
+  郵件列表。
+- 審查委員會有48小時的時間對補丁作出ACK或NAK。
+- 如果補丁被委員會成員拒絕，或者linux-kernel列表上的成員反對這個補丁並提出
+  了維護者和委員會成員沒有意識到的問題，補丁將從佇列中移除。
+- 通過ACK的補丁將作為釋出候選（-rc）版本的一部分再次發布，以供開發人員和
+  測試人員測試。
+- 通常只會產生一個 -rc 版本，然而如果存在未解決的問題，某些補丁可能會被修改
+  或移除，或者有額外的補丁進入佇列。此後會發布更多的 -rc 版本並加以測試，
+  直到不再發現問題為止。
+- 可以在郵件列表上發送帶有任何所需測試資訊的“Tested-by:”郵件來回覆 -rc
+  版本。“Tested-by:”標籤將被收集並加入到發布提交中。
+- 在審查週期結束時，新的 -stable 版本將被發布，其中包含所有排隊的、經過測試
+  的補丁。
+- 安全補丁將由核心安全團隊直接接受進入 -stable 樹，而不經過正常的審查週期。
+  關於這一流程的更多細節，請聯繫核心安全團隊。
+
+
+樹
+--
+
+- 已完成版本和進行中版本的補丁佇列可以在以下位置找到：
+
+    https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
+
+- 所有穩定版核心的最終定版並打上標籤的版本，可以在以下位置的每個版本各自的
+  分支中找到：
+
+    https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
+
+- 所有穩定版核心版本的釋出候選版本可以在以下位置找到：
+
+    https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/
+
+  .. warning::
+     -stable-rc 樹是stable-queue樹在某個時間點的快照，會頻繁變動，因此會經常
+     被rebase。它只應被用於測試目的（例如供CI系統使用）。
+
+
+審查委員會
+----------
 
+- 審查委員會由一些自願承擔這項任務的核心開發人員組成，還有幾位不是自願的。
diff --git a/Documentation/translations/zh_TW/process/submitting-patches.rst b/Documentation/translations/zh_TW/process/submitting-patches.rst
index 64de92c07906..b780f1539b46 100644
--- a/Documentation/translations/zh_TW/process/submitting-patches.rst
+++ b/Documentation/translations/zh_TW/process/submitting-patches.rst
@@ -15,37 +15,38 @@
  - 李陽 Li Yang <leoyang.li@nxp.com>
  - 王聰 Wang Cong <xiyou.wangcong@gmail.com>
  - 胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
+ - 葉宸佑 Chen-Yu Yeh <chenyou910331@gmail.com>
 
 
-提交補丁：如何讓你的改動進入內核
+提交補丁：如何讓你的改動進入核心
 ================================
 
-對於想要將改動提交到 Linux 內核的個人或者公司來說，如果不熟悉“規矩”，
-提交的流程會讓人畏懼。本文檔包含了一系列建議，可以大大提高你
+對於想要將改動提交到 Linux 核心的個人或者公司來說，如果不熟悉“規矩”，
+提交的流程會讓人畏懼。本文件包含了一系列建議，可以大大提高你
 的改動被接受的機會.
 
-本文檔以較爲簡潔的行文給出了大量建議。關於內核開發流程如何進行的詳細信息，
-參見： Documentation/translations/zh_CN/process/development-process.rst 。
-Documentation/translations/zh_CN/process/submit-checklist.rst 給出了一系列
+本文件以較為簡潔的行文給出了大量建議。關於核心開發流程如何進行的詳細資訊，
+參見： Documentation/translations/zh_TW/process/development-process.rst 。
+Documentation/translations/zh_TW/process/submit-checklist.rst 給出了一系列
 提交補丁之前要檢查的事項。設備樹相關的補丁，請參閱
 Documentation/devicetree/bindings/submitting-patches.rst 。
 
-本文檔假設您正在使用 ``git`` 準備你的補丁。如果您不熟悉 ``git`` ，最好學習
-如何使用它，這將使您作爲內核開發人員的生活變得更加輕鬆。
+本文件假設您正在使用 ``git`` 準備你的補丁。如果您不熟悉 ``git`` ，最好學習
+如何使用它，這將使您作為核心開發人員的生活變得更加輕鬆。
 
-部分子系統和維護人員的樹有一些關於其工作流程和要求的額外信息，請參閱
+部分子系統和維護人員的樹有一些關於其工作流程和要求的額外資訊，請參閱
 Documentation/process/maintainer-handbooks.rst 。
 
 獲取當前源碼樹
 --------------
 
-如果您手頭沒有當前內核源代碼的存儲庫，請使用 ``git`` 獲取一份。您需要先獲取
-主線存儲庫，它可以通過以下命令拉取::
+如果您手頭沒有當前核心原始程式碼的儲存庫，請使用 ``git`` 獲取一份。您需要先獲取
+主線儲存庫，它可以透過以下命令拉取::
 
     git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
 
 但是，請注意，您可能不想直接針對主線樹進行開發。大多數子系統維護人員運
-行自己的樹，並希望看到針對這些樹準備的補丁。請參見MAINTAINERS文件中子系
+行自己的樹，並希望看到針對這些樹準備的補丁。請參見MAINTAINERS檔案中子系
 統的 **T:** 項以查找該樹，或者直接詢問維護者該樹是否未在其中列出。
 
 .. _tw_describe_changes:
@@ -57,35 +58,37 @@ Documentation/process/maintainer-handbooks.rst 。
 的問題激勵您完成這項工作。說服審閱者相信有一個問題值得解決，讓他們讀完第一段
 後就能明白這一點。
 
-描述用戶可見的影響。直接崩潰和鎖定是相當有說服力的，但並不是所有的錯誤都那麼
-明目張膽。即使在代碼審閱期間發現了這個問題，也要描述一下您認爲它可能對用戶產
-生的影響。請記住，大多數Linux安裝運行的內核來自二級穩定樹或特定於供應商/產品
-的樹，只從上游精選特定的補丁，因此請包含任何可以幫助您將更改定位到下游的內容：
-觸發的場景、DMESG的摘錄、崩潰描述、性能迴歸、延遲尖峯、鎖定等。
+描述使用者可見的影響。直接崩潰和鎖定是相當有說服力的，但並不是所有的錯誤都
+那麼明目張膽。即使在程式碼審閱期間發現了這個問題，也要描述一下您認為它可能
+對使用者產生的影響。請記住，大多數Linux安裝執行的核心來自二級穩定樹或特定
+於供應商/產品的樹，只從上游精選特定的補丁，因此請包含任何可以幫助您將更改
+定位到下游的內容：觸發的場景、DMESG的摘錄、崩潰描述、效能迴歸、延遲尖峯、
+鎖定等。
 
-質量優化和權衡。如果您聲稱在性能、內存消耗、堆棧佔用空間或二進制大小方面有所
-改進，請包括支持它們的數據。但也要描述不明顯的成本。優化通常不是零成本的，而是
-在CPU、內存和可讀性之間進行權衡；或者，做探索性的工作，在不同的工作負載之間進
-行權衡。請描述優化的預期缺點，以便審閱者可以權衡成本和收益。
+品質最佳化和權衡。如果您聲稱在效能、記憶體消耗、堆疊佔用空間或二進位大小方
+面有所改進，請包括支援它們的資料。但也要描述不明顯的成本。最佳化通常不是零
+成本的，而是在CPU、記憶體和可讀性之間進行權衡；或者，做探索性的工作，在不
+同的工作負載之間進行權衡。請描述最佳化的預期缺點，以便審閱者可以權衡成本和
+收益。
 
 提出問題之後，就要詳細地描述一下您實際在做的技術細節。對於審閱者來說，用簡練的
-英語描述代碼的變化是很重要的，以驗證代碼的行爲是否符合您的意圖。
+英語描述程式碼的變化是很重要的，以驗證程式碼的行為是否符合您的意圖。
 
-如果您將補丁描述寫成“標準格式”，可以很容易地作爲“提交日誌”放入Linux的源代
+如果您將補丁描述寫成“標準格式”，可以很容易地作為“提交日誌”放入Linux的源代
 碼管理系統 ``git`` 中，那麼維護人員將非常感謝您。
-參見 :ref:`zh_the_canonical_patch_format` 。
+參見 :ref:`tw_the_canonical_patch_format` 。
 
 每個補丁只解決一個問題。如果你的描述開始變長，這就表明你可能需要拆分你的補丁。
-請見 :ref:`zh_split_changes` 。
+請見 :ref:`tw_split_changes` 。
 
-提交或重新提交補丁或補丁系列時，請包括完整的補丁說明和理由。不要
-只說這是補丁（系列）的第幾版。不要期望子系統維護人員引用更早的補丁版本或引用
-URL來查找補丁描述並將其放入補丁中。也就是說，補丁（系列）及其描述應該是獨立的。
-這對維護人員和審閱者都有好處。一些審閱者可能甚至沒有收到補丁的早期版本。
+提交或重新提交補丁或補丁系列時，請包括完整的補丁說明和理由。不要只說這是補丁
+（系列）的第幾版。不要期望子系統維護人員引用更早的補丁版本或引用URL來查
+找補丁描述並將其放入補丁中。也就是說，補丁（系列）及其描述應該是獨立的。這
+對維護人員和審閱者都有好處。一些審閱者可能甚至沒有收到補丁的早期版本。
 
 用祈使句描述你的變更，例如“make xyzzy do frotz”而不是“[This patch]make
-xyzzy do frotz”或“[I]changed xyzzy to do frotz”，就好像你在命令代碼庫改變
-它的行爲一樣。
+xyzzy do frotz”或“[I]changed xyzzy to do frotz”，就好像你在命令程式碼庫改變
+它的行為一樣。
 
 如果您想要引用一個特定的提交，不要只引用提交的SHA-1 ID。還請包括提交的一行
 摘要，以便於審閱者瞭解它是關於什麼的。例如::
@@ -95,38 +98,38 @@ xyzzy do frotz”或“[I]changed xyzzy to do frotz”，就好像你在命令�
         platform_set_drvdata(), but left the variable "dev" unused,
         delete it.
 
-您還應該確保至少使用前12位SHA-1 ID。內核存儲庫包含 *許多* 對象，使較短的ID
-發生衝突的可能性很大。記住，即使現在不會與您的六個字符ID發生衝突，這種情況
+您還應該確保至少使用前12位SHA-1 ID。核心儲存庫包含 *許多* 物件，使較短的ID
+發生衝突的可能性很大。記住，即使現在不會與您的六個字元ID發生衝突，這種情況
 也可能在五年後改變。
 
-如果該變更的相關討論或背景信息可以在網上查閱，請加上“Link:”標籤指向它。例如
-你的補丁修復了一個缺陷，需要添加一個帶有URL的標籤指向郵件列表存檔或缺陷跟蹤器
-的相關報告；如果該補丁是由一些早先郵件列表討論或網絡上的記錄引起的，請指向它。
+如果該變更的相關討論或背景資訊可以在網上查閱，請加上“Link:”標籤指向它。例如
+你的補丁修復了一個缺陷，需要添加一個帶有URL的標籤指向郵件列表存檔或缺陷追蹤器
+的相關報告；如果該補丁是由一些早先郵件列表討論或網路上的記錄引起的，請指向它。
 
-當鏈接到郵件列表存檔時，請首選lore.kernel.org郵件存檔服務。用郵件中的
-``Message-ID`` 頭（去掉尖括號）可以創建鏈接URL。例如::
+當連結到郵件列表存檔時，請首選lore.kernel.org郵件存檔服務。用郵件中的
+``Message-ID`` 頭（去掉尖括號）可以建立連結URL。例如::
 
-    Link: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/
+    Link: https://lore.kernel.org/30th.anniversary.repost@klaava.Helsinki.FI
 
-請檢查該鏈接以確保可用且指向正確的郵件。
+請檢查該連結以確保可用且指向正確的郵件。
 
 不過，在沒有外部資源的情況下，也要儘量讓你的解釋可理解。除了提供郵件列表存檔或
 缺陷的URL之外，還要需要總結該補丁的相關討論要點。
 
-如果補丁修復了特定提交中的錯誤，例如使用 ``git bisct`` 發現了一個問題，請使用
-帶有前12個字符SHA-1 ID的“Fixes:”標籤和單行摘要。爲了簡化解析腳本，不要將該
-標籤拆分爲多行，標籤不受“75列換行”規則的限制。例如::
+如果補丁修復了特定提交中的錯誤，例如使用 ``git bisect`` 發現了一個問題，請使用
+帶有至少前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`` 增加上述風格的顯示格式::
+下列 ``git config`` 設定可以讓 ``git log``, ``git show`` 增加上述風格的顯示格式::
 
 	[core]
 		abbrev = 12
 	[pretty]
 		fixes = Fixes: %h (\"%s\")
 
-使用示例::
+使用範例::
 
 	$ git log -1 --pretty=fixes 54a4f0239f2e
 	Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually freed")
@@ -138,41 +141,42 @@ xyzzy do frotz”或“[I]changed xyzzy to do frotz”，就好像你在命令�
 
 將每個 **邏輯更改** 拆分成一個單獨的補丁。
 
-例如，如果你的改動裏同時有bug修正和性能優化，那麼把這些改動拆分到兩個或
-者更多的補丁文件中。如果你的改動包含對API的修改，並且增加了一個使用該新API
+例如，如果你的改動裡同時有bug修正和效能最佳化，那麼把這些改動拆分到兩個或
+者更多的補丁檔案中。如果你的改動包含對API的修改，並且增加了一個使用該新API
 的驅動，那麼把這些修改分成兩個補丁。
 
-另一方面，如果你將一個單獨的改動做成多個補丁文件，那麼將它們合併成一個
-單獨的補丁文件。這樣一個邏輯上單獨的改動只被包含在一個補丁文件裏。
+另一方面，如果你將一個單獨的改動做成多個補丁檔案，那麼將它們合併成一個
+單獨的補丁檔案。這樣一個邏輯上單獨的改動只被包含在一個補丁檔案裡。
 
 需要記住的一點是，每個補丁的更改都應易於理解，以便審閱者驗證。每個補丁都應該
 對其價值進行闡述。
 
-如果有一個補丁依賴另外一個補丁來完成它的改動，那沒問題。直接在你的補
-丁描述裏指出 **“這個補丁依賴某補丁”** 就好了。
+如果有一個補丁依賴另外一個補丁來完成它的改動，那沒問題。直接在你的補丁
+描述裡指出 **“這個補丁依賴某補丁”** 就好了。
 
-在將您的更改劃分爲一系列補丁時，要特別注意確保內核在應用系列中的每個補丁之後
-都能正常構建和運行。使用 ``git bisect`` 來追蹤問題的開發者可能會在任何地方分
+在將您的更改劃分為一系列補丁時，要特別注意確保核心在應用系列中的每個補丁之後
+都能正常建置和執行。使用 ``git bisect`` 來追蹤問題的開發者可能會在任何地方分
 割你的補丁系列；如果你在中間引入錯誤，他們不會感謝你。
 
 如果你不能將補丁系列濃縮得更小，那麼每次大約發送出15個補丁，然後等待審閱
-和集成。
+和整合。
 
 檢查你的更改風格
 ----------------
 
-檢查您的補丁是否違反了基本樣式規定，詳細信息參見
-Documentation/translations/zh_CN/process/coding-style.rst
+檢查您的補丁是否違反了基本樣式規定，詳細資訊參見
+Documentation/translations/zh_TW/process/coding-style.rst
 中找到。如果不這樣做，只會浪費審閱者的時間，並且會導致你的補丁被拒絕，甚至
 可能沒有被閱讀。
 
-一個重要的例外是在將代碼從一個文件移動到另一個文件時——在這種情況下，您不應
-該在移動代碼的同一個補丁中修改移動的代碼。這清楚地描述了移動代碼和您的更改
-的行爲。這大大有助於審閱實際差異，並允許工具更好地跟蹤代碼本身的歷史。
+一個重要的例外是在將程式碼從一個檔案移動到另一個檔案時——在這種情況下，您不
+應該在移動程式碼的同一個補丁中修改移動的程式碼。這清楚地描述了移動程式碼和
+您的更改的行為。這大大有助於審閱實際差異，並允許工具更好地追蹤程式碼本身的
+歷史。
 
-在提交之前，使用補丁樣式檢查程序檢查補丁（scripts/check patch.pl）。不過，
-請注意，樣式檢查程序應該被視爲一個指南，而不是作爲人類判斷的替代品。如果您
-的代碼看起來更好，但有違規行爲，那麼最好別管它。
+在提交之前，使用補丁樣式檢查程式檢查補丁（scripts/checkpatch.pl）。不過，
+請注意，樣式檢查程式應該被視為一個指南，而不是作為人類判斷的替代品。如果您
+的程式碼看起來更好，但有違規行為，那麼最好別管它。
 
 檢查者報告三個級別：
 
@@ -180,58 +184,56 @@ Documentation/translations/zh_CN/process/coding-style.rst
  - WARNING：需要仔細審閱的事項
  - CHECK：需要思考的事情
 
-您應該能夠判斷您的補丁中存在的所有違規行爲。
+您應該能夠判斷您的補丁中存在的所有違規行為。
 
 選擇補丁收件人
 --------------
 
-您應該總是知會任何補丁相應代碼的子系統維護人員；查看
-維護人員文件和源代碼修訂歷史記錄，以瞭解這些維護人員是誰。腳本
+您應該總是知會任何補丁相應程式碼的子系統維護人員；查看
+MAINTAINERS檔案和原始程式碼修訂歷史記錄，以瞭解這些維護人員是誰。腳本
 scripts/get_maintainer.pl在這個步驟中非常有用。如果您找不到正在工作的子系統
 的維護人員，那麼Andrew Morton（akpm@linux-foundation.org）將充當最後的維護
 人員。
 
-您通常還應該選擇至少一個郵件列表來接收補丁集的副本。linux-kernel@vger.kernel.org
-是所有補丁的默認列表，但是這個列表的流量已經導致了許多開發人員不再看它。
-在MAINTAINERS文件中查找子系統特定的列表；您的補丁可能會在那裏得到更多的關注。
-不過，請不要發送垃圾郵件到無關的列表。
+您通常還應該選擇至少一個郵件列表來接收補丁集的副本。linux-kernel@
+vger.kernel.org是所有補丁的預設列表，但是這個列表的流量已經導致了許多開發
+人員不再看它。在MAINTAINERS檔案中查找子系統特定的列表；您的補丁可能會在那
+裡得到更多的關注。不過，請不要發送垃圾郵件到無關的列表。
 
-許多與內核相關的列表託管在vger.kernel.org上；您可以在
-http://vger.kernel.org/vger-lists.html 上找到它們的列表。不過，也有與內核相關
+許多與核心相關的列表託管在kernel.org上；您可以在
+https://subspace.kernel.org 上找到它們的列表。不過，也有與核心相關
 的列表託管在其他地方。
 
-不要一次發送超過15個補丁到vger郵件列表！！！！
-
-Linus Torvalds是決定改動能否進入 Linux 內核的最終裁決者。他的郵件地址是
+Linus Torvalds是決定改動能否進入 Linux 核心的最終裁決者。他的郵件地址是
 torvalds@linux-foundation.org 。他收到的郵件很多，所以一般來說最好 **別**
 給他發郵件。
 
-如果您有修復可利用安全漏洞的補丁，請將該補丁發送到 security@kernel.org 。對於
-嚴重的bug，可以考慮短期禁令以允許分銷商（有時間）向用戶發佈補丁；在這種情況下，
-顯然不應將補丁發送到任何公共列表。
-參見 Documentation/translations/zh_CN/process/security-bugs.rst 。
+如果您有修復可利用安全漏洞的補丁，請將該補丁發送到 security@kernel.org 。
+對於嚴重的bug，可以考慮短期禁令以允許分銷商（有時間）向使用者發布補丁；在
+這種情況下，顯然不應將補丁發送到任何公共列表。參見
+Documentation/process/security-bugs.rst 。
 
-修復已發佈內核中嚴重錯誤的補丁程序應該抄送給穩定版維護人員，方法是把以下列行
-放進補丁的籤準區（注意，不是電子郵件收件人）::
+修復已發布核心中嚴重錯誤的補丁程式應該抄送給穩定版維護人員，方法是把以下列行
+放進補丁的簽署區（注意，不是電子郵件收件人）::
 
   Cc: stable@vger.kernel.org
 
 除了本文件之外，您還應該閱讀
-Documentation/translations/zh_CN/process/stable-kernel-rules.rst 。
+Documentation/translations/zh_TW/process/stable-kernel-rules.rst 。
 
-如果更改影響到用戶側內核接口，請向手冊頁維護人員（如維護人員文件中所列）發送
-手冊頁補丁，或至少發送更改通知，以便一些信息進入手冊頁。還應將用戶空間API
-更改抄送到 linux-api@vger.kernel.org 。
+如果更改影響到使用者側核心介面，請向手冊頁維護人員（如MAINTAINERS檔案中所
+列）發送手冊頁補丁，或至少發送更改通知，以便一些資訊進入手冊頁。還應將使用
+者空間API更改抄送到 linux-api@vger.kernel.org 。
 
 
-不要MIME編碼，不要鏈接，不要壓縮，不要附件，只要純文本
+不要MIME編碼，不要連結，不要壓縮，不要附件，只要純文字
 ------------------------------------------------------
 
-Linus 和其他的內核開發者需要閱讀和評論你提交的改動。對於內核開發者來說
+Linus 和其他的核心開發者需要閱讀和評論你提交的改動。對於核心開發者來說
 ，可以“引用”你的改動很重要，使用一般的郵件工具，他們就可以在你的
-代碼的任何位置添加評論。
+程式碼的任何位置添加評論。
 
-因爲這個原因，所有的提交的補丁都是郵件中“內嵌”的。最簡單（和推薦）的方法就
+因為這個原因，所有的提交的補丁都是郵件中“內嵌”的。最簡單（和推薦）的方法就
 是使用 ``git send-email`` 。https://git-send-email.io 有 ``git send-email``
 的交互式教程。
 
@@ -239,30 +241,54 @@ Linus 和其他的內核開發者需要閱讀和評論你提交的改動。對�
 
 .. warning::
 
-  如果你使用剪切-粘貼你的補丁，小心你的編輯器的自動換行功能破壞你的補丁
+  如果你使用剪切-貼上你的補丁，小心你的編輯器的自動換行功能破壞你的補丁
 
-不要將補丁作爲MIME編碼的附件，不管是否壓縮。很多流行的郵件軟件不
-是任何時候都將MIME編碼的附件當作純文本發送的，這會使得別人無法在你的
-代碼中加評論。另外，MIME編碼的附件會讓Linus多花一點時間來處理，這就
+不要將補丁作為MIME編碼的附件，不管是否壓縮。很多流行的郵件軟體不
+是任何時候都將MIME編碼的附件當作純文字發送的，這會使得別人無法在你的
+程式碼中加評論。另外，MIME編碼的附件會讓Linus多花一點時間來處理，這就
 降低了你的改動被接受的可能性。
 
 例外：如果你的郵路損壞了補丁，那麼有人可能會要求你使用MIME重新發送補丁。
 
-請參閱 Documentation/translations/zh_CN/process/email-clients.rst
-以獲取有關配置電子郵件客戶端以使其不受影響地發送補丁的提示。
+請參閱 Documentation/translations/zh_TW/process/email-clients.rst
+以獲取有關設定電子郵件客戶端以使其不受影響地發送補丁的提示。
 
 回覆審閱意見
 ------------
 
 你的補丁幾乎肯定會得到審閱者對補丁改進方法的評論（以回覆郵件的形式）。您必須
 對這些評論作出回應；讓補丁被忽略的一個好辦法就是忽略審閱者的意見。直接回復郵
-件來回應意見即可。不會導致代碼更改的意見或問題幾乎肯定會帶來註釋或變更日誌的
+件來回應意見即可。不會導致程式碼更改的意見或問題幾乎肯定會帶來註解或變更日誌的
 改變，以便下一個審閱者更好地瞭解正在發生的事情。
 
-一定要告訴審閱者你在做什麼改變，並感謝他們的時間。代碼審閱是一個累人且耗時的
+一定要告訴審閱者你在做什麼改變，並感謝他們的時間。程式碼審閱是一個累人且耗時的
 過程，審閱者有時會變得暴躁。即使在這種情況下，也要禮貌地回應並解決他們指出的
 問題。當發送下一版時，在封面郵件或獨立補丁里加上 ``patch changelog`` 說明與
-前一版本的不同之處（參見 :ref:`zh_the_canonical_patch_format` ）。
+前一版本的不同之處（參見 :ref:`tw_the_canonical_patch_format` ）。
+
+.. _tw_interleaved_replies:
+
+在郵件討論中使用裁剪過的交錯式回覆
+----------------------------------
+
+在Linux核心開發的討論中，強烈不建議置頂回覆（top-posting）。交錯式（或
+“行內”）回覆使對話更容易理解。更多細節參見：
+https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
+
+正如郵件列表中經常被引用的那樣::
+
+  A: http://en.wikipedia.org/wiki/Top_post
+  Q: Where do I find info about this thing called top-posting?
+  A: Because it messes up the order in which people normally read text.
+  Q: Why is top-posting such a bad thing?
+  A: Top-posting.
+  Q: What is the most annoying thing in e-mail?
+
+同樣，請裁剪掉所有與你的回覆無關的引文。這使回覆更容易查找，並節省時間和
+空間。更多細節參見： http://daringfireball.net/2007/07/on_top ::
+
+  A: No.
+  Q: Should I include quotations after my reply?
 
 .. _tw_resend_reminders:
 
@@ -271,54 +297,54 @@ Linus 和其他的內核開發者需要閱讀和評論你提交的改動。對�
 
 提交更改後，請耐心等待。審閱者是大忙人，可能無法立即審閱您的補丁。
 
-曾幾何時，補丁曾在沒收到評論的情況下消失在虛空中，但現在開發過程應該更加順利了。
-您應該在一週左右的時間內收到評論；如果沒有收到評論，請確保您已將補丁發送
-到正確的位置。在重新提交或聯繫審閱者之前至少等待一週——在諸如合併窗口之類的
-繁忙時間可能更長。
+曾幾何時，補丁曾在沒收到評論的情況下消失在虛空中，但現在開發過程應該更加順
+利了。您應該在一週左右的時間內收到評論；如果沒有收到評論，請確保您已將補丁
+發送到正確的位置。在重新提交或聯繫審閱者之前至少等待一週——在諸如合併視窗之
+類的繁忙時間可能更長。
 
 在等了幾個星期後，用帶RESEND的主題重發補丁也是可以的::
 
    [PATCH Vx RESEND] sub/sys: Condensed patch summary
 
-當你發佈補丁（系列）修改版的時候，不要加上“RESEND”——“RESEND”只適用於重
+當你發布補丁（系列）修改版的時候，不要加上“RESEND”——“RESEND”只適用於重
 新提交之前未經修改的補丁（系列）。
 
 主題中包含 PATCH
 ----------------
 
 由於到Linus和linux-kernel的電子郵件流量很高，通常會在主題行前面加上[PATCH]
-前綴。這使Linus和其他內核開發人員更容易將補丁與其他電子郵件討論區分開。
+前綴。這使Linus和其他核心開發人員更容易將補丁與其他電子郵件討論區分開。
 
-``git send-email`` 會自動爲你加上。
+``git send-email`` 會自動為你加上。
 
 簽署你的作品——開發者來源認證
 ------------------------------
 
-爲了加強對誰做了何事的追蹤，尤其是對那些透過好幾層維護者才最終到達的補丁，我
-們在通過郵件發送的補丁上引入了“簽署（sign-off）”流程。
+為了加強對誰做了何事的追蹤，尤其是對那些透過好幾層維護者才最終到達的補丁，我
+們在透過郵件發送的補丁上引入了“簽署（sign-off）”流程。
 
-“簽署”是在補丁註釋最後的一行簡單文字，認證你編寫了它或者其他
-人有權力將它作爲開放源代碼的補丁傳遞。規則很簡單：如果你能認證如下信息:
+“簽署”是在補丁註解最後的一行簡單文字，認證你編寫了它或者其他
+人有權力將它作為開放原始程式碼的補丁傳遞。規則很簡單：如果你能認證如下資訊:
 
 開發者來源認證 1.1
 ^^^^^^^^^^^^^^^^^^
 
-對於本項目的貢獻，我認證如下信息：
+對於本專案的貢獻，我認證如下資訊：
 
-       (a) 這些貢獻是完全或者部分的由我創建，我有權利以文件中指出
-           的開放源代碼許可證提交它；或者
+       (a) 這些貢獻是完全或者部分的由我建立，我有權利以文件中指出
+           的開放原始程式碼許可證提交它；或者
 
        (b) 這些貢獻基於以前的工作，據我所知，這些以前的工作受恰當的開放
-           源代碼許可證保護，而且，根據文件中指出的許可證，我有權提交修改後的貢獻，
-           無論是完全還是部分由我創造，這些貢獻都使用同一個開放源代碼許可證
+           原始程式碼許可證保護，而且，根據文件中指出的許可證，我有權提交修改後的貢獻，
+           無論是完全還是部分由我創造，這些貢獻都使用同一個開放原始程式碼許可證
            （除非我被允許用其它的許可證）；或者
 
        (c) 這些貢獻由認證（a），（b）或者（c）的人直接提供給我，而
            且我沒有修改它。
 
-       (d) 我理解並同意這個項目和貢獻是公開的，貢獻的記錄（包括我
-           一起提交的個人記錄，包括sign-off）被永久維護並且可以和這個項目
-           或者開放源代碼的許可證同步地再發行。
+       (d) 我理解並同意這個專案和貢獻是公開的，貢獻的記錄（包括我
+           一起提交的個人記錄，包括sign-off）被永久維護並且可以和這個專案
+           或者開放原始程式碼的許可證同步地再發行。
 
 那麼加入這樣一行::
 
@@ -339,33 +365,47 @@ Linus 和其他的內核開發者需要閱讀和評論你提交的改動。對�
 
 Signed-off-by: 標籤表示簽名者參與了補丁的開發，或者他/她在補丁的傳遞路徑中。
 
-如果一個人沒有直接參與補丁的準備或處理，但希望表示並記錄他們對補丁的批准/贊成，
-那麼他們可以要求在補丁的變更日誌中添加一個Acked-by:。
+如果一個人沒有直接參與補丁的準備或處理，但希望表示並記錄他們對補丁的批准/
+贊成，那麼他們可以要求在補丁的變更日誌中添加一個Acked-by:。
+
+Acked-by: 供以某種方式對受影響程式碼負責或與之相關的人使用。最常見的情況是，
+當維護者既沒有貢獻也沒有轉發補丁時，由該維護者使用。
 
-Acked-by: 通常由受影響代碼的維護者使用，當該維護者既沒有貢獻也沒有轉發補丁時。
+Acked-by: 也可以由其他利益相關者使用，例如具有領域知識的人（例如被修改程式
+碼的原作者）、核心uAPI補丁的使用者空間側審閱者，或某項功能的關鍵使用者。在
+這些情況下，可以視需要加上一個“# 後綴”以澄清其含義::
+
+	Acked-by: The Stakeholder <stakeholder@example.org> # As primary user
 
 Acked-by: 不像簽署那樣正式。這是一個記錄，確認人至少審閱了補丁，並表示接受。
-因此，補丁合併有時會手動將Acker的“Yep，looks good to me”轉換爲 Acked-By:（但
+因此，補丁合併有時會手動將Acker的“Yep，looks good to me”轉換為 Acked-By:（但
 請注意，通常最好要求一個明確的Ack）。
 
-Acked-by：不一定表示對整個補丁的確認。例如，如果一個補丁影響多個子系統，並且
-有一個來自某個子系統維護者的Acked-By:，那麼這通常表示只確認影響維護者代碼的部
-分。這裏應該仔細判斷。如有疑問，應參考郵件列表存檔中的原始討論。
+Acked-by: 也不如 Reviewed-by: 正式。例如，維護者可以用它表示他們同意補丁
+合入，但可能沒有像提供Reviewed-by:那樣徹底地審閱過補丁。同樣，關鍵使用者
+可能沒有對補丁進行技術審閱，但他們可能對整體方法、功能或面向使用者的介面
+感到滿意。
+
+Acked-by：不一定表示對整個補丁的確認。例如，如果一個補丁影響多個子系統，並
+且有一個來自某個子系統維護者的Acked-By:，那麼這通常表示只確認影響維護者程
+式碼的部分。這裡應該仔細判斷。如有疑問，應參考郵件列表存檔中的原始討論。在
+這種情況下也可以使用“# 後綴”來澄清。
 
 如果某人本應有機會對補丁進行評論，但沒有提供此類評論，您可以選擇在補丁中添加
-``Cc:`` 這是唯一可以在沒有被該人明確同意的情況下添加的標籤——但它應該表明
-這個人是在補丁上抄送的。此標籤記錄了討論中包含的潛在利益相關方。
+``Cc:`` 標籤。此標籤記錄了討論中包含的潛在利益相關方。注意，這是僅有的三個
+可以在未經被指名者明確許可的情況下使用的標籤之一（詳見下面的“標記他人需要
+許可”）。
 
-Co-developed-by: 聲明補丁是由多個開發人員共同創建的；當幾個人在一個補丁上工
-作時，它用於給出共同作者（除了From:所給出的作者之外）。因爲Co-developed-by:
+Co-developed-by: 聲明補丁是由多個開發人員共同建立的；當幾個人在一個補丁上工
+作時，它用於給出共同作者（除了From:所給出的作者之外）。因為Co-developed-by:
 表示作者身份，所以每個Co-developed-by:必須緊跟在相關合作作者的簽署之後。標準
-簽署程序要求Signed-off-by:標籤的順序應儘可能反映補丁的時間歷史，無論作者是通
+簽署程式要求Signed-off-by:標籤的順序應儘可能反映補丁的時間歷史，無論作者是通
 過From:還是Co-developed-by:表明。值得注意的是，最後一個Signed-off-by:必須是
 提交補丁的開發人員。
 
 注意，如果From:作者也是電子郵件標題的From:行中列出的人，則From:標籤是可選的。
 
-被From:作者提交的補丁示例::
+被From:作者提交的補丁範例::
 
 	<changelog>
 
@@ -375,7 +415,7 @@ Co-developed-by: 聲明補丁是由多個開發人員共同創建的；當幾個
 	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>
 
@@ -392,67 +432,95 @@ Co-developed-by: 聲明補丁是由多個開發人員共同創建的；當幾個
 -----------------------------------------------------------------
 
 Reported-by: 給那些發現錯誤並報告錯誤的人致謝，它希望激勵他們在將來再次幫助
-我們。請注意，如果bug是以私有方式報告的，那麼在使用Reported-by標籤之前，請
-先請求許可。此標籤是爲Bug設計的；請不要將其用於感謝功能請求。
+我們。注意，Reported-by標籤是僅有的三個可以在未經被指名者明確許可的情況下
+使用的標籤之一（詳見下面的“標記他人需要許可”）。此標籤是為Bug設計的；請不要
+將其用於感謝功能請求。
 
 Tested-by: 標籤表示補丁已由指定的人（在某些環境中）成功測試。這個標籤通知
-維護人員已經執行了一些測試，爲將來的補丁提供了一種定位測試人員的方法，並彰顯測試人員的功勞。
+維護人員已經執行了一些測試，為將來的補丁提供了一種定位測試人員的方法，並彰
+顯測試人員的功勞。
 
-Reviewed-by：根據審閱者的監督聲明，表明該補丁已被審閱並被認爲是可接受的：
+Reviewed-by：根據審閱者的監督聲明，表明該補丁已被審閱並被認為是可接受的：
 
 
 審閱者的監督聲明
 ^^^^^^^^^^^^^^^^
 
-通過提供我的Reviewed-by:標籤，我聲明：
+透過提供我的Reviewed-by:標籤，我聲明：
 
         (a) 我已經對這個補丁進行了一次技術審閱，以評估它是否適合被包含到
-            主線內核中。
+            主線核心中。
 
         (b) 與補丁相關的任何問題、顧慮或問題都已反饋給提交者。我對提交者對
             我的評論的回應感到滿意。
 
-        (c) 雖然這一提交可能仍可被改進，但我相信，此時，（1）對內核
+        (c) 雖然這一提交可能仍可被改進，但我相信，此時，（1）對核心
             進行了有價值的修改，（2）沒有包含爭論中涉及的已知問題。
 
-        (d) 雖然我已經審閱了補丁並認爲它是健全的，但我不會（除非另有明確
-            說明）作出任何保證或擔保它會在任何給定情況下實現其規定的目的
-            或正常運行。
+        (d) 雖然我已經審閱了補丁並認為它是健全的，但我不會（除非另有明確
+            說明）作出任何保證或擔保它會在任何給定情況下實作其規定的目的
+            或正常執行。
 
-Reviewed-by是一種觀點聲明，即補丁是對內核的適當修改，沒有任何遺留的嚴重技術
-問題。任何感興趣的審閱者（完成工作的人）都可以爲一個補丁提供一個Reviewed-by
-標籤。此標籤用於向審閱者提供致謝，並通知維護者補丁的審閱進度。
-當Reviewed-by:標籤由已知了解主題區域並執行徹底檢查的審閱者提供時，通常會增加
-補丁進入內核的可能性。
+Reviewed-by是一種觀點聲明，即補丁是對核心的適當修改，沒有任何遺留的嚴重技
+術問題。任何感興趣的審閱者（完成了審閱工作且具有已知身分的人）都可以為一個
+補丁提供一個Reviewed-by標籤。此標籤用於向審閱者提供致謝，並通知維護者補丁
+的審閱進度。當Reviewed-by:標籤由已知了解主題區域並執行徹底檢查的審閱者提供
+時，通常會增加補丁進入核心的可能性。
 
-一旦從測試人員或審閱者的“Tested-by”和“Reviewed-by”標籤出現在郵件列表中，
-作者應在發送下一個版本時將其添加到適用的補丁中。但是，如果補丁在以下版本中發
-生了實質性更改，這些標籤可能不再適用，因此應該刪除。通常，在補丁更改日誌中
-（在 ``---`` 分隔符之後）應該提到刪除某人的測試者或審閱者標籤。
+一旦從測試人員或審閱者的“Tested-by”和“Reviewed-by”標籤出現在郵件列表中，作
+者應在發送下一個版本時將其添加到適用的補丁中。但是，如果補丁在以下版本中發
+生了實質性更改，這些標籤可能不再適用，因此應該刪除。通常，刪除某人的
+Acked-by、Tested-by或Reviewed-by標籤時，應在補丁更改日誌中（在 ``---`` 分
+隔符之後）提及並附上解釋。
 
 Suggested-by: 表示補丁的想法是由指定的人提出的，並確保將此想法歸功於指定的
-人。請注意，未經許可，不得添加此標籤，特別是如果該想法未在公共論壇上發佈。
-也就是說，如果我們勤快地致謝創意提供者，他們將受到鼓舞，很有希望在未來再次
-幫助我們。
+人：如果我們勤快地致謝創意提供者，他們將受到鼓舞，很有希望在未來再次幫助
+我們。注意，這是僅有的三個可以在未經被指名者明確許可的情況下使用的標籤之一
+（詳見下面的“標記他人需要許可”）。
 
-Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定錯誤的來源，這有助於
-檢查錯誤修復。這個標籤還幫助穩定內核團隊確定應該接收修復的穩定內核版本。這是
-指示補丁修復的錯誤的首選方法。請參閱 :ref:`zh_describe_changes` 瞭解更多信息。
+Fixes: 指示補丁修復了之前提交中的一個缺陷。它可以便於確定問題的來源，這有助於
+檢查錯誤修復。這個標籤還幫助穩定核心團隊確定應該接收修復的穩定核心版本。這是
+指示補丁修復的錯誤的首選方法。請參閱 :ref:`tw_describe_changes` 瞭解更多資訊。
 
 .. note::
 
-  附加Fixes:標籤不會改變穩定內核規則流程，也不改變所有穩定版補丁抄送
-  stable@vger.kernel.org的要求。有關更多信息，請閱讀
-  Documentation/translations/zh_CN/process/stable-kernel-rules.rst 。
+  附加Fixes:標籤不會改變穩定核心規則流程，也不改變所有穩定版補丁抄送
+  stable@vger.kernel.org的要求。有關更多資訊，請閱讀
+  Documentation/translations/zh_TW/process/stable-kernel-rules.rst 。
+
+最後，雖然提供標籤是受歡迎的且通常非常受讚賞，但請注意，簽署者（即提交者和
+維護者）可以自行斟酌是否採用所提供的標籤。
+
+.. _tw_tagging_people:
+
+標記他人需要許可
+----------------
+
+在補丁中添加上述標籤時要小心：除了Cc:、Reported-by:和Suggested-by:之外，
+所有標籤都需要被指名者的明確許可。對於這三個標籤，如果根據lore存檔或提交
+歷史，該人曾以該名字和電子郵件地址對Linux核心做出過貢獻，那麼隱含的許可
+就足夠了——並且對於Reported-by:和Suggested-by:，報告或建議必須是公開作出
+的。注意，就此而言bugzilla.kernel.org是公開場所，但其中使用的電子郵件地址
+是私密的；因此不要在標籤中暴露它們，除非該人在先前的貢獻中使用過。
+
+使用Assisted-by:
+----------------
+
+如果您在建立補丁的過程中使用了任何進階編碼工具，您需要透過添加Assisted-by
+標籤來聲明這一使用。不這樣做可能會妨礙您的工作被接受。關於聲明編碼助手的
+細節，請參見 Documentation/process/coding-assistants.rst 。
 
 .. _tw_the_canonical_patch_format:
 
 標準補丁格式
 ------------
 
-本節描述如何格式化補丁本身。請注意，如果您的補丁存儲在 ``Git`` 存儲庫中，則
-可以使用 ``git format-patch`` 進行正確的補丁格式化。但是，這些工具無法創建
-必要的文本，因此請務必閱讀下面的說明。
+本節描述如何格式化補丁本身。請注意，如果您的補丁儲存在 ``Git`` 儲存庫中，則
+可以使用 ``git format-patch`` 進行正確的補丁格式化。但是，這些工具無法建立
+必要的文字，因此請務必閱讀下面的說明。
+
+主題行
+^^^^^^
 
 標準的補丁標題行是::
 
@@ -460,7 +528,8 @@ Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定�
 
 標準補丁的信體包含如下部分：
 
-  - 一個 ``from`` 行指出補丁作者。後跟空行（僅當發送補丁的人不是作者時才需要）。
+  - 一個 ``from`` 行指出補丁作者。後跟空行（僅當發送補丁的人不是作者時才需
+    要）。
 
   - 說明文字，每行最長75列，這將被複制到永久變更日誌來描述這個補丁。
 
@@ -470,30 +539,30 @@ Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定�
 
   - 只包含 ``---`` 的標記線。
 
-  - 任何其他不適合放在變更日誌的註釋。
+  - 任何其他不適合放在變更日誌的註解。
 
   - 實際補丁（ ``diff`` 輸出）。
 
 標題行的格式，使得對標題行按字母序排序非常的容易——很多郵件客戶端都
-可以支持——因爲序列號是用零填充的，所以按數字排序和按字母排序是一樣的。
+可以支援——因為序列號是用零填充的，所以按數字排序和按字母排序是一樣的。
 
-郵件標題中的“子系統”標識哪個內核子系統將被打補丁。
+郵件標題中的“子系統”標識哪個核心子系統將被打補丁。
 
 郵件標題中的“一句話概述”扼要的描述郵件中的補丁。“一句話概述”
-不應該是一個文件名。對於一個補丁系列（“補丁系列”指一系列的多個相關補
-丁），不要對每個補丁都使用同樣的“一句話概述”。
+不應該是一個檔名。對於一個補丁系列（“補丁系列”指一系列的多個相關補丁
+），不要對每個補丁都使用同樣的“一句話概述”。
 
-記住郵件的“一句話概述”會成爲該補丁的全局唯一標識。它會進入 ``git``
-的改動記錄裏。然後“一句話概述”會被用在開發者的討論裏，用來指代這個補
-丁。用戶將希望通過搜索引擎搜索“一句話概述”來找到那些討論這個補丁的文
+記住郵件的“一句話概述”會成為該補丁的全域唯一標識。它會進入 ``git``
+的改動記錄裡。然後“一句話概述”會被用在開發者的討論裡，用來指代這個補丁
+。使用者將希望透過搜索引擎搜索“一句話概述”來找到那些討論這個補丁的文
 章。當人們在兩三個月後使用諸如 ``gitk`` 或 ``git log --oneline`` 之類
 的工具查看數千個補丁時，也會很快看到它。
 
-出於這些原因，概述必須不超過70-75個字符，並且必須描述補丁的更改以及爲
+出於這些原因，概述必須不超過70-75個字元，並且必須描述補丁的更改以及為
 什麼需要補丁。既要簡潔又要描述性很有挑戰性，但寫得好的概述應該這樣。
 
 概述的前綴可以用方括號括起來：“Subject: [PATCH <tag>...] <概述>”。標記
-不被視爲概述的一部分，而是描述應該如何處理補丁。如果補丁的多個版本已發
+不被視為概述的一部分，而是描述應該如何處理補丁。如果補丁的多個版本已發
 送出來以響應評審（即“v1，v2，v3”）則必須包含版本號，或包含“RFC”以指示
 評審請求。如果一個補丁系列中有四個補丁，那麼各個補丁可以這樣編號：1/4、2/4、
 3/4、4/4。這可以確保開發人員瞭解補丁應用的順序，且
@@ -501,42 +570,78 @@ Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定�
 
 一些標題的例子::
 
-    Subject: [patch 2/5] ext2: improve scalability of bitmap searching
-    Subject: [PATCHv2 001/207] x86: fix eflags tracking
+    Subject: [PATCH 2/5] ext2: improve scalability of bitmap searching
+    Subject: [PATCH v2 01/27] x86: fix eflags tracking
+    Subject: [PATCH v2] sub/sys: Condensed patch summary
+    Subject: [PATCH v2 M/N] sub/sys: Condensed patch summary
+
+From行
+^^^^^^
 
-``From`` 行是信體裏的最上面一行，具有如下格式::
+``From`` 行必須是信體裡的最上面一行，具有如下格式::
 
         From: Patch Author <author@example.com>
 
-``From`` 行指明在永久改動日誌裏，誰會被確認爲作者。如果沒有 ``From`` 行，那
-麼郵件頭裏的 ``From:`` 行會被用來決定改動日誌中的作者。
+``From`` 行指明在永久改動日誌裡，誰會被確認為作者。如果沒有 ``From`` 行，那
+麼郵件頭裡的 ``From:`` 行會被用來決定改動日誌中的作者。
 
-說明文字將會被提交到永久的源代碼改動日誌裏，因此應針對那些早已經不記得和這
-個補丁相關的討論細節的讀者。包括補丁處理的故障症狀（內核日誌消息、oops消息
-等），這對於可能正在搜索提交日誌以查找適用補丁的人特別有用。文本應該寫得如
-此詳細，以便在數週、數月甚至數年後閱讀時，能夠爲讀者提供所需的細節信息，以
-掌握創建補丁的 **原因** 。
+作者可以透過在 ``from`` 行和 ``SoB`` 行中加上組織名稱，來表明其所屬單位
+或工作的贊助者，例如：
+
+	From: Patch Author (Company) <author@example.com>
+
+說明主體
+^^^^^^^^
+
+說明文字將會被提交到永久的原始程式碼改動日誌裡，因此應針對那些早已經不記得和這
+個補丁相關的討論細節的讀者。包括補丁處理的故障症狀（核心日誌訊息、oops訊息
+等），這對於可能正在搜索提交日誌以查找適用補丁的人特別有用。文字應該寫得如
+此詳細，以便在數週、數月甚至數年後閱讀時，能夠為讀者提供所需的細節資訊，以
+掌握建立補丁的 **原因** 。
 
 如果一個補丁修復了一個編譯失敗，那麼可能不需要包含 *所有* 編譯失敗；
 只要足夠讓搜索補丁的人能夠找到它就行了。與概述一樣，既要簡潔又要描述性。
 
-``---`` 標記行對於補丁處理工具要找到哪裏是改動日誌信息的結束，是不可缺少
+
+.. _tw_backtraces:
+
+提交訊息中的回溯（Backtraces）
+""""""""""""""""""""""""""""""
+
+回溯有助於記錄導致問題的呼叫鏈。然而，並非所有回溯都有幫助。例如，早期引導呼
+叫鏈是獨特而明顯的。而逐字複製完整的dmesg輸出則會增加時間戳、模組列表、暫存
+器和堆疊轉儲等分散注意力的資訊。
+
+因此，最有用的回溯應該從轉儲中提取相關資訊，以更容易集中在真實問題上。下面是
+一個剪裁良好的回溯範例::
+
+  unchecked MSR access error: WRMSR to 0xd51 (tried to write 0x0000000000000064)
+  at rIP: 0xffffffffae059994 (native_write_msr+0x4/0x20)
+  Call Trace:
+  mba_wrmsr
+  update_domains
+  rdtgroup_mkdir
+
+附加註解（Commentary）
+^^^^^^^^^^^^^^^^^^^^^^
+
+``---`` 標記行對於補丁處理工具要找到哪裡是改動日誌資訊的結束，是不可缺少
 的。
 
-對於 ``---`` 標記之後的額外註解，一個好的用途就是用來寫 ``diffstat`` ，用來顯
-示修改了什麼文件和每個文件都增加和刪除了多少行。 ``diffstat`` 對於比較大的補
-丁特別有用。
-使用 ``diffstat`` 的選項 ``-p 1 -w 70`` 這樣文件名就會從內核源代碼樹的目錄開始
-，不會佔用太寬的空間（很容易適合80列的寬度，也許會有一些縮進。）
-（ ``git`` 默認會生成合適的diffstat。）
+對於 ``---`` 標記之後的額外註解，一個好的用途就是用來寫 ``diffstat`` ，用
+來顯示修改了什麼檔案和每個檔案都增加和刪除了多少行。 ``diffstat`` 對於比較
+大的補丁特別有用。使用 ``diffstat`` 的選項 ``-p 1 -w 70`` 這樣檔名就會從核
+心原始程式碼樹的目錄開始，不會佔用太寬的空間（很容易適合80列的寬度，也許會
+有一些縮排。）（ ``git`` 預設會產生合適的diffstat。）
 
-其餘那些只適用於當時或者與維護者相關的註解，不合適放到永久的改動日誌裏的，也
-應該放這裏。較好的例子就是 ``補丁更改記錄`` ，記錄了v1和v2版本補丁之間的差異。
+其餘那些只適用於當時或者與維護者相關的註解，不合適放到永久的改動日誌裡的，也
+應該放這裡。較好的例子就是 ``補丁更改記錄`` ，記錄了v1和v2版本補丁之間的差異。
 
-請將此信息放在將變更日誌與補丁的其餘部分分隔開的 ``---`` 行 **之後** 。版本
-信息不是提交到git樹的變更日誌的一部分。只是供審閱人員使用的附加信息。如果將
+請將此資訊放在將變更日誌與補丁的其餘部分分隔開的 ``---`` 行 **之後** 。版本
+資訊不是提交到git樹的變更日誌的一部分。只是供審閱人員使用的附加資訊。如果將
 其放置在提交標記上方，則需要手動交互才能將其刪除。如果它位於分隔線以下，則在
-應用補丁時會自動剝離::
+應用補丁時會自動剝離。如果可以，建議附上指向該補丁先前版本的連結（例如
+lore.kernel.org存檔連結），以幫助審閱者::
 
   <commit message>
   ...
@@ -545,29 +650,14 @@ Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定�
   V2 -> V3: Removed redundant helper function
   V1 -> V2: Cleaned up coding style and addressed review comments
 
+  v2: https://lore.kernel.org/bar
+  v1: https://lore.kernel.org/foo
+
   path/to/file | 5+++--
   ...
 
 在後面的參考資料中能看到正確補丁格式的更多細節。
 
-.. _tw_backtraces:
-
-提交消息中的回溯（Backtraces）
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-回溯有助於記錄導致問題的調用鏈。然而，並非所有回溯都有幫助。例如，早期引導調
-用鏈是獨特而明顯的。而逐字複製完整的dmesg輸出則會增加時間戳、模塊列表、寄存
-器和堆棧轉儲等分散注意力的信息。
-
-因此，最有用的回溯應該從轉儲中提取相關信息，以更容易集中在真實問題上。下面是
-一個剪裁良好的回溯示例::
-
-  unchecked MSR access error: WRMSR to 0xd51 (tried to write 0x0000000000000064)
-  at rIP: 0xffffffffae059994 (native_write_msr+0x4/0x20)
-  Call Trace:
-  mba_wrmsr
-  update_domains
-  rdtgroup_mkdir
 
 .. _tw_explicit_in_reply_to:
 
@@ -575,21 +665,21 @@ Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定�
 -----------------------------
 
 手動添加回復補丁的的郵件頭（In-Reply_To:）是有用的（例如，使用 ``git send-email`` ），
-可以將補丁與以前的相關討論關聯起來，例如，將bug補丁鏈接到電子郵件和bug報告。
-但是，對於多補丁系列，最好避免在回覆時使用鏈接到該系列的舊版本。這樣，
-補丁的多個版本就不會成爲電子郵件客戶端中無法管理的引用樹。如果鏈接有用，
-可以使用 https://lore.kernel.org/ 重定向器（例如，在封面電子郵件文本中）
-鏈接到補丁系列的早期版本。
+可以將補丁與以前的相關討論關聯起來，例如，將bug補丁連結到電子郵件和bug報告。
+但是，對於多補丁系列，最好避免在回覆時使用連結到該系列的舊版本。這樣，
+補丁的多個版本就不會成為電子郵件客戶端中無法管理的引用樹。如果連結有用，
+可以使用 https://lore.kernel.org/ 重定向器（例如，在封面電子郵件文字中）
+連結到補丁系列的早期版本。
 
-給出基礎樹信息
+給出基礎樹資訊
 --------------
 
-當其他開發人員收到您的補丁並開始審閱時，知道應該將您的工作放到代碼樹歷史記錄
-中的什麼位置通常很有用。這對於自動化持續集成流水（CI）特別有用，這些流水線試
-圖運行一系列測試，以便在維護人員開始審閱之前確定提交的質量。
+當其他開發人員收到您的補丁並開始審閱時，知道應該將您的工作放到程式碼樹歷史記錄
+中的什麼位置通常很有用。這對於自動化持續整合流水（CI）特別有用，這些流水線試
+圖執行一系列測試，以便在維護人員開始審閱之前確定提交的品質。
 
-如果您使用 ``git format-patch`` 生成補丁，則可以通過 ``--base`` 標誌在提交中
-自動包含基礎樹信息。使用此選項最簡單、最方便的方法是配合主題分支::
+如果您使用 ``git format-patch`` 產生補丁，則可以透過 ``--base`` 標誌在提交中
+自動包含基礎樹資訊。使用此選項最簡單、最方便的方法是配合主題分支::
 
     $ git checkout -t -b my-topical-branch master
     Branch 'my-topical-branch' set up to track local branch 'master'.
@@ -603,7 +693,7 @@ Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定�
     outgoing/...
 
 當你編輯 ``outgoing/0000-cover-letter.patch`` 時，您會注意到在它的最底部有一
-行 ``base-commit:`` 尾註，它爲審閱者和CI工具提供了足夠的信息以正確執行
+行 ``base-commit:`` 尾註，它為審閱者和CI工具提供了足夠的資訊以正確執行
 ``git am`` 而不必擔心衝突::
 
     $ git checkout -b patch-review [base-commit-id]
@@ -612,7 +702,7 @@ Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定�
     Applying: First Commit
     Applying: ...
 
-有關此選項的更多信息，請參閱 ``man git-format-patch`` 。
+有關此選項的更多資訊，請參閱 ``man git-format-patch`` 。
 
 .. note::
 
@@ -622,16 +712,23 @@ Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定�
 的工作所基於的樹的提交哈希。你應該在封面郵件或系列的第一個補丁中添加它，它應
 該放在 ``---`` 行的下面或所有其他內容之後，即只在你的電子郵件簽名之前。
 
+工具
+----
+
+此流程的許多技術層面都可以使用b4自動化，其說明文件見
+<https://b4.docs.kernel.org/en/latest/>。它可以幫助追蹤依賴關係、執行
+checkpatch，以及格式化和發送郵件。
+
 參考文獻
 --------
 
 Andrew Morton，“完美的補丁”（tpp）
   <https://www.ozlabs.org/~akpm/stuff/tpp.txt>
 
-Jeff Garzik，“Linux內核補丁提交格式”
+Jeff Garzik，“Linux核心補丁提交格式”
   <https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html>
 
-Greg Kroah-Hartman，“如何惹惱內核子系統維護人員”
+Greg Kroah-Hartman，“如何惹惱核心子系統維護人員”
   <http://www.kroah.com/log/linux/maintainer.html>
 
   <http://www.kroah.com/log/linux/maintainer-02.html>
@@ -644,10 +741,7 @@ Greg Kroah-Hartman，“如何惹惱內核子系統維護人員”
 
   <http://www.kroah.com/log/linux/maintainer-06.html>
 
-不！！！別再發巨型補丁炸彈給linux-kernel@vger.kernel.org的人們了！
-  <https://lore.kernel.org/r/20050711.125305.08322243.davem@davemloft.net>
-
-內核 Documentation/translations/zh_CN/process/coding-style.rst
+核心 Documentation/translations/zh_TW/process/coding-style.rst
 
 Linus Torvalds關於標準補丁格式的郵件
   <https://lore.kernel.org/r/Pine.LNX.4.58.0504071023190.28951@ppc970.osdl.org>
diff --git a/Documentation/userspace-api/dma-buf-heaps.rst b/Documentation/userspace-api/dma-buf-heaps.rst
index f56b743cdb36..92099188893e 100644
--- a/Documentation/userspace-api/dma-buf-heaps.rst
+++ b/Documentation/userspace-api/dma-buf-heaps.rst
@@ -36,7 +36,7 @@ following heaps:
  - A heap will be created for each reusable region in the device tree
    with the ``shared-dma-pool`` compatible, using the full device tree
    node name as its name. The buffer semantics are identical to
-   ``default-cma-region``.
+   ``default_cma_region``.
 
 Naming Convention
 =================
diff --git a/Documentation/userspace-api/futex2.rst b/Documentation/userspace-api/futex2.rst
index 9693f47a7e62..615616305c57 100644
--- a/Documentation/userspace-api/futex2.rst
+++ b/Documentation/userspace-api/futex2.rst
@@ -51,10 +51,10 @@ future extension.
 
 For each entry in ``waiters`` array, the current value at ``uaddr`` is compared
 to ``val``. If it's different, the syscall undo all the work done so far and
-return ``-EAGAIN``. If all tests and verifications succeeds, syscall waits until
+return ``-EWOULDBLOCK``. If all tests and verifications succeeds, syscall waits until
 one of the following happens:
 
-- The timeout expires, returning ``-ETIMEOUT``.
+- The timeout expires, returning ``-ETIMEDOUT``.
 - A signal was sent to the sleeping task, returning ``-ERESTARTSYS``.
 - Some futex at the list was woken, returning the index of some waked futex.
 
diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst
index 2fc53093752d..35f495bc54f7 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -181,8 +181,9 @@ Code  Seq#    Include File                                             Comments
 'M'   01-03  drivers/scsi/megaraid/megaraid_sas.h
 'M'   00-0F  drivers/video/fsl-diu-fb.h                                conflict!
 'N'   00-1F  drivers/usb/scanner.h
-'N'   40-7F  drivers/block/nvme.c
-'N'   80-8F  uapi/linux/ntsync.h                                       NT synchronization primitives
+'N'   40-7F  uapi/linux/nvme_ioctl.h
+'N'   80-83  uapi/linux/ntsync.h and uapi/linux/nvme_ioctl.h           conflict!
+'N'   84-8F  uapi/linux/ntsync.h                                       NT synchronization primitives
                                                                        <mailto:wine-devel@winehq.org>
 'O'   00-06  mtd/ubi-user.h                                            UBI
 'P'   all    linux/soundcard.h                                         conflict!
@@ -399,7 +400,7 @@ Code  Seq#    Include File                                             Comments
 0xDD  00-3F                                                            ZFCP device driver see drivers/s390/scsi/
                                                                        <mailto:aherrman@de.ibm.com>
 0xE5  00-3F  linux/fuse.h
-0xEC  00-01  drivers/platform/chrome/cros_ec_dev.h                     ChromeOS EC driver
+0xEC  00-01  linux/platform_data/cros_ec_chardev.h                     ChromeOS EC driver
 0xEE  00-09  uapi/linux/pfrut.h                                        Platform Firmware Runtime Update and Telemetry
 0xF3  00-3F  drivers/usb/misc/sisusbvga/sisusb.h                       sisfb (in development)
                                                                        <mailto:thomas@winischhofer.net>
diff --git a/Documentation/userspace-api/iommufd.rst b/Documentation/userspace-api/iommufd.rst
index f1c4d21e5c5e..763b23339480 100644
--- a/Documentation/userspace-api/iommufd.rst
+++ b/Documentation/userspace-api/iommufd.rst
@@ -242,7 +242,7 @@ creating the objects and links::
 
       Either a manual IOMMUFD_OBJ_HWPT_PAGING or an IOMMUFD_OBJ_HWPT_NESTED is
       created via the same IOMMU_HWPT_ALLOC uAPI. The difference is at the type
-      of the object passed in via the @pt_id field of struct iommufd_hwpt_alloc.
+      of the object passed in via the @pt_id field of struct iommu_hwpt_alloc.
 
 5. IOMMUFD_OBJ_VIOMMU can be only manually created via the IOMMU_VIOMMU_ALLOC
    uAPI, provided a dev_id (for the device's physical IOMMU to back the vIOMMU)
diff --git a/Documentation/userspace-api/vduse.rst b/Documentation/userspace-api/vduse.rst
index 81479d47c8b9..d316857ca5bd 100644
--- a/Documentation/userspace-api/vduse.rst
+++ b/Documentation/userspace-api/vduse.rst
@@ -11,11 +11,10 @@ to make the device emulation more secure, the emulated vDPA device's
 control path is handled in the kernel and only the data path is
 implemented in the userspace.
 
-Note that only virtio block device is supported by VDUSE framework now,
-which can reduce security risks when the userspace process that implements
-the data path is run by an unprivileged user. The support for other device
-types can be added after the security issue of corresponding device driver
-is clarified or fixed in the future.
+Note that virtio block, network, and filesystem device types are supported
+by the VDUSE framework. Other device types may be added after the security
+implications of the corresponding device driver are clarified or fixed in
+the future.
 
 Create/Destroy VDUSE devices
 ----------------------------
@@ -135,7 +134,8 @@ module as follows:
 		return 0;
 	}
 
-There are now three types of messages introduced by VDUSE framework:
+The following control message types may be delivered via read(2) on
+/dev/vduse/$NAME:
 
 - VDUSE_GET_VQ_STATE: Get the state for virtqueue, userspace should return
   avail index for split virtqueue or the device/driver ring wrap counters and
@@ -151,6 +151,15 @@ There are now three types of messages introduced by VDUSE framework:
   IOVA range, userspace should firstly remove the old mapping, then setup the new
   mapping via the VDUSE_IOTLB_GET_FD ioctl.
 
+- VDUSE_SET_VQ_GROUP_ASID: Notify userspace to change the address space of a
+  virtqueue group (API version 1).
+
+- VDUSE_SET_VQ_READY: Notify userspace that a virtqueue should become ready or
+  not ready (when VDUSE_F_QUEUE_READY is negotiated).
+
+- VDUSE_SUSPEND: Notify userspace that the device is being suspended (when
+  VDUSE_F_SUSPEND is negotiated).
+
 After DRIVER_OK status bit is set via the VDUSE_SET_STATUS message, userspace is
 able to start the dataplane processing as follows:
 
@@ -227,7 +236,7 @@ able to start the dataplane processing as follows:
    described by the descriptors in the descriptor table should be also mapped into
    userspace via the VDUSE_IOTLB_GET_FD ioctl before accessing.
 
-5. Inject an interrupt for specific virtqueue with the VDUSE_INJECT_VQ_IRQ ioctl
+5. Inject an interrupt for specific virtqueue with the VDUSE_VQ_INJECT_IRQ ioctl
    after the used ring is filled.
 
 Enabling ASID (API version 1)
@@ -238,11 +247,11 @@ version 1. Set it up with ioctl(VDUSE_SET_API_VERSION) on `/dev/vduse/control`
 and pass `VDUSE_API_VERSION_1` before creating a new VDUSE instance with
 ioctl(VDUSE_CREATE_DEV).
 
-Afterwards, you can use the member asid of ioctl(VDUSE_VQ_SETUP) argument to
-select the address space of the IOTLB you are querying.  The driver could
-change the address space of any virtqueue group by using the
-VDUSE_SET_VQ_GROUP_ASID VDUSE message type, and the VDUSE instance needs to
-reply with VDUSE_REQ_RESULT_OK if it was possible to change it.
+Afterwards, ioctl(VDUSE_VQ_SETUP) takes a virtqueue group index in
+struct vduse_vq_config::group.  The driver can change the address space
+of any virtqueue group by using the VDUSE_SET_VQ_GROUP_ASID message type,
+and the VDUSE instance needs to reply with VDUSE_REQ_RESULT_OK if it was
+possible to change it.
 
 Similarly, you can use ioctl(VDUSE_IOTLB_GET_FD2) to obtain the file descriptor
 describing an IOVA region of a specific ASID. Example usage:
diff --git a/Documentation/virt/coco/sev-guest.rst b/Documentation/virt/coco/sev-guest.rst
index 93debceb6eb0..3371ebc29e8b 100644
--- a/Documentation/virt/coco/sev-guest.rst
+++ b/Documentation/virt/coco/sev-guest.rst
@@ -38,7 +38,7 @@ along with a description:
       are not detailed, but errors with specific meanings are.
 
 The guest ioctl should be issued on a file descriptor of the /dev/sev-guest
-device.  The ioctl accepts struct snp_user_guest_request. The input and
+device.  The ioctl accepts struct snp_guest_request_ioctl. The input and
 output structure is specified through the req_data and resp_data field
 respectively. If the ioctl fails to execute due to a firmware error, then
 the fw_error code will be set, otherwise fw_error will be set to -1.