docs/zh_TW: update contents for zh_TW

The content of zh_TW was too outdated comparing to the original files.
Consequently carry out improvements in order to both keep track of sources
and fix several grammatical mistakes in traditional Chinese.

This is a thorough rewrite of the previous patch:
    https://lore.kernel.org/linux-doc/20230807120006.6361-1-src.res.211@gmail.com/
in order to get rid of text damage and merging errors, created based on
linux-next (date: Oct. 9, 2023).
Signed-off-by: Hu Haowen <src.res.211@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20231011051212.17580-1-src.res.211@gmail.com

Documentation/translations/zh_TW/admin-guide/bootconfig.rst

+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../disclaimer-zh_TW.rst
+
+:Original: Documentation/admin-guide/bootconfig.rst
+
+:譯者: 吳想成 Wu XiangCheng <bobwxc@email.cn>
+
+========
+引導配置
+========
+
+:作者: Masami Hiramatsu <mhiramat@kernel.org>
+
+概述
+====
+
+引導配置擴展了現有的內核命令行，以一種更有效率的方式在引導內核時進一步支持
+鍵值數據。這允許管理員傳遞一份結構化關鍵字的配置文件。
+
+配置文件語法
+============
+
+引導配置文件的語法採用非常簡單的鍵值結構。每個關鍵字由點連接的單詞組成，鍵
+和值由 ``=`` 連接。值以分號（ ``;`` ）或換行符（ ``\n`` ）結尾。數組值中每
+個元素由逗號（ ``,`` ）分隔。::
+
+  KEY[.WORD[...]] = VALUE[, VALUE2[...]][;]
+
+與內核命令行語法不同，逗號和 ``=`` 周圍允許有空格。
+
+關鍵字只允許包含字母、數字、連字符（ ``-`` ）和下劃線（ ``_`` ）。值可包含
+可打印字符和空格，但分號（ ``;`` ）、換行符（ ``\n`` ）、逗號（ ``,`` ）、
+井號（ ``#`` ）和右大括號（ ``}`` ）等分隔符除外。
+
+如果你需要在值中使用這些分隔符，可以用雙引號（ ``"VALUE"`` ）或單引號
+（ ``'VALUE'`` ）括起來。注意，引號無法轉義。
+
+鍵的值可以爲空或不存在。這些鍵用於檢查該鍵是否存在（類似布爾值）。
+
+鍵值語法
+--------
+
+引導配置文件語法允許用戶通過大括號合併鍵名部分相同的關鍵字。例如::
+
+ foo.bar.baz = value1
+ foo.bar.qux.quux = value2
+
+也可以寫成::
+
+ foo.bar {
+    baz = value1
+    qux.quux = value2
+ }
+
+或者更緊湊一些，寫成::
+
+ foo.bar { baz = value1; qux.quux = value2 }
+
+在這兩種樣式中，引導解析時相同的關鍵字都會自動合併。因此可以追加類似的樹或
+鍵值。
+
+相同關鍵字的值
+--------------
+
+禁止兩個或多個值或數組共享同一個關鍵字。例如::
+
+ foo = bar, baz
+ foo = qux  # !錯誤! 我們不可以重定義相同的關鍵字
+
+如果你想要更新值，必須顯式使用覆蓋操作符 ``:=`` 。例如::
+
+ foo = bar, baz
+ foo := qux
+
+這樣 ``foo`` 關鍵字的值就變成了 ``qux`` 。這對於通過添加（部分）自定義引導
+配置來覆蓋默認值非常有用，免於解析默認引導配置。
+
+如果你想對現有關鍵字追加值作爲數組成員，可以使用 ``+=`` 操作符。例如::
+
+ foo = bar, baz
+ foo += qux
+
+這樣， ``foo`` 關鍵字就同時擁有了 ``bar`` ， ``baz`` 和 ``qux`` 。
+
+此外，父關鍵字下可同時存在值和子關鍵字。
+例如，下列配置是可行的。::
+
+ foo = value1
+ foo.bar = value2
+ foo := value3 # 這會更新foo的值。
+
+注意，裸值不能直接放進結構化關鍵字中，必須在大括號外定義它。例如::
+
+ foo {
+     bar = value1
+     bar {
+         baz = value2
+         qux = value3
+     }
+ }
+
+同時，關鍵字下值節點的順序是固定的。如果值和子關鍵字同時存在，值永遠是該關
+鍵字的第一個子節點。因此如果用戶先指定子關鍵字，如::
+
+ foo.bar = value1
+ foo = value2
+
+則在程序（和/proc/bootconfig）中，它會按如下顯示::
+
+ foo = value2
+ foo.bar = value1
+
+註釋
+----
+
+配置語法接受shell腳本風格的註釋。註釋以井號（ ``#`` ）開始，到換行符
+（ ``\n`` ）結束。
+
+::
+
+ # comment line
+ foo = value # value is set to foo.
+ bar = 1, # 1st element
+       2, # 2nd element
+       3  # 3rd element
+
+會被解析爲::
+
+ foo = value
+ bar = 1, 2, 3
+
+注意你不能把註釋放在值和分隔符（ ``,`` 或 ``;`` ）之間。如下配置語法是錯誤的::
+
+ key = 1 # comment
+       ,2
+
+
+/proc/bootconfig
+================
+
+/proc/bootconfig是引導配置的用戶空間接口。與/proc/cmdline不同，此文件內容以
+鍵值列表樣式顯示。
+每個鍵值對一行，樣式如下::
+
+ KEY[.WORDS...] = "[VALUE]"[,"VALUE2"...]
+
+
+用引導配置引導內核
+==================
+
+用引導配置引導內核有兩種方法：將引導配置附加到initrd鏡像或直接嵌入內核中。
+
+*initrd: initial RAM disk，初始內存磁盤*
+
+將引導配置附加到initrd
+----------------------
+
+由於默認情況下引導配置文件是用initrd加載的，因此它將被添加到initrd（initramfs）
+鏡像文件的末尾，其中包含填充、大小、校驗值和12字節幻數，如下所示::
+
+ [initrd][bootconfig][padding][size(le32)][checksum(le32)][#BOOTCONFIG\n]
+
+大小和校驗值爲小端序存放的32位無符號值。
+
+當引導配置被加到initrd鏡像時，整個文件大小會對齊到4字節。空字符（ ``\0`` ）
+會填補對齊空隙。因此 ``size`` 就是引導配置文件的長度+填充的字節。
+
+Linux內核在內存中解碼initrd鏡像的最後部分以獲取引導配置數據。由於這種“揹負式”
+的方法，只要引導加載器傳遞了正確的initrd文件大小，就無需更改或更新引導加載器
+和內核鏡像本身。如果引導加載器意外傳遞了更長的大小，內核將無法找到引導配置數
+據。
+
+Linux內核在tools/bootconfig下提供了 ``bootconfig`` 命令來完成此操作，管理員
+可以用它從initrd鏡像中刪除或追加配置文件。你可以用以下命令來構建它::
+
+ # make -C tools/bootconfig
+
+要向initrd鏡像添加你的引導配置文件，請按如下命令操作（舊數據會自動移除）::
+
+ # tools/bootconfig/bootconfig -a your-config /boot/initrd.img-X.Y.Z
+
+要從鏡像中移除配置，可以使用-d選項::
+
+ # tools/bootconfig/bootconfig -d /boot/initrd.img-X.Y.Z
+
+然後在內核命令行上添加 ``bootconfig`` 告訴內核去initrd文件末尾尋找內核配置。
+
+將引導配置嵌入內核
+------------------
+
+如果你不能使用initrd，也可以通過Kconfig選項將引導配置文件嵌入內核中。在此情
+況下，你需要用以下選項重新編譯內核::
+
+ CONFIG_BOOT_CONFIG_EMBED=y
+ CONFIG_BOOT_CONFIG_EMBED_FILE="/引導配置/文件/的/路徑"
+
+``CONFIG_BOOT_CONFIG_EMBED_FILE`` 需要從源碼樹或對象樹開始的引導配置文件的
+絕對/相對路徑。內核會將其嵌入作爲默認引導配置。
+
+與將引導配置附加到initrd一樣，你也需要在內核命令行上添加 ``bootconfig`` 告訴
+內核去啓用內嵌的引導配置。
+
+注意，即使你已經設置了此選項，仍可用附加到initrd的其他引導配置覆蓋內嵌的引導
+配置。
+
+通過引導配置傳遞內核參數
+========================
+
+除了內核命令行，引導配置也可以用於傳遞內核參數。所有 ``kernel`` 關鍵字下的鍵
+值對都將直接傳遞給內核命令行。此外， ``init`` 下的鍵值對將通過命令行傳遞給
+init進程。參數按以下順序與用戶給定的內核命令行字符串相連，因此命令行參數可以
+覆蓋引導配置參數（這取決於子系統如何處理參數，但通常前面的參數將被後面的參數
+覆蓋）::
+
+ [bootconfig params][cmdline params] -- [bootconfig init params][cmdline init params]
+
+如果引導配置文件給出的kernel/init參數是::
+
+ kernel {
+   root = 01234567-89ab-cdef-0123-456789abcd
+ }
+ init {
+  splash
+ }
+
+這將被複制到內核命令行字符串中，如下所示::
+
+ root="01234567-89ab-cdef-0123-456789abcd" -- splash
+
+如果用戶給出的其他命令行是::
+
+ ro bootconfig -- quiet
+
+則最後的內核命令行如下::
+
+ root="01234567-89ab-cdef-0123-456789abcd" ro bootconfig -- splash quiet
+
+
+配置文件的限制
+==============
+
+當前最大的配置大小是32KB，關鍵字總數（不是鍵值條目）必須少於1024個節點。
+注意：這不是條目數而是節點數，條目必須消耗超過2個節點（一個關鍵字和一個值）。
+所以從理論上講最多512個鍵值對。如果關鍵字平均包含3個單詞，則可有256個鍵值對。
+在大多數情況下，配置項的數量將少於100個條目，小於8KB，因此這應該足夠了。如果
+節點數超過1024，解析器將返回錯誤，即使文件大小小於32KB。（請注意，此最大尺寸
+不包括填充的空字符。）
+無論如何，因爲 ``bootconfig`` 命令在附加啓動配置到initrd映像時會驗證它，用戶
+可以在引導之前注意到它。
+
+
+引導配置API
+===========
+
+用戶可以查詢或遍歷鍵值對，也可以查找（前綴）根關鍵字節點，並在查找該節點下的
+鍵值。
+
+如果您有一個關鍵字字符串，則可以直接使用 xbc_find_value() 查詢該鍵的值。如果
+你想知道引導配置裏有哪些關鍵字，可以使用 xbc_for_each_key_value() 迭代鍵值對。
+請注意，您需要使用 xbc_array_for_each_value() 訪問數組的值，例如::
+
+ vnode = NULL;
+ xbc_find_value("key.word", &vnode);
+ if (vnode && xbc_node_is_array(vnode))
+    xbc_array_for_each_value(vnode, value) {
+      printk("%s ", value);
+    }
+
+如果您想查找具有前綴字符串的鍵，可以使用 xbc_find_node() 通過前綴字符串查找
+節點，然後用 xbc_node_for_each_key_value() 迭代前綴節點下的鍵。
+
+但最典型的用法是獲取前綴下的命名值或前綴下的命名數組，例如::
+
+ root = xbc_find_node("key.prefix");
+ value = xbc_node_find_value(root, "option", &vnode);
+ ...
+ xbc_node_for_each_array_value(root, "array-option", value, anode) {
+    ...
+ }
+
+這將訪問值“key.prefix.option”的值和“key.prefix.array-option”的數組。
+
+鎖是不需要的，因爲在初始化之後配置只讀。如果需要修改，必須複製所有數據和關鍵字。
+
+
+函數與結構體
+============
+
+相關定義的kernel-doc參見：
+
+ - include/linux/bootconfig.h
+ - lib/bootconfig.c
+

Documentation/translations/zh_TW/admin-guide/bug-bisect.rst

@@ -17,14 +17,14 @@
 引言
 =====
 
-始終嘗試由來自kernel.org的原始碼構建的最新內核。如果您沒有信心這樣做，請將
+始終嘗試由來自kernel.org的源代碼構建的最新內核。如果您沒有信心這樣做，請將
 錯誤報告給您的發行版供應商，而不是內核開發人員。
 
 找到缺陷（bug）並不總是那麼容易，不過仍然得去找。如果你找不到它，不要放棄。
-儘可能多的向相關維護人員報告您發現的信息。請參閱MAINTAINERS文件以了解您所
+儘可能多的向相關維護人員報告您發現的信息。請參閱MAINTAINERS文件以瞭解您所
 關注的子系統的維護人員。
 
-在提交錯誤報告之前，請閱讀「Documentation/admin-guide/reporting-issues.rst」。
+在提交錯誤報告之前，請閱讀“Documentation/admin-guide/reporting-issues.rst”。
 
 設備未出現（Devices not appearing）
 ====================================
@@ -38,7 +38,7 @@
 
 操作步驟：
 
-- 從git原始碼構建內核
+- 從git源代碼構建內核
 - 以此開始二分 [#f1]_::
 
 	$ git bisect start
@@ -76,7 +76,7 @@
 如需進一步參考，請閱讀：
 
 - ``git-bisect`` 的手冊頁
-- `Fighting regressions with git bisect（用git bisect解決回歸）
+- `Fighting regressions with git bisect（用git bisect解決迴歸）
   <https://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html>`_
 - `Fully automated bisecting with "git bisect run"（使用git bisect run
   來全自動二分） <https://lwn.net/Articles/317154>`_

Documentation/translations/zh_TW/admin-guide/bug-hunting.rst

@@ -48,8 +48,8 @@
 	 [<c1549f43>] ? sysenter_past_esp+0x40/0x6a
 	---[ end trace 6ebc60ef3981792f ]---
 
-這樣的堆棧跟蹤提供了足夠的信息來識別內核原始碼中發生錯誤的那一行。根據問題的
-嚴重性，它還可能包含 **「Oops」** 一詞，比如::
+這樣的堆棧跟蹤提供了足夠的信息來識別內核源代碼中發生錯誤的那一行。根據問題的
+嚴重性，它還可能包含 **“Oops”** 一詞，比如::
 
 	BUG: unable to handle kernel NULL pointer dereference at   (null)
 	IP: [<c06969d4>] iret_exc+0x7d0/0xa59
@@ -58,17 +58,17 @@
 	...
 
 儘管有 **Oops** 或其他類型的堆棧跟蹤，但通常需要找到出問題的行來識別和處理缺
-陷。在本章中，我們將參考「Oops」來了解需要分析的各種堆棧跟蹤。
+陷。在本章中，我們將參考“Oops”來了解需要分析的各種堆棧跟蹤。
 
 如果內核是用 ``CONFIG_DEBUG_INFO`` 編譯的，那麼可以使用文件：
 `scripts/decode_stacktrace.sh` 。
 
-連結的模塊
+鏈接的模塊
 -----------
 
-受到汙染或正在加載/卸載的模塊用「（…）」標記，汙染標誌在
-`Documentation/admin-guide/tainted-kernels.rst` 文件中進行了描述，「正在被加
-載」用「+」標註，「正在被卸載」用「-」標註。
+受到污染或正在加載/卸載的模塊用“（…）”標記，污染標誌在
+`Documentation/admin-guide/tainted-kernels.rst` 文件中進行了描述，“正在被加
+載”用“+”標註，“正在被卸載”用“-”標註。
 
 
 Oops消息在哪？
@@ -81,19 +81,19 @@ syslog文件，通常是 ``/var/log/messages`` （取決於 ``/etc/syslog.conf``
 
 有時 ``klogd`` 會掛掉，這種情況下您可以運行 ``dmesg > file`` 從內核緩衝區
 讀取數據並保存它。或者您可以 ``cat /proc/kmsg > file`` ，但是您必須適時
-中斷以停止傳輸，因爲 ``kmsg`` 是一個「永無止境的文件」。
+中斷以停止傳輸，因爲 ``kmsg`` 是一個“永無止境的文件”。
 
-如果機器嚴重崩潰，無法輸入命令或磁碟不可用，那還有三個選項：
+如果機器嚴重崩潰，無法輸入命令或磁盤不可用，那還有三個選項：
 
 (1) 手動複製屏幕上的文本，並在機器重新啓動後輸入。很難受，但這是突然崩潰下
-    唯一的選擇。或者你可以用數位相機拍下屏幕——雖然不那麼好，但總比什麼都沒
-    有好。如果消息滾動超出控制台頂部，使用更高解析度（例如 ``vga=791`` ）
-    引導啓動將允許您閱讀更多文本。（警告：這需要 ``vesafb`` ，因此對「早期」
+    唯一的選擇。或者你可以用數碼相機拍下屏幕——雖然不那麼好，但總比什麼都沒
+    有好。如果消息滾動超出控制檯頂部，使用更高分辨率（例如 ``vga=791`` ）
+    引導啓動將允許您閱讀更多文本。（警告：這需要 ``vesafb`` ，因此對“早期”
     的Oppses沒有幫助）
 
 (2) 從串口終端啓動（參見
     :ref:`Documentation/admin-guide/serial-console.rst <serial_console>` ），
-    在另一台機器上運行數據機然後用你喜歡的通信程序捕獲輸出。
+    在另一臺機器上運行調制解調器然後用你喜歡的通信程序捕獲輸出。
     Minicom運行良好。
 
 (3) 使用Kdump（參閱 Documentation/admin-guide/kdump/kdump.rst ），使用
@@ -103,7 +103,7 @@ syslog文件，通常是 ``/var/log/messages`` （取決於 ``/etc/syslog.conf``
 找到缺陷位置
 -------------
 
-如果你能指出缺陷在內核原始碼中的位置，則報告缺陷的效果會非常好。這有兩種方法。
+如果你能指出缺陷在內核源代碼中的位置，則報告缺陷的效果會非常好。這有兩種方法。
 通常來說使用 ``gdb`` 會比較容易，不過內核需要用調試信息來預編譯。
 
 gdb
@@ -187,7 +187,7 @@ GNU 調試器（GNU debugger， ``gdb`` ）是從 ``vmlinux`` 文件中找出OOP
 objdump
 ^^^^^^^^
 
-要調試內核，請使用objdump並從崩潰輸出中查找十六進位偏移，以找到有效的代碼/匯
+要調試內核，請使用objdump並從崩潰輸出中查找十六進制偏移，以找到有效的代碼/匯
 編行。如果沒有調試符號，您將看到所示例程的彙編程序代碼，但是如果內核有調試
 符號，C代碼也將可見（調試符號可以在內核配置菜單的hacking項中啓用）。例如::
 
@@ -197,7 +197,7 @@ objdump
 
    您需要處於內核樹的頂層以便此獲得您的C文件。
 
-如果您無法訪問原始碼，仍然可以使用以下方法調試一些崩潰轉儲（如Dave Miller的
+如果您無法訪問源代碼，仍然可以使用以下方法調試一些崩潰轉儲（如Dave Miller的
 示例崩潰轉儲輸出所示）::
 
      EIP is at 	+0x14/0x4c0
@@ -234,9 +234,9 @@ objdump
 報告缺陷
 ---------
 
-一旦你通過定位缺陷找到了其發生的地方，你可以嘗試自己修復它或者向上游報告它。
+一旦你通過定位缺陷找到了其發生的地方，你可以嘗試自己修復它或者向上遊報告它。
 
-爲了向上游報告，您應該找出用於開發受影響代碼的郵件列表。這可以使用 ``get_maintainer.pl`` 。
+爲了向上遊報告，您應該找出用於開發受影響代碼的郵件列表。這可以使用 ``get_maintainer.pl`` 。
 
 
 例如，您在gspca的sonixj.c文件中發現一個缺陷，則可以通過以下方法找到它的維護者::
@@ -251,7 +251,7 @@ objdump
 
 請注意它將指出：
 
-- 最後接觸原始碼的開發人員（如果這是在git樹中完成的）。在上面的例子中是Tejun
+- 最後接觸源代碼的開發人員（如果這是在git樹中完成的）。在上面的例子中是Tejun
   和Bhaktipriya（在這個特定的案例中，沒有人真正參與這個文件的開發）；
 - 驅動維護人員（Hans Verkuil）；
 - 子系統維護人員（Mauro Carvalho Chehab）；

Documentation/translations/zh_TW/admin-guide/clearing-warn-once.rst

@@ -7,10 +7,10 @@
 清除 WARN_ONCE
 --------------
 
-WARN_ONCE / WARN_ON_ONCE / printk_once 僅僅列印一次消息.
+WARN_ONCE / WARN_ON_ONCE / printk_once 僅僅打印一次消息.
 
 echo 1 > /sys/kernel/debug/clear_warn_once
 
-可以清除這種狀態並且再次允許列印一次告警信息，這對於運行測試集後重現問題
+可以清除這種狀態並且再次允許打印一次告警信息，這對於運行測試集後重現問題
 很有用。
 

Documentation/translations/zh_TW/admin-guide/cpu-load.rst

@@ -20,13 +20,13 @@ Linux通過``/proc/stat``和``/proc/uptime``導出各種信息，用戶空間工
 
     ...
 
-這裡系統認爲在默認採樣周期內有10.01%的時間工作在用戶空間，2.92%的時
+這裏系統認爲在默認採樣週期內有10.01%的時間工作在用戶空間，2.92%的時
 間用在系統空間，總體上有81.63%的時間是空閒的。
 
 大多數情況下``/proc/stat``的信息幾乎真實反映了系統信息，然而，由於內
 核採集這些數據的方式/時間的特點，有時這些信息根本不可靠。
 
-那麼這些信息是如何被搜集的呢？每當時間中斷觸發時，內核查看此刻運行的
+那麼這些信息是如何被蒐集的呢？每當時間中斷觸發時，內核查看此刻運行的
 進程類型，並增加與此類型/狀態進程對應的計數器的值。這種方法的問題是
 在兩次時間中斷之間系統（進程）能夠在多種狀態之間切換多次，而計數器只
 增加最後一種狀態下的計數。
@@ -34,7 +34,7 @@ Linux通過``/proc/stat``和``/proc/uptime``導出各種信息，用戶空間工
 舉例
 ---
 
-假設系統有一個進程以如下方式周期性地占用cpu::
+假設系統有一個進程以如下方式週期性地佔用cpu::
 
      兩個時鐘中斷之間的時間線
     |-----------------------|
@@ -46,7 +46,7 @@ Linux通過``/proc/stat``和``/proc/uptime``導出各種信息，用戶空間工
 在上面的情況下，根據``/proc/stat``的信息（由於當系統處於空閒狀態時，
 時間中斷經常會發生）系統的負載將會是0
 
-大家能夠想像內核的這種行爲會發生在許多情況下，這將導致``/proc/stat``
+大家能夠想象內核的這種行爲會發生在許多情況下，這將導致``/proc/stat``
 中存在相當古怪的信息::
 
 	/* gcc -o hog smallhog.c */

Documentation/translations/zh_TW/admin-guide/cputopology.rst

+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../disclaimer-zh_TW.rst
+
+:Original: Documentation/admin-guide/cputopology.rst
+
+:翻譯:
+
+  唐藝舟 Tang Yizhou <tangyeechou@gmail.com>
+
+==========================
+如何通過sysfs將CPU拓撲導出
+==========================
+
+CPU拓撲信息通過sysfs導出。顯示的項（屬性）和某些架構的/proc/cpuinfo輸出相似。它們位於
+/sys/devices/system/cpu/cpuX/topology/。請閱讀ABI文件：
+Documentation/ABI/stable/sysfs-devices-system-cpu。
+
+drivers/base/topology.c是體系結構中性的，它導出了這些屬性。然而，die、cluster、book、
+draw這些層次結構相關的文件僅在體系結構提供了下文描述的宏的條件下被創建。
+
+對於支持這個特性的體系結構，它必須在include/asm-XXX/topology.h中定義這些宏中的一部分::
+
+	#define topology_physical_package_id(cpu)
+	#define topology_die_id(cpu)
+	#define topology_cluster_id(cpu)
+	#define topology_core_id(cpu)
+	#define topology_book_id(cpu)
+	#define topology_drawer_id(cpu)
+	#define topology_sibling_cpumask(cpu)
+	#define topology_core_cpumask(cpu)
+	#define topology_cluster_cpumask(cpu)
+	#define topology_die_cpumask(cpu)
+	#define topology_book_cpumask(cpu)
+	#define topology_drawer_cpumask(cpu)
+
+``**_id macros`` 的類型是int。
+``**_cpumask macros`` 的類型是 ``(const) struct cpumask *`` 。後者和恰當的
+``**_siblings`` sysfs屬性對應（除了topology_sibling_cpumask()，它和thread_siblings
+對應）。
+
+爲了在所有體系結構上保持一致，include/linux/topology.h提供了上述所有宏的默認定義，以防
+它們未在include/asm-XXX/topology.h中定義:
+
+1) topology_physical_package_id: -1
+2) topology_die_id: -1
+3) topology_cluster_id: -1
+4) topology_core_id: 0
+5) topology_book_id: -1
+6) topology_drawer_id: -1
+7) topology_sibling_cpumask: 僅入參CPU
+8) topology_core_cpumask: 僅入參CPU
+9) topology_cluster_cpumask: 僅入參CPU
+10) topology_die_cpumask: 僅入參CPU
+11) topology_book_cpumask:  僅入參CPU
+12) topology_drawer_cpumask: 僅入參CPU
+
+此外，CPU拓撲信息由/sys/devices/system/cpu提供，包含下述文件。輸出對應的內部數據源放在
+方括號（"[]"）中。
+
+    =========== ==================================================================
+    kernel_max: 內核配置允許的最大CPU下標值。[NR_CPUS-1]
+
+    offline:    由於熱插拔移除或者超過內核允許的CPU上限（上文描述的kernel_max）
+                導致未上線的CPU。[~cpu_online_mask + cpus >= NR_CPUS]
+
+    online:     在線的CPU，可供調度使用。[cpu_online_mask]
+
+    possible:   已被分配資源的CPU，如果它們CPU實際存在，可以上線。
+                [cpu_possible_mask]
+
+    present:    被系統識別實際存在的CPU。[cpu_present_mask]
+    =========== ==================================================================
+
+上述輸出的格式和cpulist_parse()兼容[參見 <linux/cpumask.h>]。下面給些例子。
+
+在本例中，系統中有64個CPU，但是CPU 32-63超過了kernel_max值，因爲NR_CPUS配置項是32，
+取值範圍被限制爲0..31。此外注意CPU2和4-31未上線，但是可以上線，因爲它們同時存在於
+present和possible::
+
+     kernel_max: 31
+        offline: 2,4-31,32-63
+         online: 0-1,3
+       possible: 0-31
+        present: 0-31
+
+在本例中，NR_CPUS配置項是128，但內核啓動時設置possible_cpus=144。系統中有4個CPU，
+CPU2被手動設置下線（也是唯一一個可以上線的CPU）::
+
+     kernel_max: 127
+        offline: 2,4-127,128-143
+         online: 0-1,3
+       possible: 0-127
+        present: 0-3
+
+閱讀Documentation/core-api/cpu_hotplug.rst可瞭解開機參數possible_cpus=NUM，同時還
+可以瞭解各種cpumask的信息。
+

Documentation/translations/zh_TW/admin-guide/index.rst

@@ -3,13 +3,14 @@
 .. include:: ../disclaimer-zh_TW.rst
 
 :Original: :doc:`../../../admin-guide/index`
-:Translator: 胡皓文 Hu Haowen <src.res.211@gmail.com>
+:Translator: Alex Shi <alex.shi@linux.alibaba.com>
+             胡皓文 Hu Haowen <src.res.211@gmail.com>
 
 Linux 內核用戶和管理員指南
 ==========================
 
 下面是一組隨時間添加到內核中的面向用戶的文檔的集合。到目前爲止，還沒有一個
-整體的順序或組織 - 這些材料不是一個單一的，連貫的文件！幸運的話，情況會隨著
+整體的順序或組織 - 這些材料不是一個單一的，連貫的文件！幸運的話，情況會隨着
 時間的推移而迅速改善。
 
 這個初始部分包含總體信息，包括描述內核的README， 關於內核參數的文檔等。
@@ -21,15 +22,15 @@ Linux 內核用戶和管理員指南
 
 Todolist:
 
-   kernel-parameters
-   devices
-   sysctl/index
+*   kernel-parameters
+*   devices
+*   sysctl/index
 
 本節介紹CPU漏洞及其緩解措施。
 
 Todolist:
 
-   hw-vuln/index
+*   hw-vuln/index
 
 下面的一組文檔，針對的是試圖跟蹤問題和bug的用戶。
 
@@ -37,6 +38,7 @@ Todolist:
    :maxdepth: 1
 
    reporting-issues
+   reporting-regressions
    security-bugs
    bug-hunting
    bug-bisect
@@ -45,18 +47,17 @@ Todolist:
 
 Todolist:
 
-   reporting-bugs
-   ramoops
-   dynamic-debug-howto
-   kdump/index
-   perf/index
+*   ramoops
+*   dynamic-debug-howto
+*   kdump/index
+*   perf/index
 
-這是應用程式開發人員感興趣的章節的開始。可以在這裡找到涵蓋內核ABI各個
+這是應用程序開發人員感興趣的章節的開始。可以在這裏找到涵蓋內核ABI各個
 方面的文檔。
 
 Todolist:
 
-   sysfs-rules
+*   sysfs-rules
 
 本手冊的其餘部分包括各種指南，介紹如何根據您的喜好配置內核的特定行爲。
 
@@ -64,67 +65,67 @@ Todolist:
 .. toctree::
    :maxdepth: 1
 
+   bootconfig
    clearing-warn-once
    cpu-load
+   cputopology
+   lockup-watchdogs
    unicode
+   sysrq
+   mm/index
 
 Todolist:
 
-   acpi/index
-   aoe/index
-   auxdisplay/index
-   bcache
-   binderfs
-   binfmt-misc
-   blockdev/index
-   bootconfig
-   braille-console
-   btmrvl
-   cgroup-v1/index
-   cgroup-v2
-   cifs/index
-   cputopology
-   dell_rbu
-   device-mapper/index
-   edid
-   efi-stub
-   ext4
-   nfs/index
-   gpio/index
-   highuid
-   hw_random
-   initrd
-   iostats
-   java
-   jfs
-   kernel-per-CPU-kthreads
-   laptops/index
-   lcd-panel-cgram
-   ldm
-   lockup-watchdogs
-   LSM/index
-   md
-   media/index
-   mm/index
-   module-signing
-   mono
-   namespaces/index
-   numastat
-   parport
-   perf-security
-   pm/index
-   pnp
-   rapidio
-   ras
-   rtc
-   serial-console
-   svga
-   sysrq
-   thunderbolt
-   ufs
-   vga-softcursor
-   video-output
-   xfs
+*   acpi/index
+*   aoe/index
+*   auxdisplay/index
+*   bcache
+*   binderfs
+*   binfmt-misc
+*   blockdev/index
+*   braille-console
+*   btmrvl
+*   cgroup-v1/index
+*   cgroup-v2
+*   cifs/index
+*   dell_rbu
+*   device-mapper/index
+*   edid
+*   efi-stub
+*   ext4
+*   nfs/index
+*   gpio/index
+*   highuid
+*   hw_random
+*   initrd
+*   iostats
+*   java
+*   jfs
+*   kernel-per-CPU-kthreads
+*   laptops/index
+*   lcd-panel-cgram
+*   ldm
+*   LSM/index
+*   md
+*   media/index
+*   module-signing
+*   mono
+*   namespaces/index
+*   numastat
+*   parport
+*   perf-security
+*   pm/index
+*   pnp
+*   rapidio
+*   ras
+*   rtc
+*   serial-console
+*   svga
+*   thunderbolt
+*   ufs
+*   vga-softcursor
+*   video-output
+*   xfs
 
 .. only::  subproject and html
 

Documentation/translations/zh_TW/admin-guide/init.rst

@@ -9,8 +9,8 @@
  吳想成 Wu XiangCheng <bobwxc@email.cn>
  胡皓文 Hu Haowen <src.res.211@gmail.com>
 
-解釋「No working init found.」啓動掛起消息
-==========================================
+解釋“No working init found.”啓動掛起消息
+=========================================
 
 :作者:
 
@@ -18,41 +18,41 @@
 
  Cristian Souza <cristianmsbr at gmail period com>
 
-本文檔提供了加載初始化二進位（init binary）失敗的一些高層級原因（大致按執行
+本文檔提供了加載初始化二進制（init binary）失敗的一些高層級原因（大致按執行
 順序列出）。
 
-1) **無法掛載根文件系統Unable to mount root FS** ：請設置「debug」內核參數（在
+1) **無法掛載根文件系統Unable to mount root FS** ：請設置“debug”內核參數（在
    引導加載程序bootloader配置文件或CONFIG_CMDLINE）以獲取更詳細的內核消息。
 
-2) **初始化二進位不存在於根文件系統上init binary doesn't exist on rootfs** ：
+2) **初始化二進制不存在於根文件系統上init binary doesn't exist on rootfs** ：
    確保您的根文件系統類型正確（並且 ``root=`` 內核參數指向正確的分區）；擁有
-   所需的驅動程序，例如SCSI或USB等存儲硬體；文件系統（ext3、jffs2等）是內建的
+   所需的驅動程序，例如SCSI或USB等存儲硬件；文件系統（ext3、jffs2等）是內建的
    （或者作爲模塊由initrd預加載）。
 
-3) **控制台設備損壞Broken console device** ： ``console= setup`` 中可能存在
-   衝突 --> 初始控制台不可用（initial console unavailable）。例如，由於串行
-   IRQ問題（如缺少基於中斷的配置）導致的某些串行控制台不可靠。嘗試使用不同的
+3) **控制檯設備損壞Broken console device** ： ``console= setup`` 中可能存在
+   衝突 --> 初始控制檯不可用（initial console unavailable）。例如，由於串行
+   IRQ問題（如缺少基於中斷的配置）導致的某些串行控制檯不可靠。嘗試使用不同的
    ``console= device`` 或像 ``netconsole=`` 。
 
-4) **二進位存在但依賴項不可用Binary exists but dependencies not available** ：
-   例如初始化二進位的必需庫依賴項，像 ``/lib/ld-linux.so.2`` 丟失或損壞。使用
+4) **二進制存在但依賴項不可用Binary exists but dependencies not available** ：
+   例如初始化二進制的必需庫依賴項，像 ``/lib/ld-linux.so.2`` 丟失或損壞。使用
    ``readelf -d <INIT>|grep NEEDED`` 找出需要哪些庫。
 
-5) **無法加載二進位Binary cannot be loaded** ：請確保二進位的體系結構與您的
-   硬體匹配。例如i386不匹配x86_64，或者嘗試在ARM硬體上加載x86。如果您嘗試在
-   此處加載非二進位文件（shell腳本？），您應該確保腳本在其工作頭（shebang
+5) **無法加載二進制Binary cannot be loaded** ：請確保二進制的體系結構與您的
+   硬件匹配。例如i386不匹配x86_64，或者嘗試在ARM硬件上加載x86。如果您嘗試在
+   此處加載非二進制文件（shell腳本？），您應該確保腳本在其工作頭（shebang
    header）行 ``#!/...`` 中指定能正常工作的解釋器（包括其庫依賴項）。在處理
-   腳本之前，最好先測試一個簡單的非腳本二進位文件，比如 ``/bin/sh`` ，並確認
+   腳本之前，最好先測試一個簡單的非腳本二進制文件，比如 ``/bin/sh`` ，並確認
    它能成功執行。要了解更多信息，請將代碼添加到 ``init/main.c`` 以顯示
    kernel_execve()的返回值。
 
-當您發現新的失敗原因時，請擴展本解釋（畢竟加載初始化二進位是一個 **關鍵** 且
+當您發現新的失敗原因時，請擴展本解釋（畢竟加載初始化二進制是一個 **關鍵** 且
 艱難的過渡步驟，需要儘可能無痛地進行），然後向LKML提交一個補丁。
 
 待辦事項：
 
 - 通過一個可以存儲 ``kernel_execve()`` 結果值的結構體數組實現各種
-  ``run_init_process()`` 調用，並在失敗時通過疊代 **所有** 結果來記錄一切
+  ``run_init_process()`` 調用，並在失敗時通過迭代 **所有** 結果來記錄一切
   （非常重要的可用性修復）。
-- 試著使實現本身在一般情況下更有幫助，例如在受影響的地方提供額外的錯誤消息。
+- 試着使實現本身在一般情況下更有幫助，例如在受影響的地方提供額外的錯誤消息。
 

Documentation/translations/zh_TW/admin-guide/lockup-watchdogs.rst

+.. include:: ../disclaimer-zh_TW.rst
+
+:Original: Documentation/admin-guide/lockup-watchdogs.rst
+:Translator: Hailong Liu <liu.hailong6@zte.com.cn>
+
+.. _tw_lockup-watchdogs:
+
+
+=================================================
+Softlockup與hardlockup檢測機制(又名:nmi_watchdog)
+=================================================
+
+Linux中內核實現了一種用以檢測系統發生softlockup和hardlockup的看門狗機制。
+
+Softlockup是一種會引發系統在內核態中一直循環超過20秒（詳見下面“實現”小節）導致
+其他任務沒有機會得到運行的BUG。一旦檢測到'softlockup'發生，默認情況下系統會打
+印當前堆棧跟蹤信息並進入鎖定狀態。也可配置使其在檢測到'softlockup'後進入panic
+狀態；通過sysctl命令設置“kernel.softlockup_panic”、使用內核啓動參數
+“softlockup_panic”（詳見Documentation/admin-guide/kernel-parameters.rst）以及使
+能內核編譯選項“BOOTPARAM_SOFTLOCKUP_PANIC”都可實現這種配置。
+
+而'hardlockup'是一種會引發系統在內核態一直循環超過10秒鐘（詳見"實現"小節）導致其
+他中斷沒有機會運行的缺陷。與'softlockup'情況類似，除了使用sysctl命令設置
+'hardlockup_panic'、使能內核選項“BOOTPARAM_HARDLOCKUP_PANIC”以及使用內核參數
+"nmi_watchdog"(詳見:”Documentation/admin-guide/kernel-parameters.rst“)外，一旦檢
+測到'hardlockup'默認情況下系統打印當前堆棧跟蹤信息，然後進入鎖定狀態。
+
+這個panic選項也可以與panic_timeout結合使用（這個panic_timeout是通過稍具迷惑性的
+sysctl命令"kernel.panic"來設置），使系統在panic指定時間後自動重啓。
+
+實現
+====
+
+Softlockup和hardlockup分別建立在hrtimer(高精度定時器)和perf兩個子系統上而實現。
+這也就意味着理論上任何架構只要實現了這兩個子系統就支持這兩種檢測機制。
+
+Hrtimer用於週期性產生中斷並喚醒watchdog線程；NMI perf事件則以”watchdog_thresh“
+(編譯時默認初始化爲10秒，也可通過”watchdog_thresh“這個sysctl接口來進行配置修改)
+爲間隔週期產生以檢測 hardlockups。如果一個CPU在這個時間段內沒有檢測到hrtimer中
+斷髮生，'hardlockup 檢測器'(即NMI perf事件處理函數)將會視系統配置而選擇產生內核
+警告或者直接panic。
+
+而watchdog線程本質上是一個高優先級內核線程，每調度一次就對時間戳進行一次更新。
+如果時間戳在2*watchdog_thresh(這個是softlockup的觸發門限)這段時間都未更新,那麼
+"softlocup 檢測器"(內部hrtimer定時器回調函數)會將相關的調試信息打印到系統日誌中，
+然後如果系統配置了進入panic流程則進入panic，否則內核繼續執行。
+
+Hrtimer定時器的週期是2*watchdog_thresh/5，也就是說在hardlockup被觸發前hrtimer有
+2~3次機會產生時鐘中斷。
+
+如上所述,內核相當於爲系統管理員提供了一個可調節hrtimer定時器和perf事件週期長度
+的調節旋鈕。如何通過這個旋鈕爲特定使用場景配置一個合理的週期值要對lockups檢測的
+響應速度和lockups檢測開銷這二者之間進行權衡。
+
+默認情況下所有在線cpu上都會運行一個watchdog線程。不過在內核配置了”NO_HZ_FULL“的
+情況下watchdog線程默認只會運行在管家(housekeeping)cpu上，而”nohz_full“啓動參數指
+定的cpu上則不會有watchdog線程運行。試想，如果我們允許watchdog線程在”nohz_full“指
+定的cpu上運行，這些cpu上必須得運行時鐘定時器來激發watchdog線程調度；這樣一來就會
+使”nohz_full“保護用戶程序免受內核干擾的功能失效。當然，副作用就是”nohz_full“指定
+的cpu即使在內核產生了lockup問題我們也無法檢測到。不過，至少我們可以允許watchdog
+線程在管家(non-tickless)核上繼續運行以便我們能繼續正常的監測這些cpus上的lockups
+事件。
+
+不論哪種情況都可以通過sysctl命令kernel.watchdog_cpumask來對沒有運行watchdog線程
+的cpu集合進行調節。對於nohz_full而言,如果nohz_full cpu上有異常掛住的情況，通過
+這種方式打開這些cpu上的watchdog進行調試可能會有所作用。
+

Documentation/translations/zh_TW/admin-guide/mm/damon/index.rst

+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../../../disclaimer-zh_TW.rst
+
+:Original: Documentation/admin-guide/mm/damon/index.rst
+
+:翻譯:
+
+ 司延騰 Yanteng Si <siyanteng@loongson.cn>
+
+:校譯:
+
+============
+監測數據訪問
+============
+
+:doc:`DAMON </mm/damon/index>` 允許輕量級的數據訪問監測。使用DAMON，
+用戶可以分析他們系統的內存訪問模式，並優化它們。
+
+.. toctree::
+   :maxdepth: 2
+
+   start
+   usage
+   reclaim
+   lru_sort
+
+
+
+
+

Documentation/translations/zh_TW/admin-guide/mm/damon/lru_sort.rst

+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../../../disclaimer-zh_TW.rst
+
+:Original: Documentation/admin-guide/mm/damon/lru_sort.rst
+
+:翻譯:
+
+ 臧雷剛 Leigang Zang <zangleigang@hisilicon.com>
+
+:校譯:
+
+==================
+基於DAMON的LRU排序
+==================
+
+基於DAMON的LRU排序是一個靜態的內核模塊，旨在用於以主動的、輕量級的數據訪問模型
+爲基礎的頁面優先級處理的LRU鏈表上，以使得LRU上的數據訪問模型更爲可信。
+
+哪裏需要主動的LRU排序
+=====================
+
+在一個大型系統中，以頁爲粒度的訪問檢測會有比較顯著的開銷，LRU通常不會主動去排序，
+而是對部分特殊事件進行部分的、響應式的排序，例如：特殊的用戶請求，系統調用或者
+內存壓力。這導致，在有些場景下，LRU不能夠完美的作爲一個可信的數據訪問模型，比如
+在內存壓力下對目標內存進行回收。
+
+因爲DAMON能夠儘可能準確的識別數據訪問模型，同時只引起用戶指定範圍的開銷，主動的
+執行DAMON_LRU_SORT讓LRU變得更爲可信是有益的，而且這隻需要較少和可控的開銷。
+
+這是如何工作的
+==============
+
+DAMON_LRU_SORT使用DAMON尋找熱頁（範圍內的頁面訪問頻率高於用戶指定的閾值）和冷頁
+（範圍內的頁面在超過用戶指定的時間無訪問），並提高熱頁和降低冷頁在LRU中的優先級。
+爲了避免在排序過程佔用更多的CPU計算資源，可以設置一個CPU佔用時間的約束值。在約
+束下，分別提升或者降低更多的熱頁和冷頁。系統管理員也可以配置三個內存水位以控制
+在何種條件下自動激活或者停止這種機制。
+
+冷熱閾值和CPU約束的默認值是比較保守的。這意味着，在默認參數下，模塊可以廣泛且無
+負作用的使用在常見環境中，同時在只消耗一小部分CPU時間的情況下，給有內存壓力的系
+統提供一定水平的冷熱識別。
+
+接口：模塊參數
+==============
+
+使用此特性，你首先需要確認你的系統中運行的內核在編譯時啓用了
+``CONFIG_DAMON_LRU_SORT=y``.
+
+爲了讓系統管理員打開或者關閉並且調節指定的系統，DAMON_LRU_SORT設計了模塊參數。
+這意味着，你可以添加 ``damon_lru_sort.<parameter>=<value>`` 到內核的啓動命令行
+參數，或者在 ``/sys/modules/damon_lru_sort/parameters/<parameter>`` 寫入正確的
+值。
+
+下邊是每個參數的描述
+
+enabled
+-------
+
+打開或者關閉DAMON_LRU_SORT.
+
+你可以通過設置這個參數爲 ``Y`` 來打開DAMON_LRU_SORT。設置爲 ``N`` 關閉
+DAMON_LRU_SORT。注意，在基於水位的激活的情況下，DAMON_LRU_SORT有可能不會真正去
+監測或者做LRU排序。對這種情況，參考下方關於水位的描述。
+
+commit_inputs
+-------------
+
+讓DAMON_LRU_SORT再次讀取輸入參數，除了 ``enabled`` 。
+
+在DAMON_LRU_SORT運行時，新的輸入參數默認不會被應用。一旦這個參數被設置爲 ``Y``
+，DAMON_LRU_SORT會再次讀取除了 ``enabled`` 之外的參數。讀取完成後，這個參數會被
+設置爲 ``N`` 。如果在讀取時發現有無效參數，DAMON_LRU_SORT會被關閉。
+
+hot_thres_access_freq
+---------------------
+
+熱點內存區域的訪問頻率閾值，千分比。
+
+如果一個內存區域的訪問頻率大於等於這個值，DAMON_LRU_SORT把這個區域看作熱區，並
+在LRU上把這個區域標記爲已訪問，因些在內存壓力下這部分內存不會被回收。默認爲50%。
+
+cold_min_age
+------------
+
+用於識別冷內存區域的時間閾值，單位是微秒。
+
+如果一個內存區域在這個時間內未被訪問過，DAMON_LRU_SORT把這個區域看作冷區，並在
+LRU上把這個區域標記爲未訪問，因此在內存壓力下這些內存會首先被回收。默認值爲120
+秒。
+
+quota_ms
+--------
+
+嘗試LRU鏈表排序的時間限制，單位是毫秒。
+
+DAMON_LRU_SORT在一個時間窗口內（quota_reset_interval_ms）內最多嘗試這麼長時間來
+對LRU進行排序。這個可以用來作爲CPU計算資源的約束。如果值爲0，則表示無限制。
+
+默認10毫秒。
+
+quota_reset_interval_ms
+-----------------------
+
+配額計時重置週期，毫秒。
+
+配額計時重置週期。即，在quota_reset_interval_ms毫秒內，DAMON_LRU_SORT對LRU進行
+排序不會超過quota_ms或者quota_sz。
+
+默認1秒。
+
+wmarks_interval
+---------------
+
+水位的檢查週期，單位是微秒。
+
+當DAMON_LRU_SORT使能但是由於水位而不活躍時檢查水位前最小的等待時間。默認值5秒。
+
+wmarks_high
+-----------
+
+空閒內存高水位，千分比。
+
+如果空閒內存水位高於這個值，DAMON_LRU_SORT停止工作，不做任何事，除了週期性的檢
+查水位。默認200(20%)。
+
+wmarks_mid
+----------
+
+空閒內存中間水位，千分比。
+
+如果空閒內存水位在這個值與低水位之間，DAMON_LRU_SORT開始工作，開始檢測並對LRU鏈
+表進行排序。默認150(15%)。
+
+wmarks_low
+----------
+
+空閒內存低水位，千分比。
+
+如果空閒內存小於這個值，DAMON_LRU_SORT不再工作，不做任何事，除了週期性的檢查水
+線。默認50(5%)。
+
+sample_interval
+---------------
+
+監測的採樣週期，微秒。
+
+DAMON對冷內存監測的採樣週期。更多細節請參考DAMON文檔 (:doc:`usage`) 。默認5
+毫秒。
+
+aggr_interval
+-------------
+
+監測的收集週期，微秒。
+
+DAMON對冷內存進行收集的時間週期。更多細節請參考DAMON文檔 (:doc:`usage`) 。默認
+100毫秒。
+
+min_nr_regions
+--------------
+
+最小監測區域數量。
+
+對冷內存區域監測的最小數量。這個值可以作爲監測質量的下限。不過，這個值設置的過
+大會增加開銷。更多細節請參考DAMON文檔 (:doc:`usage`) 。默認值爲10。
+
+max_nr_regions
+--------------
+
+最大監測區域數量。
+
+對冷內存區域監測的最大數量。這個值可以作爲監測質量的上限。然而，這個值設置的過
+低會導致監測結果變差。更多細節請參考DAMON文檔 (:doc:`usage`) 。默認值爲1000。
+
+monitor_region_start
+--------------------
+
+目標內存區域的起始物理地址。
+
+DAMON_LRU_SORT要處理的目標內存區域的起始物理地址。默認，使用系統最大內存。
+
+monitor_region_end
+------------------
+
+目標內存區域的結束物理地址。
+
+DAMON_LRU_SORT要處理的目標內存區域的結束物理地址。默認，使用系統最大內存。
+
+kdamond_pid
+-----------
+
+DAMON線程的PID。
+
+如果DAMON_LRU_SORT是使能的，這個表示任務線程的PID。其它情況爲-1。
+
+nr_lru_sort_tried_hot_regions
+-----------------------------
+
+被嘗試進行LRU排序的熱內存區域的數量。
+
+bytes_lru_sort_tried_hot_regions
+--------------------------------
+
+被嘗試進行LRU排序的熱內存區域的大小（字節）。
+
+nr_lru_sorted_hot_regions
+-------------------------
+
+成功進行LRU排序的熱內存區域的數量。
+
+bytes_lru_sorted_hot_regions
+----------------------------
+
+成功進行LRU排序的熱內存區域的大小（字節）。
+
+nr_hot_quota_exceeds
+--------------------
+
+熱區域時間約束超過限制的次數。
+
+nr_lru_sort_tried_cold_regions
+------------------------------
+
+被嘗試進行LRU排序的冷內存區域的數量。
+
+bytes_lru_sort_tried_cold_regions
+---------------------------------
+
+被嘗試進行LRU排序的冷內存區域的大小（字節）。
+
+nr_lru_sorted_cold_regions
+--------------------------
+
+成功進行LRU排序的冷內存區域的數量。
+
+bytes_lru_sorted_cold_regions
+-----------------------------
+
+成功進行LRU排序的冷內存區域的大小（字節）。
+
+nr_cold_quota_exceeds
+---------------------
+
+冷區域時間約束超過限制的次數。
+
+Example
+=======
+
+如下是一個運行時的命令示例，使DAMON_LRU_SORT查找訪問頻率超過50%的區域並對其進行
+LRU的優先級的提升，同時降低那些超過120秒無人訪問的內存區域的優先級。優先級的處
+理被限制在最多1%的CPU以避免DAMON_LRU_SORT消費過多CPU時間。在系統空閒內存超過50%
+時DAMON_LRU_SORT停止工作，並在低於40%時重新開始工作。如果DAMON_RECLAIM沒有取得
+進展且空閒內存低於20%，再次讓DAMON_LRU_SORT停止工作，以此回退到以LRU鏈表爲基礎
+以頁面爲單位的內存回收上。 ::
+
+    # cd /sys/modules/damon_lru_sort/parameters
+    # echo 500 > hot_thres_access_freq
+    # echo 120000000 > cold_min_age
+    # echo 10 > quota_ms
+    # echo 1000 > quota_reset_interval_ms
+    # echo 500 > wmarks_high
+    # echo 400 > wmarks_mid
+    # echo 200 > wmarks_low
+    # echo Y > enabled
+

Documentation/translations/zh_TW/admin-guide/mm/damon/reclaim.rst

+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../../../disclaimer-zh_TW.rst
+
+:Original: Documentation/admin-guide/mm/damon/reclaim.rst
+
+:翻譯:
+
+ 司延騰 Yanteng Si <siyanteng@loongson.cn>
+
+:校譯:
+
+===============
+基於DAMON的回收
+===============
+
+基於DAMON的回收（DAMON_RECLAIM）是一個靜態的內核模塊，旨在用於輕度內存壓力下的主動和輕
+量級的回收。它的目的不是取代基於LRU列表的頁面回收，而是有選擇地用於不同程度的內存壓力和要
+求。
+
+哪些地方需要主動回收？
+======================
+
+在一般的內存超量使用（over-committed systems，虛擬化相關術語）的系統上，主動回收冷頁
+有助於節省內存和減少延遲高峯，這些延遲是由直接回收進程或kswapd的CPU消耗引起的，同時只產
+生最小的性能下降 [1]_ [2]_ 。
+
+基於空閒頁報告 [3]_ 的內存過度承諾的虛擬化系統就是很好的例子。在這樣的系統中，客戶機
+向主機報告他們的空閒內存，而主機則將報告的內存重新分配給其他客戶。因此，系統的內存得到了充
+分的利用。然而，客戶可能不那麼節省內存，主要是因爲一些內核子系統和用戶空間應用程序被設計爲
+使用盡可能多的內存。然後，客戶機可能只向主機報告少量的內存是空閒的，導致系統的內存利用率下降。
+在客戶中運行主動回收可以緩解這個問題。
+
+它是如何工作的？
+================
+
+DAMON_RECLAIM找到在特定時間內沒有被訪問的內存區域並分頁。爲了避免它在分頁操作中消耗過多
+的CPU，可以配置一個速度限制。在這個速度限制下，它首先分頁出那些沒有被訪問過的內存區域。系
+統管理員還可以配置在什麼情況下這個方案應該自動激活和停用三個內存壓力水位。
+
+接口: 模塊參數
+==============
+
+要使用這個功能，你首先要確保你的系統運行在一個以 ``CONFIG_DAMON_RECLAIM=y`` 構建的內
+核上。
+
+爲了讓系統管理員啓用或禁用它，併爲給定的系統進行調整，DAMON_RECLAIM利用了模塊參數。也就
+是說，你可以把 ``damon_reclaim.<parameter>=<value>`` 放在內核啓動命令行上，或者把
+適當的值寫入 ``/sys/module/damon_reclaim/parameters/<parameter>`` 文件。
+
+下面是每個參數的描述。
+
+enabled
+-------
+
+啓用或禁用DAMON_RECLAIM。
+
+你可以通過把這個參數的值設置爲 ``Y`` 來啓用DAMON_RCLAIM，把它設置爲 ``N`` 可以禁用
+DAMON_RECLAIM。注意，由於基於水位的激活條件，DAMON_RECLAIM不能進行真正的監測和回收。
+這一點請參考下面關於水位參數的描述。
+
+min_age
+-------
+
+識別冷內存區域的時間閾值，單位是微秒。
+
+如果一個內存區域在這個時間或更長的時間內沒有被訪問，DAMON_RECLAIM會將該區域識別爲冷的，
+並回收它。
+
+默認爲120秒。
+
+quota_ms
+--------
+
+回收的時間限制，以毫秒爲單位。
+
+DAMON_RECLAIM 試圖在一個時間窗口（quota_reset_interval_ms）內只使用到這個時間，以
+嘗試回收冷頁。這可以用來限制DAMON_RECLAIM的CPU消耗。如果該值爲零，則該限制被禁用。
+
+默認爲10ms。
+
+quota_sz
+--------
+
+回收的內存大小限制，單位爲字節。
+
+DAMON_RECLAIM 收取在一個時間窗口（quota_reset_interval_ms）內試圖回收的內存量，並
+使其不超過這個限制。這可以用來限制CPU和IO的消耗。如果該值爲零，則限制被禁用。
+
+默認情況下是128 MiB。
+
+quota_reset_interval_ms
+-----------------------
+
+時間/大小配額收取重置間隔，單位爲毫秒。
+
+時間（quota_ms）和大小（quota_sz）的配額的目標重置間隔。也就是說，DAMON_RECLAIM在
+嘗試回收‘不’超過quota_ms毫秒或quota_sz字節的內存。
+
+默認爲1秒。
+
+wmarks_interval
+---------------
+
+當DAMON_RECLAIM被啓用但由於其水位規則而不活躍時，在檢查水位之前的最小等待時間。
+
+wmarks_high
+-----------
+
+高水位的可用內存率（每千字節）。
+
+如果系統的可用內存（以每千字節爲單位）高於這個數值，DAMON_RECLAIM就會變得不活躍，所以
+它什麼也不做，只是定期檢查水位。
+
+wmarks_mid
+----------
+
+中間水位的可用內存率（每千字節）。
+
+如果系統的空閒內存（以每千字節爲單位）在這個和低水位線之間，DAMON_RECLAIM就會被激活，
+因此開始監測和回收。
+
+wmarks_low
+----------
+
+低水位的可用內存率（每千字節）。
+
+如果系統的空閒內存（以每千字節爲單位）低於這個數值，DAMON_RECLAIM就會變得不活躍，所以
+它除了定期檢查水位外什麼都不做。在這種情況下，系統會退回到基於LRU列表的頁面粒度回收邏輯。
+
+sample_interval
+---------------
+
+監測的採樣間隔，單位是微秒。
+
+DAMON用於監測冷內存的採樣間隔。更多細節請參考DAMON文檔 (:doc:`usage`) 。
+
+aggr_interval
+-------------
+
+監測的聚集間隔，單位是微秒。
+
+DAMON對冷內存監測的聚集間隔。更多細節請參考DAMON文檔 (:doc:`usage`)。
+
+min_nr_regions
+--------------
+
+監測區域的最小數量。
+
+DAMON用於冷內存監測的最小監測區域數。這可以用來設置監測質量的下限。但是，設
+置的太高可能會導致監測開銷的增加。更多細節請參考DAMON文檔 (:doc:`usage`) 。
+
+max_nr_regions
+--------------
+
+監測區域的最大數量。
+
+DAMON用於冷內存監測的最大監測區域數。這可以用來設置監測開銷的上限值。但是，
+設置得太低可能會導致監測質量不好。更多細節請參考DAMON文檔 (:doc:`usage`) 。
+
+monitor_region_start
+--------------------
+
+目標內存區域的物理地址起點。
+
+DAMON_RECLAIM將對其進行工作的內存區域的起始物理地址。也就是說，DAMON_RECLAIM
+將在這個區域中找到冷的內存區域並進行回收。默認情況下，該區域使用最大系統內存區。
+
+monitor_region_end
+------------------
+
+目標內存區域的結束物理地址。
+
+DAMON_RECLAIM將對其進行工作的內存區域的末端物理地址。也就是說，DAMON_RECLAIM將
+在這個區域內找到冷的內存區域並進行回收。默認情況下，該區域使用最大系統內存區。
+
+kdamond_pid
+-----------
+
+DAMON線程的PID。
+
+如果DAMON_RECLAIM被啓用，這將成爲工作線程的PID。否則，爲-1。
+
+nr_reclaim_tried_regions
+------------------------
+
+試圖通過DAMON_RECLAIM回收的內存區域的數量。
+
+bytes_reclaim_tried_regions
+---------------------------
+
+試圖通過DAMON_RECLAIM回收的內存區域的總字節數。
+
+nr_reclaimed_regions
+--------------------
+
+通過DAMON_RECLAIM成功回收的內存區域的數量。
+
+bytes_reclaimed_regions
+-----------------------
+
+通過DAMON_RECLAIM成功回收的內存區域的總字節數。
+
+nr_quota_exceeds
+----------------
+
+超過時間/空間配額限制的次數。
+
+例子
+====
+
+下面的運行示例命令使DAMON_RECLAIM找到30秒或更長時間沒有訪問的內存區域並“回收”？
+爲了避免DAMON_RECLAIM在分頁操作中消耗過多的CPU時間，回收被限制在每秒1GiB以內。
+它還要求DAMON_RECLAIM在系統的可用內存率超過50%時不做任何事情，但如果它低於40%時
+就開始真正的工作。如果DAMON_RECLAIM沒有取得進展，因此空閒內存率低於20%，它會要求
+DAMON_RECLAIM再次什麼都不做，這樣我們就可以退回到基於LRU列表的頁面粒度回收了::
+
+    # cd /sys/module/damon_reclaim/parameters
+    # echo 30000000 > min_age
+    # echo $((1 * 1024 * 1024 * 1024)) > quota_sz
+    # echo 1000 > quota_reset_interval_ms
+    # echo 500 > wmarks_high
+    # echo 400 > wmarks_mid
+    # echo 200 > wmarks_low
+    # echo Y > enabled
+
+.. [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
+

Documentation/translations/zh_TW/admin-guide/mm/damon/start.rst

+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../../../disclaimer-zh_TW.rst
+
+:Original: Documentation/admin-guide/mm/damon/start.rst
+
+:翻譯:
+
+ 司延騰 Yanteng Si <siyanteng@loongson.cn>
+
+:校譯:
+
+========
+入門指南
+========
+
+本文通過演示DAMON的默認用戶空間工具，簡要地介紹瞭如何使用DAMON。請注意，爲了簡潔
+起見，本文檔只描述了它的部分功能。更多細節請參考該工具的使用文檔。
+`doc <https://github.com/awslabs/damo/blob/next/USAGE.md>`_ .
+
+
+前提條件
+========
+
+內核
+----
+
+首先，你要確保你當前系統中跑的內核構建時選定了這個功能選項 ``CONFIG_DAMON_*=y``.
+
+
+用戶空間工具
+------------
+
+在演示中，我們將使用DAMON的默認用戶空間工具，稱爲DAMON Operator（DAMO）。它可以在
+https://github.com/awslabs/damo找到。下面的例子假設DAMO在你的$PATH上。當然，但
+這並不是強制性的。
+
+因爲DAMO使用了DAMON的sysfs接口（詳情請參考:doc:`usage`），你應該確保
+:doc:`sysfs </filesystems/sysfs>` 被掛載。
+
+記錄數據訪問模式
+================
+
+下面的命令記錄了一個程序的內存訪問模式，並將監測結果保存到文件中。 ::
+
+    $ git clone https://github.com/sjp38/masim
+    $ cd masim; make; ./masim ./configs/zigzag.cfg &
+    $ sudo damo record -o damon.data $(pidof masim)
+
+命令的前兩行下載了一個人工內存訪問生成器程序並在後臺運行。生成器將重複地逐一訪問兩個
+100 MiB大小的內存區域。你可以用你的真實工作負載來代替它。最後一行要求 ``damo`` 將
+訪問模式記錄在 ``damon.data`` 文件中。
+
+
+將記錄的模式可視化
+==================
+
+你可以在heatmap中直觀地看到這種模式，顯示哪個內存區域（X軸）何時被訪問（Y軸）以及訪
+問的頻率（數字）。::
+
+    $ sudo damo report heats --heatmap stdout
+    22222222222222222222222222222222222222211111111111111111111111111111111111111100
+    44444444444444444444444444444444444444434444444444444444444444444444444444443200
+    44444444444444444444444444444444444444433444444444444444444444444444444444444200
+    33333333333333333333333333333333333333344555555555555555555555555555555555555200
+    33333333333333333333333333333333333344444444444444444444444444444444444444444200
+    22222222222222222222222222222222222223355555555555555555555555555555555555555200
+    00000000000000000000000000000000000000288888888888888888888888888888888888888400
+    00000000000000000000000000000000000000288888888888888888888888888888888888888400
+    33333333333333333333333333333333333333355555555555555555555555555555555555555200
+    88888888888888888888888888888888888888600000000000000000000000000000000000000000
+    88888888888888888888888888888888888888600000000000000000000000000000000000000000
+    33333333333333333333333333333333333333444444444444444444444444444444444444443200
+    00000000000000000000000000000000000000288888888888888888888888888888888888888400
+    [...]
+    # access_frequency:  0  1  2  3  4  5  6  7  8  9
+    # x-axis: space (139728247021568-139728453431248: 196.848 MiB)
+    # y-axis: time (15256597248362-15326899978162: 1 m 10.303 s)
+    # resolution: 80x40 (2.461 MiB and 1.758 s for each character)
+
+你也可以直觀地看到工作集的大小分佈，按大小排序。::
+
+    $ sudo damo report wss --range 0 101 10
+    # <percentile> <wss>
+    # target_id     18446632103789443072
+    # avr:  107.708 MiB
+      0             0 B |                                                           |
+     10      95.328 MiB |****************************                               |
+     20      95.332 MiB |****************************                               |
+     30      95.340 MiB |****************************                               |
+     40      95.387 MiB |****************************                               |
+     50      95.387 MiB |****************************                               |
+     60      95.398 MiB |****************************                               |
+     70      95.398 MiB |****************************                               |
+     80      95.504 MiB |****************************                               |
+     90     190.703 MiB |*********************************************************  |
+    100     196.875 MiB |***********************************************************|
+
+在上述命令中使用 ``--sortby`` 選項，可以顯示工作集的大小是如何按時間順序變化的。::
+
+    $ sudo damo report wss --range 0 101 10 --sortby time
+    # <percentile> <wss>
+    # target_id     18446632103789443072
+    # avr:  107.708 MiB
+      0       3.051 MiB |                                                           |
+     10     190.703 MiB |***********************************************************|
+     20      95.336 MiB |*****************************                              |
+     30      95.328 MiB |*****************************                              |
+     40      95.387 MiB |*****************************                              |
+     50      95.332 MiB |*****************************                              |
+     60      95.320 MiB |*****************************                              |
+     70      95.398 MiB |*****************************                              |
+     80      95.398 MiB |*****************************                              |
+     90      95.340 MiB |*****************************                              |
+    100      95.398 MiB |*****************************                              |
+
+
+數據訪問模式感知的內存管理
+==========================
+
+以下三個命令使每一個大小>=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>
+

Documentation/translations/zh_TW/admin-guide/mm/index.rst

+.. include:: ../../disclaimer-zh_TW.rst
+
+:Original:   Documentation/admin-guide/mm/index.rst
+
+:翻譯:
+
+  徐鑫 xu xin <xu.xin16@zte.com.cn>
+
+
+========
+內存管理
+========
+
+Linux內存管理子系統，顧名思義，是負責系統中的內存管理。它包括了虛擬內存與請求
+分頁的實現，內核內部結構和用戶空間程序的內存分配、將文件映射到進程地址空間以
+及許多其他很酷的事情。
+
+Linux內存管理是一個具有許多可配置設置的複雜系統, 且這些設置中的大多數都可以通
+過 ``/proc`` 文件系統獲得，並且可以使用 ``sysctl`` 進行查詢和調整。這些API接
+口被描述在Documentation/admin-guide/sysctl/vm.rst文件和 `man 5 proc`_ 中。
+
+.. _man 5 proc: http://man7.org/linux/man-pages/man5/proc.5.html
+
+Linux內存管理有它自己的術語，如果你還不熟悉它，請考慮閱讀下面參考：
+Documentation/admin-guide/mm/concepts.rst.
+
+在此目錄下，我們詳細描述瞭如何與Linux內存管理中的各種機制交互。
+
+.. toctree::
+   :maxdepth: 1
+
+   damon/index
+   ksm
+
+Todolist:
+* concepts
+* cma_debugfs
+* hugetlbpage
+* idle_page_tracking
+* memory-hotplug
+* nommu-mmap
+* numa_memory_policy
+* numaperf
+* pagemap
+* soft-dirty
+* swap_numa
+* transhuge
+* userfaultfd
+* zswap
+

Documentation/translations/zh_TW/admin-guide/security-bugs.rst

@@ -19,17 +19,17 @@ Linux內核開發人員非常重視安全性。因此我們想知道何時發現
 -----
 
 可以通過電子郵件<security@kernel.org>聯繫Linux內核安全團隊。這是一個安全人員
-的私有列表，他們將幫助驗證錯誤報告並開發和發布修復程序。如果您已經有了一個
+的私有列表，他們將幫助驗證錯誤報告並開發和發佈修復程序。如果您已經有了一個
 修復，請將其包含在您的報告中，這樣可以大大加快進程。安全團隊可能會從區域維護
-人員那裡獲得額外的幫助，以理解和修復安全漏洞。
+人員那裏獲得額外的幫助，以理解和修復安全漏洞。
 
 與任何缺陷一樣，提供的信息越多，診斷和修復就越容易。如果您不清楚哪些信息有用，
-請查看「Documentation/translations/zh_TW/admin-guide/reporting-issues.rst」中
+請查看“Documentation/translations/zh_CN/admin-guide/reporting-issues.rst”中
 概述的步驟。任何利用漏洞的攻擊代碼都非常有用，未經報告者同意不會對外發布，除
 非已經公開。
 
-請儘可能發送無附件的純文本電子郵件。如果所有的細節都藏在附件里，那麼就很難對
-一個複雜的問題進行上下文引用的討論。把它想像成一個
+請儘可能發送無附件的純文本電子郵件。如果所有的細節都藏在附件裏，那麼就很難對
+一個複雜的問題進行上下文引用的討論。把它想象成一個
 :doc:`常規的補丁提交 <../process/submitting-patches>` （即使你還沒有補丁）：
 描述問題和影響，列出復現步驟，然後給出一個建議的解決方案，所有這些都是純文本的。
 
@@ -38,15 +38,15 @@ Linux內核開發人員非常重視安全性。因此我們想知道何時發現
 
 安全列表不是公開渠道。爲此，請參見下面的協作。
 
-一旦開發出了健壯的補丁，發布過程就開始了。對公開的缺陷的修復會立即發布。
+一旦開發出了健壯的補丁，發佈過程就開始了。對公開的缺陷的修復會立即發佈。
 
-儘管我們傾向於在未公開缺陷的修復可用時即發布補丁，但應報告者或受影響方的請求，
-這可能會被推遲到發布過程開始後的7日內，如果根據缺陷的嚴重性需要更多的時間，
-則可額外延長到14天。推遲發布修復的唯一有效原因是爲了適應QA的邏輯和需要發布
+儘管我們傾向於在未公開缺陷的修復可用時即發佈補丁，但應報告者或受影響方的請求，
+這可能會被推遲到發佈過程開始後的7日內，如果根據缺陷的嚴重性需要更多的時間，
+則可額外延長到14天。推遲發佈修復的唯一有效原因是爲了適應QA的邏輯和需要發佈
 協調的大規模部署。
 
 雖然可能與受信任的個人共享受限信息以開發修復，但未經報告者許可，此類信息不會
-與修復程序一起發布或發布在任何其他披露渠道上。這包括但不限於原始錯誤報告和
+與修復程序一起發佈或發佈在任何其他披露渠道上。這包括但不限於原始錯誤報告和
 後續討論（如有）、漏洞、CVE信息或報告者的身份。
 
 換句話說，我們唯一感興趣的是修復缺陷。提交給安全列表的所有其他資料以及對報告
@@ -57,10 +57,10 @@ Linux內核開發人員非常重視安全性。因此我們想知道何時發現
 
 對敏感缺陷（例如那些可能導致權限提升的缺陷）的修復可能需要與私有郵件列表
 <linux-distros@vs.openwall.org>進行協調，以便分發供應商做好準備，在公開披露
-上游補丁時發布一個已修復的內核。發行版將需要一些時間來測試建議的補丁，通常
-會要求至少幾天的限制，而供應商更新發布更傾向於周二至周四。若合適，安全團隊
+上游補丁時發佈一個已修復的內核。發行版將需要一些時間來測試建議的補丁，通常
+會要求至少幾天的限制，而供應商更新發布更傾向於週二至週四。若合適，安全團隊
 可以協助這種協調，或者報告者可以從一開始就包括linux發行版。在這種情況下，請
-記住在電子郵件主題行前面加上「[vs]」，如linux發行版wiki中所述：
+記住在電子郵件主題行前面加上“[vs]”，如linux發行版wiki中所述：
 <http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists>。
 
 CVE分配

Documentation/translations/zh_TW/admin-guide/unicode.rst

@@ -37,15 +37,15 @@ IBMPC_MAP       IBM code page 437               ESC ( U
 USER_MAP        User defined                    ESC ( K
 =============== =============================== ================
 
-特別是 ESC ( U 不再是「直通字體」，因爲字體可能與IBM字符集完全不同。
+特別是 ESC ( U 不再是“直通字體”，因爲字體可能與IBM字符集完全不同。
 例如，即使加載了一個Latin-1字體，也允許使用塊圖形（block graphics）。
 
 請注意，儘管這些代碼與ISO 2022類似，但這些代碼及其用途都與ISO 2022不匹配；
 Linux有兩個八位代碼（G0和G1），而ISO 2022有四個七位代碼（G0-G3）。
 
-根據Unicode標準/ISO 10646，U+F000到U+F8FF被保留用於作業系統範圍內的分配
-（Unicode標準將其稱爲「團體區域（Corporate Zone）」，因爲這對於Linux是不準確
-的，所以我們稱之爲「Linux區域」）。選擇U+F000作爲起點，因爲它允許直接映射
+根據Unicode標準/ISO 10646，U+F000到U+F8FF被保留用於操作系統範圍內的分配
+（Unicode標準將其稱爲“團體區域（Corporate Zone）”，因爲這對於Linux是不準確
+的，所以我們稱之爲“Linux區域”）。選擇U+F000作爲起點，因爲它允許直接映射
 區域以2的大倍數開始（以防需要1024或2048個字符的字體）。這就留下U+E000到
 U+EFFF作爲最終用戶區。
 
@@ -87,7 +87,7 @@ U+F813 KEYBOARD SYMBOL SOLID APPLE
 克林貢（Klingon）語支持
 ------------------------
 
-1996年，Linux是世界上第一個添加對人工語言克林貢支持的作業系統，克林貢是由
+1996年，Linux是世界上第一個添加對人工語言克林貢支持的操作系統，克林貢是由
 Marc Okrand爲《星際迷航》電視連續劇創造的。這種編碼後來被徵募Unicode註冊表
 （ConScript Unicode Registry，CSUR）採用，並建議（但最終被拒絕）納入Unicode
 平面一。不過，它仍然是Linux區域中的Linux/CSUR私有分配。

Documentation/translations/zh_TW/arch/arm/Booting

+Chinese translated version of Documentation/arch/arm/booting.rst
+
+If you have any comment or update to the content, please contact the
+original document maintainer directly.  However, if you have a problem
+communicating in English you can also ask the Chinese maintainer for
+help.  Contact the Chinese maintainer if this translation is outdated
+or if there is a problem with the translation.
+
+Maintainer: Russell King <linux@arm.linux.org.uk>
+Chinese maintainer: Fu Wei <tekkamanninja@gmail.com>
+---------------------------------------------------------------------
+Documentation/arch/arm/booting.rst 的中文翻譯
+
+如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文
+交流有困難的話，也可以向中文版維護者求助。如果本翻譯更新不及時或者翻
+譯存在問題，請聯繫中文版維護者。
+
+英文版維護者： Russell King <linux@arm.linux.org.uk>
+中文版維護者： 傅煒  Fu Wei <tekkamanninja@gmail.com>
+中文版翻譯者： 傅煒  Fu Wei <tekkamanninja@gmail.com>
+中文版校譯者： 傅煒  Fu Wei <tekkamanninja@gmail.com>
+
+以下爲正文
+---------------------------------------------------------------------
+
+			啓動 ARM Linux
+			==============
+
+作者：Russell King
+日期：2002年5月18日
+
+以下文檔適用於 2.4.18-rmk6 及以上版本。
+
+爲了啓動 ARM Linux，你需要一個引導裝載程序（boot loader），
+它是一個在主內核啓動前運行的一個小程序。引導裝載程序需要初始化各種
+設備，並最終調用 Linux 內核，將信息傳遞給內核。
+
+從本質上講，引導裝載程序應提供（至少）以下功能：
+
+1、設置和初始化 RAM。
+2、初始化一個串口。
+3、檢測機器的類型（machine type）。
+4、設置內核標籤列表（tagged list）。
+5、調用內核映像。
+
+
+1、設置和初始化 RAM
+-------------------
+
+現有的引導加載程序:		強制
+新開發的引導加載程序:		強制
+
+引導裝載程序應該找到並初始化系統中所有內核用於保持系統變量數據的 RAM。
+這個操作的執行是設備依賴的。（它可能使用內部算法來自動定位和計算所有
+RAM，或可能使用對這個設備已知的 RAM 信息，還可能使用任何引導裝載程序
+設計者想到的匹配方法。）
+
+
+2、初始化一個串口
+-----------------------------
+
+現有的引導加載程序:		可選、建議
+新開發的引導加載程序:		可選、建議
+
+引導加載程序應該初始化並使能一個目標板上的串口。這允許內核串口驅動
+自動檢測哪個串口用於內核控制檯。(一般用於調試或與目標板通信。)
+
+作爲替代方案，引導加載程序也可以通過標籤列表傳遞相關的'console='
+選項給內核以指定某個串口，而串口數據格式的選項在以下文檔中描述：
+
+       Documentation/admin-guide/kernel-parameters.rst。
+
+
+3、檢測機器類型
+--------------------------
+
+現有的引導加載程序:		可選
+新開發的引導加載程序:		強制
+
+引導加載程序應該通過某些方式檢測自身所處的機器類型。這是一個硬件
+代碼或通過查看所連接的硬件用某些算法得到，這些超出了本文檔的範圍。
+引導加載程序最終必須能提供一個 MACH_TYPE_xxx 值給內核。
+(詳見 linux/arch/arm/tools/mach-types )。
+
+4、設置啓動數據
+------------------
+
+現有的引導加載程序:		可選、強烈建議
+新開發的引導加載程序:		強制
+
+引導加載程序必須提供標籤列表或者 dtb 映像以傳遞配置數據給內核。啓動
+數據的物理地址通過寄存器 r2 傳遞給內核。
+
+4a、設置內核標籤列表
+--------------------------------
+
+bootloader 必須創建和初始化內核標籤列表。一個有效的標籤列表以
+ATAG_CORE 標籤開始，並以 ATAG_NONE 標籤結束。ATAG_CORE 標籤可以是
+空的，也可以是非空。一個空 ATAG_CORE 標籤其 size 域設置爲
+‘2’(0x00000002)。ATAG_NONE 標籤的 size 域必須設置爲零。
+
+在列表中可以保存任意數量的標籤。對於一個重複的標籤是追加到之前標籤
+所攜帶的信息之後，還是會覆蓋原來的信息，是未定義的。某些標籤的行爲
+是前者，其他是後者。
+
+bootloader 必須傳遞一個系統內存的位置和最小值，以及根文件系統位置。
+因此，最小的標籤列表如下所示：
+
+		+-----------+
+基地址 ->	| ATAG_CORE |  |
+		+-----------+  |
+		| ATAG_MEM  |  | 地址增長方向
+		+-----------+  |
+		| ATAG_NONE |  |
+		+-----------+  v
+
+標籤列表應該保存在系統的 RAM 中。
+
+標籤列表必須置於內核自解壓和 initrd'bootp' 程序都不會覆蓋的內存區。
+建議放在 RAM 的頭 16KiB 中。
+
+4b、設置設備樹
+-------------------------
+
+bootloader 必須以 64bit 地址對齊的形式加載一個設備樹映像(dtb)到系統
+RAM 中，並用啓動數據初始化它。dtb 格式在文檔
+https://www.devicetree.org/specifications/ 中。內核將會在
+dtb 物理地址處查找 dtb 魔數值（0xd00dfeed），以確定 dtb 是否已經代替
+標籤列表被傳遞進來。
+
+bootloader 必須傳遞一個系統內存的位置和最小值，以及根文件系統位置。
+dtb 必須置於內核自解壓不會覆蓋的內存區。建議將其放置於 RAM 的頭 16KiB
+中。但是不可將其放置於“0”物理地址處，因爲內核認爲：r2 中爲 0，意味着
+沒有標籤列表和 dtb 傳遞過來。
+
+5、調用內核映像
+---------------------------
+
+現有的引導加載程序:		強制
+新開發的引導加載程序:		強制
+
+調用內核映像 zImage 有兩個選擇。如果 zImge 保存在 flash 中，且是爲了
+在 flash 中直接運行而被正確鏈接的。這樣引導加載程序就可以在 flash 中
+直接調用 zImage。
+
+zImage 也可以被放在系統 RAM（任意位置）中被調用。注意：內核使用映像
+基地址的前 16KB RAM 空間來保存頁表。建議將映像置於 RAM 的 32KB 處。
+
+對於以上任意一種情況，都必須符合以下啓動狀態：
+
+- 停止所有 DMA 設備，這樣內存數據就不會因爲虛假網絡包或磁盤數據而被破壞。
+  這可能可以節省你許多的調試時間。
+
+- CPU 寄存器配置
+  r0 = 0，
+  r1 = （在上面 3 中獲取的）機器類型碼。
+  r2 = 標籤列表在系統 RAM 中的物理地址，或
+       設備樹塊(dtb)在系統 RAM 中的物理地址
+
+- CPU 模式
+  所有形式的中斷必須被禁止 (IRQs 和 FIQs)
+  CPU 必須處於 SVC 模式。(對於 Angel 調試有特例存在)
+
+- 緩存，MMUs
+  MMU 必須關閉。
+  指令緩存開啓或關閉都可以。
+  數據緩存必須關閉。
+
+- 引導加載程序應該通過直接跳轉到內核映像的第一條指令來調用內核映像。
+
+  對於支持 ARM 指令集的 CPU，跳入內核入口時必須處在 ARM 狀態，即使
+  對於 Thumb-2 內核也是如此。
+
+  對於僅支持 Thumb 指令集的 CPU，比如 Cortex-M 系列的 CPU，跳入
+  內核入口時必須處於 Thumb 狀態。
+

Documentation/translations/zh_TW/arch/arm/kernel_user_helpers.txt

+Chinese translated version of Documentation/arch/arm/kernel_user_helpers.rst
+
+If you have any comment or update to the content, please contact the
+original document maintainer directly.  However, if you have a problem
+communicating in English you can also ask the Chinese maintainer for
+help.  Contact the Chinese maintainer if this translation is outdated
+or if there is a problem with the translation.
+
+Maintainer: Nicolas Pitre <nicolas.pitre@linaro.org>
+		Dave Martin <dave.martin@linaro.org>
+Chinese maintainer: Fu Wei <tekkamanninja@gmail.com>
+---------------------------------------------------------------------
+Documentation/arch/arm/kernel_user_helpers.rst 的中文翻譯
+
+如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文
+交流有困難的話，也可以向中文版維護者求助。如果本翻譯更新不及時或者翻
+譯存在問題，請聯繫中文版維護者。
+英文版維護者： Nicolas Pitre <nicolas.pitre@linaro.org>
+		Dave Martin <dave.martin@linaro.org>
+中文版維護者： 傅煒 Fu Wei <tekkamanninja@gmail.com>
+中文版翻譯者： 傅煒 Fu Wei <tekkamanninja@gmail.com>
+中文版校譯者： 宋冬生 Dongsheng Song <dongshneg.song@gmail.com>
+		傅煒 Fu Wei <tekkamanninja@gmail.com>
+
+
+以下爲正文
+---------------------------------------------------------------------
+內核提供的用戶空間輔助代碼
+=========================
+
+在內核內存空間的固定地址處，有一個由內核提供並可從用戶空間訪問的代碼
+段。它用於向用戶空間提供因在許多 ARM CPU 中未實現的特性和/或指令而需
+內核提供幫助的某些操作。這些代碼直接在用戶模式下執行的想法是爲了獲得
+最佳效率，但那些與內核計數器聯繫過於緊密的部分，則被留給了用戶庫實現。
+事實上，此代碼甚至可能因不同的 CPU 而異，這取決於其可用的指令集或它
+是否爲 SMP 系統。換句話說，內核保留在不作出警告的情況下根據需要更改
+這些代碼的權利。只有本文檔描述的入口及其結果是保證穩定的。
+
+這與完全成熟的 VDSO 實現不同（但兩者並不衝突），儘管如此，VDSO 可阻止
+某些通過常量高效跳轉到那些代碼段的彙編技巧。且由於那些代碼段在返回用戶
+代碼前僅使用少量的代碼週期，則一個 VDSO 間接遠程調用將會在這些簡單的
+操作上增加一個可測量的開銷。
+
+在對那些擁有原生支持的新型處理器進行代碼優化時，僅在已爲其他操作使用
+了類似的新增指令，而導致二進制結果已與早期 ARM 處理器不兼容的情況下，
+用戶空間才應繞過這些輔助代碼，並在內聯函數中實現這些操作（無論是通過
+編譯器在代碼中直接放置，還是作爲庫函數調用實現的一部分）。也就是說，
+如果你編譯的代碼不會爲了其他目的使用新指令，則不要僅爲了避免使用這些
+內核輔助代碼，導致二進制程序無法在早期處理器上運行。
+
+新的輔助代碼可能隨着時間的推移而增加，所以新內核中的某些輔助代碼在舊
+內核中可能不存在。因此，程序必須在對任何輔助代碼調用假設是安全之前，
+檢測 __kuser_helper_version 的值（見下文）。理想情況下，這種檢測應該
+只在進程啓動時執行一次；如果內核版本不支持所需輔助代碼，則該進程可儘早
+中止執行。
+
+kuser_helper_version
+--------------------
+
+位置:	0xffff0ffc
+
+參考聲明:
+
+  extern int32_t __kuser_helper_version;
+
+定義:
+
+  這個區域包含了當前運行內核實現的輔助代碼版本號。用戶空間可以通過讀
+  取此版本號以確定特定的輔助代碼是否存在。
+
+使用範例:
+
+#define __kuser_helper_version (*(int32_t *)0xffff0ffc)
+
+void check_kuser_version(void)
+{
+	if (__kuser_helper_version < 2) {
+		fprintf(stderr, "can't do atomic operations, kernel too old\n");
+		abort();
+	}
+}
+
+注意:
+
+  用戶空間可以假設這個域的值不會在任何單個進程的生存期內改變。也就
+  是說，這個域可以僅在庫的初始化階段或進程啓動階段讀取一次。
+
+kuser_get_tls
+-------------
+
+位置:	0xffff0fe0
+
+參考原型:
+
+  void * __kuser_get_tls(void);
+
+輸入:
+
+  lr = 返回地址
+
+輸出:
+
+  r0 = TLS 值
+
+被篡改的寄存器:
+
+  無
+
+定義:
+
+  獲取之前通過 __ARM_NR_set_tls 系統調用設置的 TLS 值。
+
+使用範例:
+
+typedef void * (__kuser_get_tls_t)(void);
+#define __kuser_get_tls (*(__kuser_get_tls_t *)0xffff0fe0)
+
+void foo()
+{
+	void *tls = __kuser_get_tls();
+	printf("TLS = %p\n", tls);
+}
+
+注意:
+
+  - 僅在 __kuser_helper_version >= 1 時，此輔助代碼存在
+    （從內核版本 2.6.12 開始）。
+
+kuser_cmpxchg
+-------------
+
+位置:	0xffff0fc0
+
+參考原型:
+
+  int __kuser_cmpxchg(int32_t oldval, int32_t newval, volatile int32_t *ptr);
+
+輸入:
+
+  r0 = oldval
+  r1 = newval
+  r2 = ptr
+  lr = 返回地址
+
+輸出:
+
+  r0 = 成功代碼 (零或非零)
+  C flag = 如果 r0 == 0 則置 1，如果 r0 != 0 則清零。
+
+被篡改的寄存器:
+
+  r3, ip, flags
+
+定義:
+
+  僅在 *ptr 爲 oldval 時原子保存 newval 於 *ptr 中。
+  如果 *ptr 被改變，則返回值爲零，否則爲非零值。
+  如果 *ptr 被改變，則 C flag 也會被置 1，以實現調用代碼中的彙編
+  優化。
+
+使用範例:
+
+typedef int (__kuser_cmpxchg_t)(int oldval, int newval, volatile int *ptr);
+#define __kuser_cmpxchg (*(__kuser_cmpxchg_t *)0xffff0fc0)
+
+int atomic_add(volatile int *ptr, int val)
+{
+	int old, new;
+
+	do {
+		old = *ptr;
+		new = old + val;
+	} while(__kuser_cmpxchg(old, new, ptr));
+
+	return new;
+}
+
+注意:
+
+  - 這個例程已根據需要包含了內存屏障。
+
+  - 僅在 __kuser_helper_version >= 2 時，此輔助代碼存在
+    （從內核版本 2.6.12 開始）。
+
+kuser_memory_barrier
+--------------------
+
+位置:	0xffff0fa0
+
+參考原型:
+
+  void __kuser_memory_barrier(void);
+
+輸入:
+
+  lr = 返回地址
+
+輸出:
+
+  無
+
+被篡改的寄存器:
+
+  無
+
+定義:
+
+  應用於任何需要內存屏障以防止手動數據修改帶來的一致性問題，以及
+  __kuser_cmpxchg 中。
+
+使用範例:
+
+typedef void (__kuser_dmb_t)(void);
+#define __kuser_dmb (*(__kuser_dmb_t *)0xffff0fa0)
+
+注意:
+
+  - 僅在 __kuser_helper_version >= 3 時，此輔助代碼存在
+    （從內核版本 2.6.15 開始）。
+
+kuser_cmpxchg64
+---------------
+
+位置:	0xffff0f60
+
+參考原型:
+
+  int __kuser_cmpxchg64(const int64_t *oldval,
+                        const int64_t *newval,
+                        volatile int64_t *ptr);
+
+輸入:
+
+  r0 = 指向 oldval
+  r1 = 指向 newval
+  r2 = 指向目標值
+  lr = 返回地址
+
+輸出:
+
+  r0 = 成功代碼 (零或非零)
+  C flag = 如果 r0 == 0 則置 1，如果 r0 != 0 則清零。
+
+被篡改的寄存器:
+
+  r3, lr, flags
+
+定義:
+
+  僅在 *ptr 等於 *oldval 指向的 64 位值時，原子保存 *newval
+  指向的 64 位值於 *ptr 中。如果 *ptr 被改變，則返回值爲零，
+  否則爲非零值。
+
+  如果 *ptr 被改變，則 C flag 也會被置 1，以實現調用代碼中的彙編
+  優化。
+
+使用範例:
+
+typedef int (__kuser_cmpxchg64_t)(const int64_t *oldval,
+                                  const int64_t *newval,
+                                  volatile int64_t *ptr);
+#define __kuser_cmpxchg64 (*(__kuser_cmpxchg64_t *)0xffff0f60)
+
+int64_t atomic_add64(volatile int64_t *ptr, int64_t val)
+{
+	int64_t old, new;
+
+	do {
+		old = *ptr;
+		new = old + val;
+	} while(__kuser_cmpxchg64(&old, &new, ptr));
+
+	return new;
+}
+
+注意:
+
+  - 這個例程已根據需要包含了內存屏障。
+
+  - 由於這個過程的代碼長度（此輔助代碼跨越 2 個常規的 kuser “槽”），
+    因此 0xffff0f80 不被作爲有效的入口點。
+
+  - 僅在 __kuser_helper_version >= 5 時，此輔助代碼存在
+    （從內核版本 3.1 開始）。
+

Documentation/translations/zh_TW/arch/arm64/amu.rst

@@ -28,11 +28,11 @@ AArch64 Linux 中擴展的活動監控單元
 
 AMUv1 架構實現了一個由4個固定的64位事件計數器組成的計數器組。
 
-  - CPU 周期計數器：同 CPU 的頻率增長
+  - CPU 週期計數器：同 CPU 的頻率增長
   - 常量計數器：同固定的系統時鐘頻率增長
   - 淘汰指令計數器: 同每次架構指令執行增長
-  - 內存停頓周期計數器：計算由在時鐘域內的最後一級緩存中未命中而引起
-    的指令調度停頓周期數
+  - 內存停頓週期計數器：計算由在時鐘域內的最後一級緩存中未命中而引起
+    的指令調度停頓週期數
 
 當處於 WFI 或者 WFE 狀態時，計數器不會增長。
 

Documentation/translations/zh_TW/arch/arm64/booting.txt

@@ -41,8 +41,8 @@ AArch64 異常模型由多個異常級（EL0 - EL3）組成，對於 EL0 和 EL1
 有對應的安全和非安全模式。EL2 是系統管理級，且僅存在於非安全模式下。
 EL3 是最高特權級，且僅存在於安全模式下。
 
-基於本文檔的目的，我們將簡單地使用『引導裝載程序』（『boot loader』）
-這個術語來定義在將控制權交給 Linux 內核前 CPU 上執行的所有軟體。
+基於本文檔的目的，我們將簡單地使用‘引導裝載程序’（‘boot loader’）
+這個術語來定義在將控制權交給 Linux 內核前 CPU 上執行的所有軟件。
 這可能包含安全監控和系統管理代碼，或者它可能只是一些用於準備最小啓動
 環境的指令。
 
@@ -74,7 +74,7 @@ RAM，或可能使用對這個設備已知的 RAM 信息，還可能是引導裝
 數據塊將在使能緩存的情況下以 2MB 粒度被映射，故其不能被置於必須以特定
 屬性映射的2M區域內。
 
-註： v4.2 之前的版本同時要求設備樹數據塊被置於從內核映像以下
+注： v4.2 之前的版本同時要求設備樹數據塊被置於從內核映像以下
 text_offset 字節處算起第一個 512MB 內。
 
 3、解壓內核映像
@@ -106,7 +106,7 @@ AArch64 內核當前沒有提供自解壓代碼，因此如果使用了壓縮內
   u32 res5;			/* 保留 （用於 PE COFF 偏移） */
 
 
-映像頭注釋：
+映像頭註釋：
 
 - 自 v3.17 起，除非另有說明，所有域都是小端模式。
 
@@ -143,7 +143,7 @@ AArch64 內核當前沒有提供自解壓代碼，因此如果使用了壓縮內
 字節處，並從該處被調用。2MB 對齊基址和內核映像起始地址之間的區域對於
 內核來說沒有特殊意義，且可能被用於其他目的。
 從映像起始地址算起，最少必須準備 image_size 字節的空閒內存供內核使用。
-註： v4.6 之前的版本無法使用內核映像物理偏移以下的內存，所以當時建議
+注： v4.6 之前的版本無法使用內核映像物理偏移以下的內存，所以當時建議
 將映像儘量放置在靠近系統內存起始的地方。
 
 任何提供給內核的內存（甚至在映像起始地址之前），若未從內核中標記爲保留
@@ -151,7 +151,7 @@ AArch64 內核當前沒有提供自解壓代碼，因此如果使用了壓縮內
 
 在跳轉入內核前，必須符合以下狀態：
 
-- 停止所有 DMA 設備，這樣內存數據就不會因爲虛假網絡包或磁碟數據而
+- 停止所有 DMA 設備，這樣內存數據就不會因爲虛假網絡包或磁盤數據而
   被破壞。這可能可以節省你許多的調試時間。
 
 - 主 CPU 通用寄存器設置
@@ -175,7 +175,7 @@ AArch64 內核當前沒有提供自解壓代碼，因此如果使用了壓縮內
   而不通過虛擬地址操作維護構架緩存的系統緩存（不推薦），必須被配置且
   禁用。
 
-  *譯者註：對於 PoC 以及緩存相關內容，請參考 ARMv8 構架參考手冊
+  *譯者注：對於 PoC 以及緩存相關內容，請參考 ARMv8 構架參考手冊
    ARM DDI 0487A
 
 - 架構計時器
@@ -189,7 +189,7 @@ AArch64 內核當前沒有提供自解壓代碼，因此如果使用了壓縮內
   接收。
 
 - 系統寄存器
-  在進入內核映像的異常級中，所有構架中可寫的系統寄存器必須通過軟體
+  在進入內核映像的異常級中，所有構架中可寫的系統寄存器必須通過軟件
   在一個更高的異常級別下初始化，以防止在 未知 狀態下運行。
 
   對於擁有 GICv3 中斷控制器並以 v3 模式運行的系統：
@@ -214,14 +214,14 @@ AArch64 內核當前沒有提供自解壓代碼，因此如果使用了壓縮內
 引導裝載程序必須在每個 CPU 處於以下狀態時跳入內核入口：
 
 - 主 CPU 必須直接跳入內核映像的第一條指令。通過此 CPU 傳遞的設備樹
-  數據塊必須在每個 CPU 節點中包含一個 『enable-method』 屬性，所
+  數據塊必須在每個 CPU 節點中包含一個 ‘enable-method’ 屬性，所
   支持的 enable-method 請見下文。
 
   引導裝載程序必須生成這些設備樹屬性，並在跳入內核入口之前將其插入
   數據塊。
 
-- enable-method 爲 「spin-table」 的 CPU 必須在它們的 CPU
-  節點中包含一個 『cpu-release-addr』 屬性。這個屬性標識了一個
+- enable-method 爲 “spin-table” 的 CPU 必須在它們的 CPU
+  節點中包含一個 ‘cpu-release-addr’ 屬性。這個屬性標識了一個
   64 位自然對齊且初始化爲零的內存位置。
 
   這些 CPU 必須在內存保留區（通過設備樹中的 /memreserve/ 域傳遞
@@ -231,15 +231,15 @@ AArch64 內核當前沒有提供自解壓代碼，因此如果使用了壓縮內
   時，CPU 必須跳入此值所指向的地址。此值爲一個單獨的 64 位小端值，
   因此 CPU 須在跳轉前將所讀取的值轉換爲其本身的端模式。
 
-- enable-method 爲 「psci」 的 CPU 保持在內核外（比如，在
+- enable-method 爲 “psci” 的 CPU 保持在內核外（比如，在
   memory 節點中描述爲內核空間的內存區外，或在通過設備樹 /memreserve/
   域中描述爲內核保留區的空間中）。內核將會發起在 ARM 文檔（編號
-  ARM DEN 0022A：用於 ARM 上的電源狀態協調接口系統軟體）中描述的
+  ARM DEN 0022A：用於 ARM 上的電源狀態協調接口系統軟件）中描述的
   CPU_ON 調用來將 CPU 帶入內核。
 
   *譯者注: ARM DEN 0022A 已更新到 ARM DEN 0022C。
 
-  設備樹必須包含一個 『psci』 節點，請參考以下文檔：
+  設備樹必須包含一個 ‘psci’ 節點，請參考以下文檔：
   Documentation/devicetree/bindings/arm/psci.yaml
 
 

Documentation/translations/zh_TW/arch/arm64/elf_hwcaps.rst

@@ -17,11 +17,11 @@ ARM64 ELF hwcaps
 1. 簡介
 -------
 
-有些硬體或軟體功能僅在某些 CPU 實現上和/或在具體某個內核配置上可用，但
+有些硬件或軟件功能僅在某些 CPU 實現上和/或在具體某個內核配置上可用，但
 對於處於 EL0 的用戶空間代碼沒有可用的架構發現機制。內核通過在輔助向量表
 公開一組稱爲 hwcaps 的標誌而把這些功能暴露給用戶空間。
 
-用戶空間軟體可以通過獲取輔助向量的 AT_HWCAP 或 AT_HWCAP2 條目來測試功能，
+用戶空間軟件可以通過獲取輔助向量的 AT_HWCAP 或 AT_HWCAP2 條目來測試功能，
 並測試是否設置了相關標誌，例如::
 
 	bool floating_point_is_present(void)
@@ -33,7 +33,7 @@ ARM64 ELF hwcaps
 		return false;
 	}
 
-如果軟體依賴於 hwcap 描述的功能，在嘗試使用該功能前則應檢查相關的 hwcap
+如果軟件依賴於 hwcap 描述的功能，在嘗試使用該功能前則應檢查相關的 hwcap
 標誌以驗證該功能是否存在。
 
 不能通過其他方式探查這些功能。當一個功能不可用時，嘗試使用它可能導致不可
@@ -44,8 +44,8 @@ ARM64 ELF hwcaps
 ----------------
 
 大多數 hwcaps 旨在說明通過架構 ID 寄存器(處於 EL0 的用戶空間代碼無法訪問)
-描述的功能的存在。這些 hwcap 通過 ID 寄存器欄位定義，並且應根據 ARM 體系
-結構參考手冊（ARM ARM）中定義的欄位來解釋說明。
+描述的功能的存在。這些 hwcap 通過 ID 寄存器字段定義，並且應根據 ARM 體系
+結構參考手冊（ARM ARM）中定義的字段來解釋說明。
 
 這些 hwcaps 以下面的形式描述::
 

Documentation/translations/zh_TW/arch/arm64/legacy_instructions.txt

@@ -31,7 +31,7 @@ Documentation/arch/arm64/legacy_instructions.rst 的中文翻譯
 以下爲正文
 ---------------------------------------------------------------------
 Linux 內核在 arm64 上的移植提供了一個基礎框架，以支持構架中正在被淘汰或已廢棄指令的模擬執行。
-這個基礎框架的代碼使用未定義指令鉤子（hooks）來支持模擬。如果指令存在，它也允許在硬體中啓用該指令。
+這個基礎框架的代碼使用未定義指令鉤子（hooks）來支持模擬。如果指令存在，它也允許在硬件中啓用該指令。
 
 模擬模式可通過寫 sysctl 節點（/proc/sys/abi）來控制。
 不同的執行方式及 sysctl 節點的相應值，解釋如下：
@@ -42,18 +42,18 @@ Linux 內核在 arm64 上的移植提供了一個基礎框架，以支持構架
 
 * Emulate（模擬）
   值： 1
-  使用軟體模擬方式。爲解決軟體遷移問題，這種模擬指令模式的使用是被跟蹤的，並會發出速率限制警告。
+  使用軟件模擬方式。爲解決軟件遷移問題，這種模擬指令模式的使用是被跟蹤的，並會發出速率限制警告。
   它是那些構架中正在被淘汰的指令，如 CP15 barriers（隔離指令），的默認處理方式。
 
-* Hardware Execution（硬體執行）
+* Hardware Execution（硬件執行）
   值： 2
-  雖然標記爲正在被淘汰，但一些實現可能提供硬體執行這些指令的使能/禁用操作。
-  使用硬體執行一般會有更好的性能，但將無法收集運行時對正被淘汰指令的使用統計數據。
+  雖然標記爲正在被淘汰，但一些實現可能提供硬件執行這些指令的使能/禁用操作。
+  使用硬件執行一般會有更好的性能，但將無法收集運行時對正被淘汰指令的使用統計數據。
 
 默認執行模式依賴於指令在構架中狀態。正在被淘汰的指令應該以模擬（Emulate）作爲默認模式，
 而已廢棄的指令必須默認使用未定義（Undef）模式
 
-注意：指令模擬可能無法應對所有情況。更多詳情請參考單獨的指令注釋。
+注意：指令模擬可能無法應對所有情況。更多詳情請參考單獨的指令註釋。
 
 受支持的遺留指令
 -------------
@@ -71,7 +71,7 @@ Linux 內核在 arm64 上的移植提供了一個基礎框架，以支持構架
 節點: /proc/sys/abi/setend
 狀態: 正被淘汰，不推薦使用
 默認執行方式: Emulate (1)*
-註：爲了使能這個特性，系統中的所有 CPU 必須在 EL0 支持混合字節序。
+注：爲了使能這個特性，系統中的所有 CPU 必須在 EL0 支持混合字節序。
 如果一個新的 CPU （不支持混合字節序） 在使能這個特性後被熱插入系統，
 在應用中可能會出現不可預期的結果。
 

Documentation/translations/zh_TW/arch/arm64/memory.txt

@@ -28,17 +28,17 @@ Documentation/arch/arm64/memory.rst 的中文翻譯
 
 以下爲正文
 ---------------------------------------------------------------------
-		     Linux 在 AArch64 中的內存布局
+		     Linux 在 AArch64 中的內存佈局
 		     ===========================
 
 作者: Catalin Marinas <catalin.marinas@arm.com>
 
-本文檔描述 AArch64 Linux 內核所使用的虛擬內存布局。此構架可以實現
+本文檔描述 AArch64 Linux 內核所使用的虛擬內存佈局。此構架可以實現
 頁大小爲 4KB 的 4 級轉換表和頁大小爲 64KB 的 3 級轉換表。
 
 AArch64 Linux 使用 3 級或 4 級轉換表，其頁大小配置爲 4KB，對於用戶和內核
 分別都有 39-bit (512GB) 或 48-bit (256TB) 的虛擬地址空間。
-對於頁大小爲 64KB的配置，僅使用 2 級轉換表，有 42-bit (4TB) 的虛擬地址空間，但內存布局相同。
+對於頁大小爲 64KB的配置，僅使用 2 級轉換表，有 42-bit (4TB) 的虛擬地址空間，但內存佈局相同。
 
 用戶地址空間的 63:48 位爲 0，而內核地址空間的相應位爲 1。TTBRx 的
 選擇由虛擬地址的 63 位給出。swapper_pg_dir 僅包含內核（全局）映射，
@@ -46,7 +46,7 @@ AArch64 Linux 使用 3 級或 4 級轉換表，其頁大小配置爲 4KB，對
 TTBR1 中，且從不寫入 TTBR0。
 
 
-AArch64 Linux 在頁大小爲 4KB，並使用 3 級轉換表時的內存布局：
+AArch64 Linux 在頁大小爲 4KB，並使用 3 級轉換表時的內存佈局：
 
 起始地址			結束地址			大小		用途
 -----------------------------------------------------------------------
@@ -54,7 +54,7 @@ AArch64 Linux 在頁大小爲 4KB，並使用 3 級轉換表時的內存布局
 ffffff8000000000	ffffffffffffffff	 512GB		內核空間
 
 
-AArch64 Linux 在頁大小爲 4KB，並使用 4 級轉換表時的內存布局：
+AArch64 Linux 在頁大小爲 4KB，並使用 4 級轉換表時的內存佈局：
 
 起始地址			結束地址			大小		用途
 -----------------------------------------------------------------------
@@ -62,7 +62,7 @@ AArch64 Linux 在頁大小爲 4KB，並使用 4 級轉換表時的內存布局
 ffff000000000000	ffffffffffffffff	 256TB		內核空間
 
 
-AArch64 Linux 在頁大小爲 64KB，並使用 2 級轉換表時的內存布局：
+AArch64 Linux 在頁大小爲 64KB，並使用 2 級轉換表時的內存佈局：
 
 起始地址			結束地址			大小		用途
 -----------------------------------------------------------------------
@@ -70,7 +70,7 @@ AArch64 Linux 在頁大小爲 64KB，並使用 2 級轉換表時的內存布局
 fffffc0000000000	ffffffffffffffff	   4TB		內核空間
 
 
-AArch64 Linux 在頁大小爲 64KB，並使用 3 級轉換表時的內存布局：
+AArch64 Linux 在頁大小爲 64KB，並使用 3 級轉換表時的內存佈局：
 
 起始地址			結束地址			大小		用途
 -----------------------------------------------------------------------
@@ -78,7 +78,7 @@ AArch64 Linux 在頁大小爲 64KB，並使用 3 級轉換表時的內存布局
 ffff000000000000	ffffffffffffffff	 256TB		內核空間
 
 
-更詳細的內核虛擬內存布局，請參閱內核啓動信息。
+更詳細的內核虛擬內存佈局，請參閱內核啓動信息。
 
 
 4KB 頁大小的轉換表查找：

Documentation/translations/zh_TW/arch/arm64/perf.rst

@@ -59,7 +59,7 @@ EL2（VHE 內核 或 non-VHE 虛擬機監控器）。
 
 KVM 客戶機可能運行在 EL0（用戶空間）和 EL1（內核）。
 
-由於宿主機和客戶機之間重疊的異常級別，我們不能僅僅依靠 PMU 的硬體異
+由於宿主機和客戶機之間重疊的異常級別，我們不能僅僅依靠 PMU 的硬件異
 常過濾機制-因此我們必須啓用/禁用對於客戶機進入和退出的計數。而這在
 VHE 和 non-VHE 系統上表現不同。
 

Documentation/translations/zh_TW/arch/arm64/silicon-errata.txt

@@ -28,39 +28,39 @@ Documentation/arch/arm64/silicon-errata.rst 的中文翻譯
 
 以下爲正文
 ---------------------------------------------------------------------
-                晶片勘誤和軟體補救措施
+                芯片勘誤和軟件補救措施
                 ==================
 
 作者: Will Deacon <will.deacon@arm.com>
 日期: 2015年11月27日
 
-一個不幸的現實：硬體經常帶有一些所謂的「瑕疵（errata）」，導致其在
-某些特定情況下會違背構架定義的行爲。就基於 ARM 的硬體而言，這些瑕疵
+一個不幸的現實：硬件經常帶有一些所謂的“瑕疵（errata）”，導致其在
+某些特定情況下會違背構架定義的行爲。就基於 ARM 的硬件而言，這些瑕疵
 大體可分爲以下幾類：
 
   A 類：無可行補救措施的嚴重缺陷。
   B 類：有可接受的補救措施的重大或嚴重缺陷。
   C 類：在正常操作中不會顯現的小瑕疵。
 
-更多資訊，請在 infocenter.arm.com （需註冊）中查閱「軟體開發者勘誤
-筆記」（「Software Developers Errata Notice」）文檔。
+更多資訊，請在 infocenter.arm.com （需註冊）中查閱“軟件開發者勘誤
+筆記”（“Software Developers Errata Notice”）文檔。
 
-對於 Linux 而言，B 類缺陷可能需要作業系統的某些特別處理。例如，避免
+對於 Linux 而言，B 類缺陷可能需要操作系統的某些特別處理。例如，避免
 一個特殊的代碼序列，或是以一種特定的方式配置處理器。在某種不太常見的
 情況下，爲將 A 類缺陷當作 C 類處理，可能需要用類似的手段。這些手段被
-統稱爲「軟體補救措施」，且僅在少數情況需要（例如，那些需要一個運行在
+統稱爲“軟件補救措施”，且僅在少數情況需要（例如，那些需要一個運行在
 非安全異常級的補救措施 *並且* 能被 Linux 觸發的情況）。
 
-對於尚在討論中的可能對未受瑕疵影響的系統產生干擾的軟體補救措施，有一個
-相應的內核配置（Kconfig）選項被加在 「內核特性（Kernel Features）」->
-「基於可選方法框架的 ARM 瑕疵補救措施（ARM errata workarounds via
+對於尚在討論中的可能對未受瑕疵影響的系統產生干擾的軟件補救措施，有一個
+相應的內核配置（Kconfig）選項被加在 “內核特性（Kernel Features）”->
+“基於可選方法框架的 ARM 瑕疵補救措施（ARM errata workarounds via
 the alternatives framework）"。這些選項被默認開啓，若探測到受影響的CPU，
 補丁將在運行時被使用。至於對系統運行影響較小的補救措施，內核配置選項
-並不存在，且代碼以某種規避瑕疵的方式被構造（帶注釋爲宜）。
+並不存在，且代碼以某種規避瑕疵的方式被構造（帶註釋爲宜）。
 
-這種做法對於在任意內核原始碼樹中準確地判斷出哪個瑕疵已被軟體方法所補救
-稍微有點麻煩，所以在 Linux 內核中此文件作爲軟體補救措施的註冊表，
-並將在新的軟體補救措施被提交和向後移植（backported）到穩定內核時被更新。
+這種做法對於在任意內核源代碼樹中準確地判斷出哪個瑕疵已被軟件方法所補救
+稍微有點麻煩，所以在 Linux 內核中此文件作爲軟件補救措施的註冊表，
+並將在新的軟件補救措施被提交和向後移植（backported）到穩定內核時被更新。
 
 | 實現者         | 受影響的組件    | 勘誤編號        | 內核配置                |
 +----------------+-----------------+-----------------+-------------------------+

Documentation/translations/zh_TW/arch/arm64/tagged-pointers.txt

@@ -36,14 +36,14 @@ Documentation/arch/arm64/tagged-pointers.rst 的中文翻譯
 AArch64 Linux 中的潛在用途。
 
 內核提供的地址轉換表配置使通過 TTBR0 完成的虛擬地址轉換（即用戶空間
-映射），其虛擬地址的最高 8 位（63:56）會被轉換硬體所忽略。這種機制
-讓這些位可供應用程式自由使用，其注意事項如下：
+映射），其虛擬地址的最高 8 位（63:56）會被轉換硬件所忽略。這種機制
+讓這些位可供應用程序自由使用，其注意事項如下：
 
 	(1) 內核要求所有傳遞到 EL1 的用戶空間地址帶有 0x00 標記。
-	    這意味著任何攜帶用戶空間虛擬地址的系統調用（syscall）
+	    這意味着任何攜帶用戶空間虛擬地址的系統調用（syscall）
 	    參數 *必須* 在陷入內核前使它們的最高字節被清零。
 
-	(2) 非零標記在傳遞信號時不被保存。這意味著在應用程式中利用了
+	(2) 非零標記在傳遞信號時不被保存。這意味着在應用程序中利用了
 	    標記的信號處理函數無法依賴 siginfo_t 的用戶空間虛擬
 	    地址所攜帶的包含其內部域信息的標記。此規則的一個例外是
 	    當信號是在調試觀察點的異常處理程序中產生的，此時標記的
@@ -53,5 +53,5 @@ AArch64 Linux 中的潛在用途。
 	    的高字節，C 編譯器很可能無法判斷它們是不同的。
 
 此構架會阻止對帶標記的 PC 指針的利用，因此在異常返回時，其高字節
-將被設置成一個爲 「55」 的擴展符。
+將被設置成一個爲 “55” 的擴展符。
 

Documentation/translations/zh_TW/arch/index.rst

+.. SPDX-License-Identifier: GPL-2.0
+
+處理器體系結構
+==============
+
+以下文檔提供了具體架構實現的編程細節。
+
+.. toctree::
+   :maxdepth: 2
+
+   mips/index
+   arm64/index
+   openrisc/index
+   parisc/index
+   loongarch/index
+
+TODOList:
+
+* arm/index
+* m68k/index
+* nios2/index
+* powerpc/index
+* s390/index
+* sh/index
+* sparc/index
+* x86/index
+* xtensa/index
+* ../riscv/index
+

Documentation/translations/zh_TW/arch/loongarch/booting.rst

+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../../disclaimer-zh_TW.rst
+
+:Original: Documentation/arch/loongarch/booting.rst
+
+:翻譯:
+
+ 司延騰 Yanteng Si <siyanteng@loongson.cn>
+
+====================
+啓動 Linux/LoongArch
+====================
+
+:作者: 司延騰 <siyanteng@loongson.cn>
+:日期: 2022年11月18日
+
+BootLoader傳遞給內核的信息
+==========================
+
+LoongArch支持ACPI和FDT啓動，需要傳遞給內核的信息包括memmap、initrd、cmdline、可
+選的ACPI/FDT表等。
+
+內核在 `kernel_entry` 入口處被傳遞以下參數:
+
+      - a0 = efi_boot: `efi_boot` 是一個標誌，表示這個啓動環境是否完全符合UEFI
+        的要求。
+
+      - a1 = cmdline: `cmdline` 是一個指向內核命令行的指針。
+
+      - a2 = systemtable: `systemtable` 指向EFI的系統表，在這個階段涉及的所有
+        指針都是物理地址。
+
+Linux/LoongArch內核鏡像文件頭
+=============================
+
+內核鏡像是EFI鏡像。作爲PE文件，它們有一個64字節的頭部結構體，如下所示::
+
+	u32	MZ_MAGIC                /* "MZ", MS-DOS 頭 */
+	u32	res0 = 0                /* 保留 */
+	u64	kernel_entry            /* 內核入口點 */
+	u64	_end - _text            /* 內核鏡像有效大小 */
+	u64	load_offset             /* 加載內核鏡像相對內存起始地址的偏移量 */
+	u64	res1 = 0                /* 保留 */
+	u64	res2 = 0                /* 保留 */
+	u64	res3 = 0                /* 保留 */
+	u32	LINUX_PE_MAGIC          /* 魔術數 */
+	u32	pe_header - _head       /* 到PE頭的偏移量 */
+

Documentation/translations/zh_TW/arch/loongarch/features.rst

+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../../disclaimer-zh_TW.rst
+
+:Original: Documentation/arch/loongarch/features.rst
+:Translator: Huacai Chen <chenhuacai@loongson.cn>
+
+.. kernel-feat:: $srctree/Documentation/features loongarch
+

Documentation/translations/zh_TW/arch/loongarch/index.rst

+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../../disclaimer-zh_TW.rst
+
+:Original: Documentation/arch/loongarch/index.rst
+:Translator: Huacai Chen <chenhuacai@loongson.cn>
+
+=================
+LoongArch體系結構
+=================
+
+.. toctree::
+   :maxdepth: 2
+   :numbered:
+
+   introduction
+   booting
+   irq-chip-model
+
+   features
+
+.. only::  subproject and html
+
+   Indices
+   =======
+
+   * :ref:`genindex`
+

Documentation/translations/zh_TW/arch/mips/booting.rst

+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../../disclaimer-zh_TW.rst
+
+:Original: Documentation/arch/mips/booting.rst
+
+:翻譯:
+
+ 司延騰 Yanteng Si <siyanteng@loongson.cn>
+
+.. _tw_booting:
+
+BMIPS設備樹引導
+------------------------
+
+  一些bootloaders只支持在內核鏡像開始地址處的單一入口點。而其它
+  bootloaders將跳轉到ELF的開始地址處。兩種方案都支持的；因爲
+  CONFIG_BOOT_RAW=y and CONFIG_NO_EXCEPT_FILL=y, 所以第一條指令
+  會立即跳轉到kernel_entry()入口處執行。
+
+  與arch/arm情況(b)類似，dt感知的引導加載程序需要設置以下寄存器:
+
+         a0 : 0
+
+         a1 : 0xffffffff
+
+         a2 : RAM中指向設備樹塊的物理指針(在chapterII中定義)。
+              設備樹可以位於前512MB物理地址空間(0x00000000 -
+              0x1fffffff)的任何位置，以64位邊界對齊。
+
+  傳統bootloaders不會使用這樣的約定，並且它們不傳入DT塊。
+  在這種情況下，Linux將通過選中CONFIG_DT_*查找DTB。
+
+  以上約定只在32位系統中定義，因爲目前沒有任何64位的BMIPS實現。
+

Documentation/translations/zh_TW/arch/mips/features.rst

+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../../disclaimer-zh_TW.rst
+
+:Original: Documentation/arch/mips/features.rst
+
+:翻譯:
+
+ 司延騰 Yanteng Si <siyanteng@loongson.cn>
+
+.. _tw_features:
+
+.. kernel-feat:: $srctree/Documentation/features mips
+

Documentation/translations/zh_TW/arch/mips/index.rst

+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../../disclaimer-zh_TW.rst
+
+:Original: Documentation/arch/mips/index.rst
+
+:翻譯:
+
+ 司延騰 Yanteng Si <siyanteng@loongson.cn>
+
+===========================
+MIPS特性文檔
+===========================
+
+.. toctree::
+   :maxdepth: 2
+   :numbered:
+
+   booting
+   ingenic-tcu
+
+   features
+
+.. only::  subproject and html
+
+   Indices
+   =======
+
+   * :ref:`genindex`
+

Documentation/translations/zh_TW/arch/openrisc/index.rst

+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../../disclaimer-zh_TW.rst
+
+:Original: Documentation/arch/openrisc/index.rst
+
+:翻譯:
+
+ 司延騰 Yanteng Si <siyanteng@loongson.cn>
+
+.. _tw_openrisc_index:
+
+=================
+OpenRISC 體系架構
+=================
+
+.. toctree::
+   :maxdepth: 2
+
+   openrisc_port
+   todo
+
+Todolist:
+    features
+
+
+.. only::  subproject and html
+
+   Indices
+   =======
+
+   * :ref:`genindex`
+

Documentation/translations/zh_TW/arch/openrisc/todo.rst

+.. include:: ../../disclaimer-zh_TW.rst
+
+:Original: Documentation/arch/openrisc/todo.rst
+
+:翻譯:
+
+ 司延騰 Yanteng Si <siyanteng@loongson.cn>
+
+.. _tw_openrisc_todo.rst:
+
+========
+待辦事項
+========
+
+OpenRISC Linux的移植已經完全投入使用，並且從 2.6.35 開始就一直在上游同步。
+然而，還有一些剩餘的項目需要在未來幾個月內完成。 下面是一個即將進行調查的已知
+不盡完美的項目列表，即我們的待辦事項列表。
+
+-   實現其餘的DMA API……dma_map_sg等。
+
+-   完成重命名清理工作……代碼中提到了or32，這是架構的一個老名字。 我們
+    已經確定的名字是or1k，這個改變正在以緩慢積累的方式進行。 目前，or32相當
+    於or1k。
+