* [PATCH v3 0/6] docs/zh_TW: update zh_TW's documentation from an ascensive aspect
@ 2023-08-07 12:00 Hu Haowen
2023-08-07 12:00 ` [PATCH v3 2/6] docs/zh_TW: update arch Hu Haowen
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: Hu Haowen @ 2023-08-07 12:00 UTC (permalink / raw)
To: corbet; +Cc: Hu Haowen, linux-doc, linux-kernel
Update zh_TW's documentation concentrating on the following aspects:
* The file tree structure changes of the main documentation;
* Some changes and ideas from zh_CN translation;
* Removal for several obsoleted contents within the zh_TW translation
or those which are not exising anymore in the main documentation.
* Replacements for some incorrect words and phrases in traditional
Chinese or those which are odd within their context being hard for
readers to comprehend.
v3:
* Remove the fancy character thoroughly asked by Corbet.
v2:
* Remove the fancy character U+feff (ZERO WIDTH NO-BREAK SPACE) reported by Corbet
in https://lore.kernel.org/lkml/87bkg5dp6x.fsf@meer.lwn.net/.
v1:
https://lore.kernel.org/lkml/20230720132729.1821-1-src.res.211@gmail.com/
Hu Haowen (6):
docs/zh_TW: update admin-guide
docs/zh_TW: update arch
docs/zh_TW: update cpu-freq
docs/zh_TW: update filesystems
docs/zh_TW: update process
docs/zh_TW: turn zh_CN's folder references and headers into zh_TW's
ones
.../translations/zh_TW/admin-guide/README.rst | 166 ++--
.../zh_TW/admin-guide/bootconfig.rst | 294 +++++++
.../zh_TW/admin-guide/bug-bisect.rst | 12 +-
.../zh_TW/admin-guide/bug-hunting.rst | 40 +-
.../zh_TW/admin-guide/clearing-warn-once.rst | 6 +-
.../zh_TW/admin-guide/cpu-load.rst | 10 +-
.../zh_TW/admin-guide/cputopology.rst | 98 +++
.../translations/zh_TW/admin-guide/index.rst | 136 ++--
.../translations/zh_TW/admin-guide/init.rst | 38 +-
.../zh_TW/admin-guide/lockup-watchdogs.rst | 69 ++
.../zh_TW/admin-guide/mm/damon/index.rst | 31 +
.../zh_TW/admin-guide/mm/damon/lru_sort.rst | 265 ++++++
.../zh_TW/admin-guide/mm/damon/reclaim.rst | 230 ++++++
.../zh_TW/admin-guide/mm/damon/start.rst | 126 +++
.../zh_TW/admin-guide/mm/damon/usage.rst | 593 ++++++++++++++
.../zh_TW/admin-guide/mm/index.rst | 52 ++
.../translations/zh_TW/admin-guide/mm/ksm.rst | 201 +++++
.../zh_TW/admin-guide/reporting-issues.rst | 729 +++++++++--------
.../admin-guide/reporting-regressions.rst | 371 +++++++++
.../zh_TW/admin-guide/security-bugs.rst | 28 +-
.../translations/zh_TW/admin-guide/sysrq.rst | 283 +++++++
.../zh_TW/admin-guide/tainted-kernels.rst | 86 +-
.../zh_TW/admin-guide/unicode.rst | 12 +-
.../translations/zh_TW/arch/arm/Booting | 176 ++++
.../zh_TW/arch/arm/kernel_user_helpers.txt | 285 +++++++
.../translations/zh_TW/arch/arm64/amu.rst | 6 +-
.../translations/zh_TW/arch/arm64/booting.txt | 28 +-
.../zh_TW/arch/arm64/elf_hwcaps.rst | 10 +-
.../zh_TW/arch/arm64/legacy_instructions.txt | 14 +-
.../translations/zh_TW/arch/arm64/memory.txt | 16 +-
.../translations/zh_TW/arch/arm64/perf.rst | 2 +-
.../zh_TW/arch/arm64/silicon-errata.txt | 30 +-
.../zh_TW/arch/arm64/tagged-pointers.txt | 10 +-
.../translations/zh_TW/arch/index.rst | 30 +
.../zh_TW/arch/openrisc/index.rst | 33 +
.../zh_TW/arch/openrisc/openrisc_port.rst | 129 +++
.../translations/zh_TW/arch/openrisc/todo.rst | 25 +
.../zh_TW/arch/parisc/debugging.rst | 47 ++
.../translations/zh_TW/arch/parisc/index.rst | 32 +
.../zh_TW/arch/parisc/registers.rst | 157 ++++
.../translations/zh_TW/cpu-freq/core.rst | 26 +-
.../zh_TW/cpu-freq/cpu-drivers.rst | 147 ++--
.../zh_TW/cpu-freq/cpufreq-stats.rst | 41 +-
.../translations/zh_TW/cpu-freq/index.rst | 4 +-
.../zh_TW/filesystems/debugfs.rst | 38 +-
.../translations/zh_TW/filesystems/index.rst | 2 +-
.../translations/zh_TW/filesystems/sysfs.txt | 16 +-
.../translations/zh_TW/filesystems/tmpfs.rst | 32 +-
.../zh_TW/filesystems/virtiofs.rst | 8 +-
Documentation/translations/zh_TW/index.rst | 5 +-
.../translations/zh_TW/process/1.Intro.rst | 78 +-
.../translations/zh_TW/process/2.Process.rst | 130 +--
.../zh_TW/process/3.Early-stage.rst | 44 +-
.../translations/zh_TW/process/4.Coding.rst | 102 +--
.../translations/zh_TW/process/5.Posting.rst | 66 +-
.../zh_TW/process/6.Followthrough.rst | 46 +-
.../zh_TW/process/7.AdvancedTopics.rst | 56 +-
.../zh_TW/process/8.Conclusion.rst | 10 +-
.../code-of-conduct-interpretation.rst | 52 +-
.../zh_TW/process/code-of-conduct.rst | 18 +-
.../zh_TW/process/coding-style.rst | 400 ++++++----
.../zh_TW/process/development-process.rst | 2 +-
.../zh_TW/process/email-clients.rst | 273 ++++---
.../process/embargoed-hardware-issues.rst | 78 +-
.../translations/zh_TW/process/howto.rst | 144 ++--
.../translations/zh_TW/process/index.rst | 5 +-
.../zh_TW/process/kernel-driver-statement.rst | 2 +-
.../process/kernel-enforcement-statement.rst | 14 +-
.../zh_TW/process/license-rules.rst | 54 +-
.../zh_TW/process/management-style.rst | 60 +-
.../zh_TW/process/stable-api-nonsense.rst | 86 +-
.../zh_TW/process/stable-kernel-rules.rst | 36 +-
.../zh_TW/process/submit-checklist.rst | 92 ++-
.../zh_TW/process/submitting-patches.rst | 755 +++++++++---------
.../process/volatile-considered-harmful.rst | 32 +-
75 files changed, 5781 insertions(+), 2079 deletions(-)
create mode 100644 Documentation/translations/zh_TW/admin-guide/bootconfig.rst
create mode 100644 Documentation/translations/zh_TW/admin-guide/cputopology.rst
create mode 100644 Documentation/translations/zh_TW/admin-guide/lockup-watchdogs.rst
create mode 100644 Documentation/translations/zh_TW/admin-guide/mm/damon/index.rst
create mode 100644 Documentation/translations/zh_TW/admin-guide/mm/damon/lru_sort.rst
create mode 100644 Documentation/translations/zh_TW/admin-guide/mm/damon/reclaim.rst
create mode 100644 Documentation/translations/zh_TW/admin-guide/mm/damon/start.rst
create mode 100644 Documentation/translations/zh_TW/admin-guide/mm/damon/usage.rst
create mode 100644 Documentation/translations/zh_TW/admin-guide/mm/index.rst
create mode 100644 Documentation/translations/zh_TW/admin-guide/mm/ksm.rst
create mode 100644 Documentation/translations/zh_TW/admin-guide/reporting-regressions.rst
create mode 100644 Documentation/translations/zh_TW/admin-guide/sysrq.rst
create mode 100644 Documentation/translations/zh_TW/arch/arm/Booting
create mode 100644 Documentation/translations/zh_TW/arch/arm/kernel_user_helpers.txt
create mode 100644 Documentation/translations/zh_TW/arch/index.rst
create mode 100644 Documentation/translations/zh_TW/arch/openrisc/index.rst
create mode 100644 Documentation/translations/zh_TW/arch/openrisc/openrisc_port.rst
create mode 100644 Documentation/translations/zh_TW/arch/openrisc/todo.rst
create mode 100644 Documentation/translations/zh_TW/arch/parisc/debugging.rst
create mode 100644 Documentation/translations/zh_TW/arch/parisc/index.rst
create mode 100644 Documentation/translations/zh_TW/arch/parisc/registers.rst
--
2.34.1
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v3 2/6] docs/zh_TW: update arch
2023-08-07 12:00 [PATCH v3 0/6] docs/zh_TW: update zh_TW's documentation from an ascensive aspect Hu Haowen
@ 2023-08-07 12:00 ` Hu Haowen
2023-08-07 12:00 ` [PATCH v3 3/6] docs/zh_TW: update cpu-freq Hu Haowen
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Hu Haowen @ 2023-08-07 12:00 UTC (permalink / raw)
To: corbet; +Cc: Hu Haowen, linux-doc, linux-kernel
Update zh_TW's arch documentation concentrating on the following
aspects:
* The file tree structure changes of the main documentation;
* Some changes and ideas from zh_CN translation;
* Removal for several obsoleted contents within the zh_TW translation
or those which are not exising anymore in the main documentation.
* Replacements for some incorrect words and phrases in traditional
Chinese or those which are odd within their context being hard for
readers to comprehend.
Signed-off-by: Hu Haowen <src.res.211@gmail.com>
---
.../translations/zh_TW/arch/arm/Booting | 176 +++++++++++
.../zh_TW/arch/arm/kernel_user_helpers.txt | 285 ++++++++++++++++++
.../translations/zh_TW/arch/arm64/amu.rst | 6 +-
.../translations/zh_TW/arch/arm64/booting.txt | 26 +-
.../zh_TW/arch/arm64/elf_hwcaps.rst | 10 +-
.../zh_TW/arch/arm64/legacy_instructions.txt | 14 +-
.../translations/zh_TW/arch/arm64/memory.txt | 16 +-
.../translations/zh_TW/arch/arm64/perf.rst | 2 +-
.../zh_TW/arch/arm64/silicon-errata.txt | 28 +-
.../zh_TW/arch/arm64/tagged-pointers.txt | 10 +-
.../translations/zh_TW/arch/index.rst | 30 ++
.../zh_TW/arch/openrisc/index.rst | 33 ++
.../zh_TW/arch/openrisc/openrisc_port.rst | 129 ++++++++
.../translations/zh_TW/arch/openrisc/todo.rst | 25 ++
.../zh_TW/arch/parisc/debugging.rst | 47 +++
.../translations/zh_TW/arch/parisc/index.rst | 32 ++
.../zh_TW/arch/parisc/registers.rst | 157 ++++++++++
Documentation/translations/zh_TW/index.rst | 5 +-
18 files changed, 973 insertions(+), 58 deletions(-)
create mode 100644 Documentation/translations/zh_TW/arch/arm/Booting
create mode 100644 Documentation/translations/zh_TW/arch/arm/kernel_user_helpers.txt
create mode 100644 Documentation/translations/zh_TW/arch/index.rst
create mode 100644 Documentation/translations/zh_TW/arch/openrisc/index.rst
create mode 100644 Documentation/translations/zh_TW/arch/openrisc/openrisc_port.rst
create mode 100644 Documentation/translations/zh_TW/arch/openrisc/todo.rst
create mode 100644 Documentation/translations/zh_TW/arch/parisc/debugging.rst
create mode 100644 Documentation/translations/zh_TW/arch/parisc/index.rst
create mode 100644 Documentation/translations/zh_TW/arch/parisc/registers.rst
diff --git a/Documentation/translations/zh_TW/arch/arm/Booting b/Documentation/translations/zh_TW/arch/arm/Booting
new file mode 100644
index 000000000000..a5375f262de2
--- /dev/null
+++ b/Documentation/translations/zh_TW/arch/arm/Booting
@@ -0,0 +1,176 @@
+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 狀態。
+
diff --git a/Documentation/translations/zh_TW/arch/arm/kernel_user_helpers.txt b/Documentation/translations/zh_TW/arch/arm/kernel_user_helpers.txt
new file mode 100644
index 000000000000..4c0bff97af31
--- /dev/null
+++ b/Documentation/translations/zh_TW/arch/arm/kernel_user_helpers.txt
@@ -0,0 +1,285 @@
+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 開始)。
+
diff --git a/Documentation/translations/zh_TW/arch/arm64/amu.rst b/Documentation/translations/zh_TW/arch/arm64/amu.rst
index f947a6c7369f..80044364208e 100644
--- a/Documentation/translations/zh_TW/arch/arm64/amu.rst
+++ b/Documentation/translations/zh_TW/arch/arm64/amu.rst
@@ -28,11 +28,11 @@ AArch64 Linux 中擴展的活動監控單元
AMUv1 架構實現了一個由4個固定的64位事件計數器組成的計數器組。
- - CPU 周期計數器:同 CPU 的頻率增長
+ - CPU 週期計數器:同 CPU 的頻率增長
- 常量計數器:同固定的系統時鐘頻率增長
- 淘汰指令計數器: 同每次架構指令執行增長
- - 內存停頓周期計數器:計算由在時鐘域內的最後一級緩存中未命中而引起
- 的指令調度停頓周期數
+ - 內存停頓週期計數器:計算由在時鐘域內的最後一級緩存中未命中而引起
+ 的指令調度停頓週期數
當處於 WFI 或者 WFE 狀態時,計數器不會增長。
diff --git a/Documentation/translations/zh_TW/arch/arm64/booting.txt b/Documentation/translations/zh_TW/arch/arm64/booting.txt
index 24817b8b70cd..af1bd2d7eec1 100644
--- a/Documentation/translations/zh_TW/arch/arm64/booting.txt
+++ b/Documentation/translations/zh_TW/arch/arm64/booting.txt
@@ -41,7 +41,7 @@ AArch64 異常模型由多個異常級(EL0 - EL3)組成,對於 EL0 和 EL1
有對應的安全和非安全模式。EL2 是系統管理級,且僅存在於非安全模式下。
EL3 是最高特權級,且僅存在於安全模式下。
-基於本文檔的目的,我們將簡單地使用『引導裝載程序』(『boot loader』)
+基於本文檔的目的,我們將簡單地使用“引導裝載程序”(“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
diff --git a/Documentation/translations/zh_TW/arch/arm64/elf_hwcaps.rst b/Documentation/translations/zh_TW/arch/arm64/elf_hwcaps.rst
index fca3c6ff7b93..b67df8939d60 100644
--- a/Documentation/translations/zh_TW/arch/arm64/elf_hwcaps.rst
+++ b/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 以下面的形式描述::
diff --git a/Documentation/translations/zh_TW/arch/arm64/legacy_instructions.txt b/Documentation/translations/zh_TW/arch/arm64/legacy_instructions.txt
index 3c915df9836c..03e36567ad5f 100644
--- a/Documentation/translations/zh_TW/arch/arm64/legacy_instructions.txt
+++ b/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 (不支持混合字節序) 在使能這個特性後被熱插入系統,
在應用中可能會出現不可預期的結果。
diff --git a/Documentation/translations/zh_TW/arch/arm64/memory.txt b/Documentation/translations/zh_TW/arch/arm64/memory.txt
index 2437380a26d8..5d57603aa271 100644
--- a/Documentation/translations/zh_TW/arch/arm64/memory.txt
+++ b/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 頁大小的轉換表查找:
diff --git a/Documentation/translations/zh_TW/arch/arm64/perf.rst b/Documentation/translations/zh_TW/arch/arm64/perf.rst
index 3b39997a52eb..07b264d70e43 100644
--- a/Documentation/translations/zh_TW/arch/arm64/perf.rst
+++ b/Documentation/translations/zh_TW/arch/arm64/perf.rst
@@ -59,7 +59,7 @@ EL2(VHE 內核 或 non-VHE 虛擬機監控器)。
KVM 客戶機可能運行在 EL0(用戶空間)和 EL1(內核)。
-由於宿主機和客戶機之間重疊的異常級別,我們不能僅僅依靠 PMU 的硬體異
+由於宿主機和客戶機之間重疊的異常級別,我們不能僅僅依靠 PMU 的硬件異
常過濾機制-因此我們必須啓用/禁用對於客戶機進入和退出的計數。而這在
VHE 和 non-VHE 系統上表現不同。
diff --git a/Documentation/translations/zh_TW/arch/arm64/silicon-errata.txt b/Documentation/translations/zh_TW/arch/arm64/silicon-errata.txt
index 66c3a3506458..9d1f49a6b6e7 100644
--- a/Documentation/translations/zh_TW/arch/arm64/silicon-errata.txt
+++ b/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)到穩定內核時被更新。
| 實現者 | 受影響的組件 | 勘誤編號 | 內核配置 |
+----------------+-----------------+-----------------+-------------------------+
diff --git a/Documentation/translations/zh_TW/arch/arm64/tagged-pointers.txt b/Documentation/translations/zh_TW/arch/arm64/tagged-pointers.txt
index b7f683f20ed1..fa2fbc4cecad 100644
--- a/Documentation/translations/zh_TW/arch/arm64/tagged-pointers.txt
+++ b/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” 的擴展符。
diff --git a/Documentation/translations/zh_TW/arch/index.rst b/Documentation/translations/zh_TW/arch/index.rst
new file mode 100644
index 000000000000..fd1f0de1b8de
--- /dev/null
+++ b/Documentation/translations/zh_TW/arch/index.rst
@@ -0,0 +1,30 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+處理器體系結構
+==============
+
+以下文檔提供了具體架構實現的編程細節。
+
+.. toctree::
+ :maxdepth: 2
+
+ ../mips/index
+ arm64/index
+ ../riscv/index
+ openrisc/index
+ parisc/index
+ ../loongarch/index
+
+TODOList:
+
+* arm/index
+* ia64/index
+* m68k/index
+* nios2/index
+* powerpc/index
+* s390/index
+* sh/index
+* sparc/index
+* x86/index
+* xtensa/index
+
diff --git a/Documentation/translations/zh_TW/arch/openrisc/index.rst b/Documentation/translations/zh_TW/arch/openrisc/index.rst
new file mode 100644
index 000000000000..7585960783fc
--- /dev/null
+++ b/Documentation/translations/zh_TW/arch/openrisc/index.rst
@@ -0,0 +1,33 @@
+.. 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`
+
diff --git a/Documentation/translations/zh_TW/arch/openrisc/openrisc_port.rst b/Documentation/translations/zh_TW/arch/openrisc/openrisc_port.rst
new file mode 100644
index 000000000000..e72b470cf792
--- /dev/null
+++ b/Documentation/translations/zh_TW/arch/openrisc/openrisc_port.rst
@@ -0,0 +1,129 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../../disclaimer-zh_TW.rst
+
+:Original: Documentation/arch/openrisc/openrisc_port.rst
+
+:翻譯:
+
+ 司延騰 Yanteng Si <siyanteng@loongson.cn>
+
+.. _tw_openrisc_port:
+
+==============
+OpenRISC Linux
+==============
+
+這是Linux對OpenRISC類微處理器的移植;具體來說,最早移植目標是32位
+OpenRISC 1000系列(或1k)。
+
+關於OpenRISC處理器和正在進行中的開發的信息:
+
+ ======= =============================
+ 網站 https://openrisc.io
+ 郵箱 openrisc@lists.librecores.org
+ ======= =============================
+
+---------------------------------------------------------------------
+
+OpenRISC工具鏈和Linux的構建指南
+===============================
+
+爲了構建和運行Linux for OpenRISC,你至少需要一個基本的工具鏈,或許
+還需要架構模擬器。 這裏概述了準備就位這些部分的步驟。
+
+1) 工具鏈
+
+工具鏈二進制文件可以從openrisc.io或我們的github發佈頁面獲得。不同
+工具鏈的構建指南可以在openrisc.io或Stafford的工具鏈構建和發佈腳本
+中找到。
+
+ ====== =================================================
+ 二進制 https://github.com/openrisc/or1k-gcc/releases
+ 工具鏈 https://openrisc.io/software
+ 構建 https://github.com/stffrdhrn/or1k-toolchain-build
+ ====== =================================================
+
+2) 構建
+
+像往常一樣構建Linux內核::
+
+ make ARCH=openrisc CROSS_COMPILE="or1k-linux-" defconfig
+ make ARCH=openrisc CROSS_COMPILE="or1k-linux-"
+
+3) 在FPGA上運行(可選)
+
+OpenRISC社區通常使用FuseSoC來管理構建和編程SoC到FPGA中。 下面是用
+OpenRISC SoC對De0 Nano開發板進行編程的一個例子。 在構建過程中,
+FPGA RTL是從FuseSoC IP核庫中下載的代碼,並使用FPGA供應商工具構建。
+二進制文件用openocd加載到電路板上。
+
+::
+
+ git clone https://github.com/olofk/fusesoc
+ cd fusesoc
+ sudo pip install -e .
+
+ fusesoc init
+ fusesoc build de0_nano
+ fusesoc pgm de0_nano
+
+ openocd -f interface/altera-usb-blaster.cfg \
+ -f board/or1k_generic.cfg
+
+ telnet localhost 4444
+ > init
+ > halt; load_image vmlinux ; reset
+
+4) 在模擬器上運行(可選)
+
+QEMU是一個處理器仿真器,我們推薦它來模擬OpenRISC平臺。 請按照QEMU網
+站上的OpenRISC說明,讓Linux在QEMU上運行。 你可以自己構建QEMU,但你的
+Linux發行版可能提供了支持OpenRISC的二進制包。
+
+ ============= ======================================================
+ qemu openrisc https://wiki.qemu.org/Documentation/Platforms/OpenRISC
+ ============= ======================================================
+
+---------------------------------------------------------------------
+
+術語表
+======
+
+代碼中使用了以下符號約定以將範圍限制在幾個特定處理器實現上:
+
+========= =======================
+openrisc: OpenRISC類型處理器
+or1k: OpenRISC 1000系列處理器
+or1200: OpenRISC 1200處理器
+========= =======================
+
+---------------------------------------------------------------------
+
+歷史
+====
+
+2003-11-18 Matjaz Breskvar (phoenix@bsemi.com)
+ 將linux初步移植到OpenRISC或32架構。
+ 所有的核心功能都實現了,並且可以使用。
+
+2003-12-08 Matjaz Breskvar (phoenix@bsemi.com)
+ 徹底改變TLB失誤處理。
+ 重寫異常處理。
+ 在默認的initrd中實現了sash-3.6的所有功能。
+ 大幅改進的版本。
+
+2004-04-10 Matjaz Breskvar (phoenix@bsemi.com)
+ 大量的bug修復。
+ 支持以太網,http和telnet服務器功能。
+ 可以運行許多標準的linux應用程序。
+
+2004-06-26 Matjaz Breskvar (phoenix@bsemi.com)
+ 移植到2.6.x。
+
+2004-11-30 Matjaz Breskvar (phoenix@bsemi.com)
+ 大量的bug修復和增強功能。
+ 增加了opencores framebuffer驅動。
+
+2010-10-09 Jonas Bonn (jonas@southpole.se)
+ 重大重寫,使其與上游的Linux 2.6.36看齊。
+
diff --git a/Documentation/translations/zh_TW/arch/openrisc/todo.rst b/Documentation/translations/zh_TW/arch/openrisc/todo.rst
new file mode 100644
index 000000000000..cbf4ca74fa23
--- /dev/null
+++ b/Documentation/translations/zh_TW/arch/openrisc/todo.rst
@@ -0,0 +1,25 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. 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。
+
diff --git a/Documentation/translations/zh_TW/arch/parisc/debugging.rst b/Documentation/translations/zh_TW/arch/parisc/debugging.rst
new file mode 100644
index 000000000000..d74c73557e9b
--- /dev/null
+++ b/Documentation/translations/zh_TW/arch/parisc/debugging.rst
@@ -0,0 +1,47 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../../disclaimer-zh_TW.rst
+
+:Original: Documentation/arch/parisc/debugging.rst
+
+:翻譯:
+
+ 司延騰 Yanteng Si <siyanteng@loongson.cn>
+
+.. _tw_parisc_debugging:
+
+=================
+調試PA-RISC
+=================
+
+好吧,這裏有一些關於調試linux/parisc的較底層部分的信息。
+
+
+1. 絕對地址
+=====================
+
+很多彙編代碼目前運行在實模式下,這意味着會使用絕對地址,而不是像內核其他
+部分那樣使用虛擬地址。要將絕對地址轉換爲虛擬地址,你可以在System.map中查
+找,添加__PAGE_OFFSET(目前是0x10000000)。
+
+
+2. HPMCs
+========
+
+當實模式的代碼試圖訪問不存在的內存時,會出現HPMC(high priority machine
+check)而不是內核oops。若要調試HPMC,請嘗試找到系統響應程序/請求程序地址。
+系統請求程序地址應該與(某)處理器的HPA(I/O範圍內的高地址)相匹配;系統響應程
+序地址是實模式代碼試圖訪問的地址。
+
+系統響應程序地址的典型值是大於__PAGE_OFFSET (0x10000000)的地址,這意味着
+在實模式試圖訪問它之前,虛擬地址沒有被翻譯成物理地址。
+
+
+3. 有趣的Q位
+============
+
+某些非常關鍵的代碼必須清除PSW中的Q位。當Q位被清除時,CPU不會更新中斷處理
+程序所讀取的寄存器,以找出機器被中斷的位置——所以如果你在清除Q位的指令和再
+次設置Q位的RFI之間遇到中斷,你不知道它到底發生在哪裏。如果你幸運的話,IAOQ
+會指向清除Q位的指令,如果你不幸運的話,它會指向任何地方。通常Q位的問題會
+表現爲無法解釋的系統掛起或物理內存越界。
+
diff --git a/Documentation/translations/zh_TW/arch/parisc/index.rst b/Documentation/translations/zh_TW/arch/parisc/index.rst
new file mode 100644
index 000000000000..35941bf68c88
--- /dev/null
+++ b/Documentation/translations/zh_TW/arch/parisc/index.rst
@@ -0,0 +1,32 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../../disclaimer-zh_TW.rst
+
+:Original: Documentation/arch/parisc/index.rst
+
+:翻譯:
+
+ 司延騰 Yanteng Si <siyanteng@loongson.cn>
+
+.. _tw_parisc_index:
+
+====================
+PA-RISC體系架構
+====================
+
+.. toctree::
+ :maxdepth: 2
+
+ debugging
+ registers
+
+Todolist:
+
+ features
+
+.. only:: subproject and html
+
+ Indices
+ =======
+
+ * :ref:`genindex`
+
diff --git a/Documentation/translations/zh_TW/arch/parisc/registers.rst b/Documentation/translations/zh_TW/arch/parisc/registers.rst
new file mode 100644
index 000000000000..695acb21134a
--- /dev/null
+++ b/Documentation/translations/zh_TW/arch/parisc/registers.rst
@@ -0,0 +1,157 @@
+.. include:: ../../disclaimer-zh_TW.rst
+
+:Original: Documentation/arch/parisc/registers.rst
+
+:翻譯:
+
+ 司延騰 Yanteng Si <siyanteng@loongson.cn>
+
+.. _tw_parisc_registers:
+
+=========================
+Linux/PA-RISC的寄存器用法
+=========================
+
+[ 用星號表示目前尚未實現的計劃用途。 ]
+
+ABI約定的通用寄存器
+===================
+
+控制寄存器
+----------
+
+============================ =================================
+CR 0 (恢復計數器) 用於ptrace
+CR 1-CR 7(無定義) 未使用
+CR 8 (Protection ID) 每進程值*
+CR 9, 12, 13 (PIDS) 未使用
+CR10 (CCR) FPU延遲保存*
+CR11 按照ABI的規定(SAR)
+CR14 (中斷向量) 初始化爲 fault_vector
+CR15 (EIEM) 所有位初始化爲1*
+CR16 (間隔計時器) 讀取週期數/寫入開始時間間隔計時器
+CR17-CR22 中斷參數
+CR19 中斷指令寄存器
+CR20 中斷空間寄存器
+CR21 中斷偏移量寄存器
+CR22 中斷 PSW
+CR23 (EIRR) 讀取未決中斷/寫入清除位
+CR24 (TR 0) 內核空間頁目錄指針
+CR25 (TR 1) 用戶空間頁目錄指針
+CR26 (TR 2) 不使用
+CR27 (TR 3) 線程描述符指針
+CR28 (TR 4) 不使用
+CR29 (TR 5) 不使用
+CR30 (TR 6) 當前 / 0
+CR31 (TR 7) 臨時寄存器,在不同地方使用
+============================ =================================
+
+空間寄存器(內核模式)
+----------------------
+
+======== ==============================
+SR0 臨時空間寄存器
+SR4-SR7 設置爲0
+SR1 臨時空間寄存器
+SR2 內核不應該破壞它
+SR3 用於用戶空間訪問(當前進程)
+======== ==============================
+
+空間寄存器(用戶模式)
+----------------------
+
+======== ============================
+SR0 臨時空間寄存器
+SR1 臨時空間寄存器
+SR2 保存Linux gateway page的空間
+SR3 在內核中保存用戶地址空間的值
+SR4-SR7 定義了用戶/內核的短地址空間
+======== ============================
+
+
+處理器狀態字
+------------
+
+====================== ================================================
+W (64位地址) 0
+E (小尾端) 0
+S (安全間隔計時器) 0
+T (產生分支陷阱) 0
+H (高特權級陷阱) 0
+L (低特權級陷阱) 0
+N (撤銷下一條指令) 被C代碼使用
+X (數據存儲中斷禁用) 0
+B (產生分支) 被C代碼使用
+C (代碼地址轉譯) 1, 在執行實模式代碼時爲0
+V (除法步長校正) 被C代碼使用
+M (HPMC 掩碼) 0, 在執行HPMC操作*時爲1
+C/B (進/借 位) 被C代碼使用
+O (有序引用) 1*
+F (性能監視器) 0
+R (回收計數器陷阱) 0
+Q (收集中斷狀態) 1 (在rfi之前的代碼中爲0)
+P (保護標識符) 1*
+D (數據地址轉譯) 1, 在執行實模式代碼時爲0
+I (外部中斷掩碼) 由cli()/sti()宏使用。
+====================== ================================================
+
+“隱形”寄存器(影子寄存器)
+---------------------------
+
+============= ===================
+PSW W 默認值 0
+PSW E 默認值 0
+影子寄存器 被中斷處理代碼使用
+TOC啓用位 1
+============= ===================
+
+----------------------------------------------------------
+
+PA-RISC架構定義了7個寄存器作爲“影子寄存器”。這些寄存器在
+RETURN FROM INTERRUPTION AND RESTORE指令中使用,通過消
+除中斷處理程序中對一般寄存器(GR)的保存和恢復的需要來減
+少狀態保存和恢復時間。影子寄存器是GRs 1, 8, 9, 16, 17,
+24和25。
+
+-------------------------------------------------------------------------
+
+寄存器使用說明,最初由John Marvin提供,並由Randolph Chung提供一些補充說明。
+
+對於通用寄存器:
+
+r1,r2,r19-r26,r28,r29 & r31可以在不保存它們的情況下被使用。當然,如果你
+關心它們,在調用另一個程序之前,你也需要保存它們。上面的一些寄存器確實
+有特殊的含義,你應該注意一下:
+
+ r1:
+ addil指令是硬性規定將其結果放在r1中,所以如果你使用這條指令要
+ 注意這點。
+
+ r2:
+ 這就是返回指針。一般來說,你不想使用它,因爲你需要這個指針來返
+ 回給你的調用者。然而,它與這組寄存器組合在一起,因爲調用者不能
+ 依賴你返回時的值是相同的,也就是說,你可以將r2複製到另一個寄存
+ 器,並在作廢r2後通過該寄存器返回,這應該不會給調用程序帶來問題。
+
+ r19-r22:
+ 這些通常被認爲是臨時寄存器。
+ 請注意,在64位中它們是arg7-arg4。
+
+ r23-r26:
+ 這些是arg3-arg0,也就是說,如果你不再關心傳入的值,你可以使用
+ 它們。
+
+ r28,r29:
+ 這倆是ret0和ret1。它們是你傳入返回值的地方。r28是主返回值。當返回
+ 小結構體時,r29也可以用來將數據傳回給調用程序。
+
+ r30:
+ 棧指針
+
+ r31:
+ ble指令將返回指針放在這裏。
+
+
+ r3-r18,r27,r30需要被保存和恢復。r3-r18只是一般用途的寄存器。
+ r27是數據指針,用來使對全局變量的引用更容易。r30是棧指針。
+
diff --git a/Documentation/translations/zh_TW/index.rst b/Documentation/translations/zh_TW/index.rst
index fe0c8b34bafc..411a9323b41d 100644
--- a/Documentation/translations/zh_TW/index.rst
+++ b/Documentation/translations/zh_TW/index.rst
@@ -101,9 +101,10 @@ TODOList:
體系結構文檔
------------
-TODOList:
+.. toctree::
+ :maxdepth: 1
-* arch/index
+ arch/index
其他文檔
--------
--
2.34.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH v3 3/6] docs/zh_TW: update cpu-freq
2023-08-07 12:00 [PATCH v3 0/6] docs/zh_TW: update zh_TW's documentation from an ascensive aspect Hu Haowen
2023-08-07 12:00 ` [PATCH v3 2/6] docs/zh_TW: update arch Hu Haowen
@ 2023-08-07 12:00 ` Hu Haowen
2023-08-07 12:00 ` [PATCH v3 4/6] docs/zh_TW: update filesystems Hu Haowen
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Hu Haowen @ 2023-08-07 12:00 UTC (permalink / raw)
To: corbet; +Cc: Hu Haowen, linux-doc, linux-kernel
Update zh_TW's cpu-freq documentation concentrating on the following
aspects:
* The file tree structure changes of the main documentation;
* Some changes and ideas from zh_CN translation;
* Removal for several obsoleted contents within the zh_TW translation
or those which are not exising anymore in the main documentation.
* Replacements for some incorrect words and phrases in traditional
Chinese or those which are odd within their context being hard for
readers to comprehend.
Signed-off-by: Hu Haowen <src.res.211@gmail.com>
---
.../translations/zh_TW/cpu-freq/core.rst | 26 ++--
.../zh_TW/cpu-freq/cpu-drivers.rst | 147 +++++++++---------
.../zh_TW/cpu-freq/cpufreq-stats.rst | 41 +++--
.../translations/zh_TW/cpu-freq/index.rst | 4 +-
4 files changed, 108 insertions(+), 110 deletions(-)
diff --git a/Documentation/translations/zh_TW/cpu-freq/core.rst b/Documentation/translations/zh_TW/cpu-freq/core.rst
index 3d890c2f2a61..20ec33aa98e4 100644
--- a/Documentation/translations/zh_TW/cpu-freq/core.rst
+++ b/Documentation/translations/zh_TW/cpu-freq/core.rst
@@ -29,10 +29,10 @@ CPUFreq核心和CPUFreq通知器的通用說明
======================
cpufreq核心代碼位於drivers/cpufreq/cpufreq.c中。這些cpufreq代碼爲CPUFreq架構的驅
-動程序(那些操作硬體切換頻率的代碼)以及 "通知器 "提供了一個標準化的接口。
-這些是設備驅動程序或需要了解策略變化的其它內核部分(如 ACPI 熱量管理)或所有頻率更改(除
-計時代碼外),甚至需要強制確定速度限制的通知器(如 ARM 架構上的 LCD 驅動程序)。
-此外, 內核 "常數" loops_per_jiffy會根據頻率變化而更新。
+動程序(那些執行硬件頻率切換的代碼)以及 "通知器" 提供了一個標準化的接口。
+包括設備驅動程序;需要了解策略變化(如 ACPI 熱量管理),或所有頻率變化(如計時代碼),
+甚至需要強制限制爲指定頻率(如 ARM 架構上的 LCD 驅動程序)的其它內核組件。
+此外,內核 "常數" loops_per_jiffy 會根據頻率變化而更新。
cpufreq策略的引用計數由 cpufreq_cpu_get 和 cpufreq_cpu_put 來完成,以確保 cpufreq 驅
動程序被正確地註冊到核心中,並且驅動程序在 cpufreq_put_cpu 被調用之前不會被卸載。這也保證
@@ -41,10 +41,10 @@ cpufreq策略的引用計數由 cpufreq_cpu_get 和 cpufreq_cpu_put 來完成,
2. CPUFreq 通知器
====================
-CPUFreq通知器符合標準的內核通知器接口。
+CPUFreq通知器遵循標準的內核通知器接口。
關於通知器的細節請參閱 linux/include/linux/notifier.h。
-這裡有兩個不同的CPUfreq通知器 - 策略通知器和轉換通知器。
+這裏有兩個不同的CPUfreq通知器 - 策略通知器和轉換通知器。
2.1 CPUFreq策略通知器
@@ -62,27 +62,27 @@ CPUFreq通知器符合標準的內核通知器接口。
2.2 CPUFreq轉換通知器
--------------------------------
-當CPUfreq驅動切換CPU核心頻率時,策略中的每個在線CPU都會收到兩次通知,這些變化沒有任何外部干
+當CPUfreq驅動切換CPU核心頻率時,策略中的每個在線CPU都會收到兩次通知,這些變化沒有任何外部幹
預。
第二個參數指定階段 - CPUFREQ_PRECHANGE or CPUFREQ_POSTCHANGE.
第三個參數是一個包含如下值的結構體cpufreq_freqs:
-===== ====================
-cpu 受影響cpu的編號
+====== ===============================
+policy 指向struct cpufreq_policy的指針
old 舊頻率
new 新頻率
flags cpufreq驅動的標誌
-===== ====================
+====== ===============================
3. 含有Operating Performance Point (OPP)的CPUFreq表的生成
==================================================================
關於OPP的細節請參閱 Documentation/power/opp.rst
dev_pm_opp_init_cpufreq_table -
- 這個功能提供了一個隨時可用的轉換程序,用來將OPP層關於可用頻率的內部信息翻譯成一種容易提供給
- cpufreq的格式。
+ 這個函數提供了一個隨時可用的轉換例程,用來將OPP層關於可用頻率的內部信息翻譯成一種
+ cpufreq易於處理的格式。
.. Warning::
@@ -101,7 +101,7 @@ dev_pm_opp_init_cpufreq_table -
.. note::
- 該函數只有在CONFIG_PM_OPP之外還啓用了CONFIG_CPU_FREQ時才可用。
+ 該函數只有在CONFIG_PM_OPP之外還啓用了CONFIG_CPU_FREQ時纔可用。
dev_pm_opp_free_cpufreq_table
釋放dev_pm_opp_init_cpufreq_table分配的表。
diff --git a/Documentation/translations/zh_TW/cpu-freq/cpu-drivers.rst b/Documentation/translations/zh_TW/cpu-freq/cpu-drivers.rst
index 2bb8197cd320..40b56259cf72 100644
--- a/Documentation/translations/zh_TW/cpu-freq/cpu-drivers.rst
+++ b/Documentation/translations/zh_TW/cpu-freq/cpu-drivers.rst
@@ -37,15 +37,15 @@
1. 怎麼做?
===========
-如此,你剛剛得到了一個全新的CPU/晶片組及其數據手冊,並希望爲這個CPU/晶片組添加cpufreq
-支持?很好,這裡有一些至關重要的提示:
+如果,你剛剛得到了一個全新的CPU/芯片組及其數據手冊,並希望爲這個CPU/芯片組添加cpufreq
+支持?很好,這裏有一些至關重要的提示:
1.1 初始化
----------
-首先,在__initcall_level_7 (module_init())或更靠後的函數中檢查這個內核是否
-運行在正確的CPU和正確的晶片組上。如果是,則使用cpufreq_register_driver()向
+首先,在 __initcall level 7 (module_init())或更靠後的函數中檢查這個內核是否
+運行在正確的CPU和正確的芯片組上。如果是,則使用cpufreq_register_driver()向
CPUfreq核心層註冊一個cpufreq_driver結構體。
結構體cpufreq_driver應該包含什麼成員?
@@ -59,11 +59,11 @@ CPUfreq核心層註冊一個cpufreq_driver結構體。
.setpolicy 或 .fast_switch 或 .target 或 .target_index - 差異見
下文。
-並且可選擇
+其它可選成員
- .flags - cpufreq核的提示。
+ .flags - 給cpufreq核心的提示。
- .driver_data - cpufreq驅動程序的特定數據。
+ .driver_data - cpufreq驅動程序的特有數據。
.get_intermediate 和 target_intermediate - 用於在改變CPU頻率時切換到穩定
的頻率。
@@ -72,18 +72,18 @@ CPUfreq核心層註冊一個cpufreq_driver結構體。
.bios_limit - 返回HW/BIOS對CPU的最大頻率限制值。
- .exit - 一個指向per-policy清理函數的指針,該函數在cpu熱插拔過程的CPU_POST_DEAD
+ .exit - 一個指向per-policy清理函數的指針,該函數在CPU熱插拔過程的CPU_POST_DEAD
階段被調用。
.suspend - 一個指向per-policy暫停函數的指針,該函數在關中斷且在該策略的調節器停止
後被調用。
- .resume - 一個指向per-policy恢復函數的指針,該函數在關中斷且在調節器再一次開始前被
+ .resume - 一個指向per-policy恢復函數的指針,該函數在關中斷且在調節器再一次啓動前被
調用。
.ready - 一個指向per-policy準備函數的指針,該函數在策略完全初始化之後被調用。
- .attr - 一個指向NULL結尾的"struct freq_attr"列表的指針,該函數允許導出值到
+ .attr - 一個指向NULL結尾的"struct freq_attr"列表的指針,該列表允許導出值到
sysfs。
.boost_enabled - 如果設置,則啓用提升(boost)頻率。
@@ -94,95 +94,93 @@ CPUfreq核心層註冊一個cpufreq_driver結構體。
1.2 Per-CPU 初始化
------------------
-每當一個新的CPU被註冊到設備模型中,或者在cpufreq驅動註冊自己之後,如果此CPU的cpufreq策
-略不存在,則會調用per-policy的初始化函數cpufreq_driver.init。請注意,.init()和.exit()程序
-只對策略調用一次,而不是對策略管理的每個CPU調用一次。它需要一個 ``struct cpufreq_policy
+每當一個新的CPU被註冊到設備模型中,或者當cpufreq驅動註冊自身之後,如果此CPU的cpufreq策
+略不存在,則會調用per-policy的初始化函數cpufreq_driver.init。請注意,.init()和.exit()例程
+只爲某個策略調用一次,而不是對該策略管理的每個CPU調用一次。它需要一個 ``struct cpufreq_policy
*policy`` 作爲參數。現在該怎麼做呢?
如果有必要,請在你的CPU上激活CPUfreq功能支持。
-然後,驅動程序必須填寫以下數值:
+然後,驅動程序必須填寫以下值:
+-----------------------------------+--------------------------------------+
-|policy->cpuinfo.min_freq 和 | |
-|policy->cpuinfo.max_freq | 該CPU支持的最低和最高頻率(kHz) |
-| | |
-| | |
+|policy->cpuinfo.min_freq和 | 該CPU支持的最低和最高頻率(kHz) |
+|policy->cpuinfo.max_freq | |
+| | |
+-----------------------------------+--------------------------------------+
-|policy->cpuinfo.transition_latency | |
-| | CPU在兩個頻率之間切換所需的時間,以 |
-| | 納秒爲單位(如適用,否則指定 |
-| | CPUFREQ_ETERNAL) |
+|policy->cpuinfo.transition_latency | CPU在兩個頻率之間切換所需的時間,以 |
+| | 納秒爲單位(如不適用,設定爲 |
+| | CPUFREQ_ETERNAL) |
+| | |
+-----------------------------------+--------------------------------------+
-|policy->cur | 該CPU當前的工作頻率(如適用) |
-| | |
+|policy->cur | 該CPU當前的工作頻率(如適用) |
+| | |
+-----------------------------------+--------------------------------------+
-|policy->min, | |
-|policy->max, | |
-|policy->policy and, if necessary, | |
-|policy->governor | 必須包含該cpu的 「默認策略」。稍後 |
-| | 會用這些值調用 |
-| | cpufreq_driver.verify and either |
-| | cpufreq_driver.setpolicy or |
-| | cpufreq_driver.target/target_index |
-| | |
+|policy->min, | 必須包含該CPU的"默認策略"。稍後 |
+|policy->max, | 會用這些值調用 |
+|policy->policy and, if necessary, | cpufreq_driver.verify和下面函數 |
+|policy->governor | 之一:cpufreq_driver.setpolicy或 |
+| | cpufreq_driver.target/target_index |
+| | |
+-----------------------------------+--------------------------------------+
-|policy->cpus | 用與這個CPU一起做DVFS的(在線+離線) |
-| | CPU(即與它共享時鐘/電壓軌)的掩碼更新 |
-| | 這個 |
-| | |
+|policy->cpus | 該policy通過DVFS框架影響的全部CPU |
+| | (即與本CPU共享"時鐘/電壓"對)構成 |
+| | 掩碼(同時包含在線和離線CPU),用掩碼 |
+| | 更新本字段 |
+| | |
+-----------------------------------+--------------------------------------+
-對於設置其中的一些值(cpuinfo.min[max]_freq, policy->min[max]),頻率表助手可能會有幫
+對於設置其中的一些值(cpuinfo.min[max]_freq, policy->min[max]),頻率表輔助函數可能會有幫
助。關於它們的更多信息,請參見第2節。
1.3 驗證
--------
-當用戶決定設置一個新的策略(由 「policy,governor,min,max組成」)時,必須對這個策略進行驗證,
+當用戶決定設置一個新的策略(由"policy,governor,min,max組成")時,必須對這個策略進行驗證,
以便糾正不兼容的值。爲了驗證這些值,cpufreq_verify_within_limits(``struct cpufreq_policy
*policy``, ``unsigned int min_freq``, ``unsigned int max_freq``)函數可能會有幫助。
-關於頻率表助手的詳細內容請參見第2節。
+關於頻率表輔助函數的詳細內容請參見第2節。
您需要確保至少有一個有效頻率(或工作範圍)在 policy->min 和 policy->max 範圍內。如果有必
-要,先增加policy->max,只有在沒有辦法的情況下,才減少policy->min。
+要,先增大policy->max,只有在沒有解決方案的情況下,才減小policy->min。
1.4 target 或 target_index 或 setpolicy 或 fast_switch?
-------------------------------------------------------
-大多數cpufreq驅動甚至大多數cpu頻率升降算法只允許將CPU頻率設置爲預定義的固定值。對於這些,你
+大多數cpufreq驅動甚至大多數CPU頻率升降算法只允許將CPU頻率設置爲預定義的固定值。對於這些,你
可以使用->target(),->target_index()或->fast_switch()回調。
-有些cpufreq功能的處理器可以自己在某些限制之間切換頻率。這些應使用->setpolicy()回調。
+有些具有硬件調頻能力的處理器可以自行依據某些限制來切換CPU頻率。它們應使用->setpolicy()回調。
1.5. target/target_index
------------------------
-target_index調用有兩個參數:``struct cpufreq_policy * policy``和``unsigned int``
-索引(於列出的頻率表)。
+target_index調用有兩個參數: ``struct cpufreq_policy * policy`` 和 ``unsigned int``
+索引(用於索引頻率表項)。
-當調用這裡時,CPUfreq驅動必須設置新的頻率。實際頻率必須由freq_table[index].frequency決定。
+當調用這裏時,CPUfreq驅動必須設置新的頻率。實際頻率必須由freq_table[index].frequency決定。
-它應該總是在錯誤的情況下恢復到之前的頻率(即policy->restore_freq),即使我們之前切換到中間頻率。
+在發生錯誤的情況下總是應該恢復到之前的頻率(即policy->restore_freq),即使我們已經切換到了
+中間頻率。
已棄用
----------
-目標調用有三個參數。``struct cpufreq_policy * policy``, unsigned int target_frequency,
+target調用有三個參數。``struct cpufreq_policy * policy``, unsigned int target_frequency,
unsigned int relation.
-CPUfreq驅動在調用這裡時必須設置新的頻率。實際的頻率必須使用以下規則來確定。
+CPUfreq驅動在調用這裏時必須設置新的頻率。實際的頻率必須使用以下規則來確定。
-- 緊跟 "目標頻率"。
+- 儘量貼近"目標頻率"。
- policy->min <= new_freq <= policy->max (這必須是有效的!!!)
- 如果 relation==CPUFREQ_REL_L,嘗試選擇一個高於或等於 target_freq 的 new_freq。("L代表
最低,但不能低於")
- 如果 relation==CPUFREQ_REL_H,嘗試選擇一個低於或等於 target_freq 的 new_freq。("H代表
最高,但不能高於")
-這裡,頻率表助手可能會幫助你--詳見第2節。
+這裏,頻率表輔助函數可能會幫助你 -- 詳見第2節。
1.6. fast_switch
----------------
@@ -196,51 +194,52 @@ CPUfreq驅動在調用這裡時必須設置新的頻率。實際的頻率必須
1.7 setpolicy
-------------
-setpolicy調用只需要一個``struct cpufreq_policy * policy``作爲參數。需要將處理器內或晶片組內動態頻
+setpolicy調用只需要一個 ``struct cpufreq_policy * policy`` 作爲參數。需要將處理器內或芯片組內動態頻
率切換的下限設置爲policy->min,上限設置爲policy->max,如果支持的話,當policy->policy爲
-CPUFREQ_POLICY_PERFORMANCE時選擇面向性能的設置,當CPUFREQ_POLICY_POWERSAVE時選擇面向省電的設置。
+CPUFREQ_POLICY_PERFORMANCE時選擇面向性能的設置,爲CPUFREQ_POLICY_POWERSAVE時選擇面向省電的設置。
也可以查看drivers/cpufreq/longrun.c中的參考實現。
1.8 get_intermediate 和 target_intermediate
--------------------------------------------
-僅適用於 target_index() 和 CPUFREQ_ASYNC_NOTIFICATION 未設置的驅動。
+僅適用於未設置 target_index() 和 CPUFREQ_ASYNC_NOTIFICATION 的驅動。
-get_intermediate應該返回一個平台想要切換到的穩定的中間頻率,target_intermediate()應該將CPU設置爲
-該頻率,然後再跳轉到'index'對應的頻率。核心會負責發送通知,驅動不必在target_intermediate()或
-target_index()中處理。
+get_intermediate應該返回一個平臺想要切換到的穩定的中間頻率,target_intermediate()應該將CPU設置爲
+該頻率,然後再跳轉到'index'對應的頻率。cpufreq核心會負責發送通知,驅動不必在
+target_intermediate()或target_index()中處理它們。
-在驅動程序不想因爲某個目標頻率切換到中間頻率的情況下,它們可以從get_intermediate()中返回'0'。在這種情況
-下,核心將直接調用->target_index()。
+在驅動程序不想爲某個目標頻率切換到中間頻率的情況下,它們可以讓get_intermediate()返回'0'。
+在這種情況下,cpufreq核心將直接調用->target_index()。
-注意:->target_index()應該在失敗的情況下恢復到policy->restore_freq,因爲core會爲此發送通知。
+注意:->target_index()應該在發生失敗的情況下將頻率恢復到policy->restore_freq,
+因爲cpufreq核心會爲此發送通知。
-2. 頻率表助手
-=============
+2. 頻率表輔助函數
+=================
-由於大多數cpufreq處理器只允許被設置爲幾個特定的頻率,因此,一個帶有一些函數的 「頻率表」可能會輔助處理器驅動
-程序的一些工作。這樣的 "頻率表" 由一個cpufreq_frequency_table條目構成的數組組成,"driver_data" 中包
-含了驅動程序的具體數值,"frequency" 中包含了相應的頻率,並設置了標誌。在表的最後,需要添加一個
-cpufreq_frequency_table條目,頻率設置爲CPUFREQ_TABLE_END。而如果想跳過表中的一個條目,則將頻率設置爲
-CPUFREQ_ENTRY_INVALID。這些條目不需要按照任何特定的順序排序,但如果它們是cpufreq 核心會對它們進行快速的DVFS,
+由於大多數支持cpufreq的處理器只允許被設置爲幾個特定的頻率,因此,"頻率表"和一些相關函數可能會輔助處理器驅動
+程序的一些工作。這樣的"頻率表"是一個由struct cpufreq_frequency_table的條目構成的數組,"driver_data"成員包
+含驅動程序的專用值,"frequency"成員包含了相應的頻率,此外還有標誌成員。在表的最後,需要添加一個
+cpufreq_frequency_table條目,頻率設置爲CPUFREQ_TABLE_END。如果想跳過表中的一個條目,則將頻率設置爲
+CPUFREQ_ENTRY_INVALID。這些條目不需要按照任何特定的順序排序,如果排序了,cpufreq核心執行DVFS會更快一點,
因爲搜索最佳匹配會更快。
-如果策略在其policy->freq_table欄位中包含一個有效的指針,cpufreq表就會被核心自動驗證。
+如果在policy->freq_table字段中包含一個有效的頻率表指針,頻率表就會被cpufreq核心自動驗證。
cpufreq_frequency_table_verify()保證至少有一個有效的頻率在policy->min和policy->max範圍內,並且所有其他
-標準都被滿足。這對->verify調用很有幫助。
+準則都被滿足。這對->verify調用很有幫助。
-cpufreq_frequency_table_target()是對應於->target階段的頻率表助手。只要把數值傳遞給這個函數,這個函數就會返
+cpufreq_frequency_table_target()是對應於->target階段的頻率表輔助函數。只要把值傳遞給這個函數,這個函數就會返
回包含CPU要設置的頻率的頻率表條目。
-以下宏可以作爲cpufreq_frequency_table的疊代器。
+以下宏可以作爲cpufreq_frequency_table的迭代器。
cpufreq_for_each_entry(pos, table) - 遍歷頻率表的所有條目。
cpufreq_for_each_valid_entry(pos, table) - 該函數遍歷所有條目,不包括CPUFREQ_ENTRY_INVALID頻率。
-使用參數 "pos"-一個``cpufreq_frequency_table * `` 作爲循環變量,使用參數 "table"-作爲你想疊代
-的``cpufreq_frequency_table * `` 。
+使用參數"pos" -- 一個 ``cpufreq_frequency_table *`` 作爲循環指針,使用參數"table" -- 作爲你想迭代
+的 ``cpufreq_frequency_table *`` 。
例如::
@@ -251,6 +250,6 @@ cpufreq_for_each_valid_entry(pos, table) - 該函數遍歷所有條目,不包
pos->frequency = ...
}
-如果你需要在driver_freq_table中處理pos的位置,不要減去指針,因爲它的代價相當高。相反,使用宏
+如果你需要在driver_freq_table中處理pos的位置,不要做指針減法,因爲它的代價相當高。作爲替代,使用宏
cpufreq_for_each_entry_idx() 和 cpufreq_for_each_valid_entry_idx() 。
diff --git a/Documentation/translations/zh_TW/cpu-freq/cpufreq-stats.rst b/Documentation/translations/zh_TW/cpu-freq/cpufreq-stats.rst
index d80bfed50e8c..f8d0d462f29a 100644
--- a/Documentation/translations/zh_TW/cpu-freq/cpufreq-stats.rst
+++ b/Documentation/translations/zh_TW/cpu-freq/cpufreq-stats.rst
@@ -13,7 +13,7 @@
sysfs CPUFreq Stats的一般說明
==========================================
-用戶信息
+爲使用者準備的信息
作者: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
@@ -28,17 +28,16 @@ sysfs CPUFreq Stats的一般說明
1. 簡介
===============
-cpufreq-stats是一個爲每個CPU提供CPU頻率統計的驅動。
-這些統計數據在/sysfs中以一堆只讀接口的形式提供。這個接口(在配置好後)將出現在
-/sysfs(<sysfs root>/devices/system/cpu/cpuX/cpufreq/stats/)中cpufreq下的一個單
-獨的目錄中,提供給每個CPU。
-各種統計數據將在此目錄下形成只讀文件。
+cpufreq-stats是一種爲每個CPU提供CPU頻率統計的驅動。
+這些統計數據以/sysfs中一系列只讀接口的形式呈現。cpufreq-stats接口(若已配置)將爲每個CPU生成
+/sysfs(<sysfs root>/devices/system/cpu/cpuX/cpufreq/stats/)中cpufreq目錄下的stats目錄。
+各項統計數據將在stats目錄下形成對應的只讀文件。
-此驅動是獨立於任何可能運行在你所用CPU上的特定cpufreq_driver而設計的。因此,它將與所有
-cpufreq_driver一起工作。
+此驅動是以獨立於任何可能運行在你所用CPU上的特定cpufreq_driver的方式設計的。因此,它將能和任何
+cpufreq_driver協同工作。
-2. 提供的統計數據(舉例說明)
+2. 已提供的統計數據(有例子)
=====================================
cpufreq stats提供了以下統計數據(在下面詳細解釋)。
@@ -47,8 +46,8 @@ cpufreq stats提供了以下統計數據(在下面詳細解釋)。
- total_trans
- trans_table
-所有的統計數據將從統計驅動被載入的時間(或統計被重置的時間)開始,到某一統計數據被讀取的時間爲止。
-顯然,統計驅動不會有任何關於統計驅動載入之前的頻率轉換信息。
+所有統計數據來自以下時間範圍:從統計驅動被加載的時間(或統計數據被重置的時間)開始,到某一統計數據被讀取的時間爲止。
+顯然,統計驅動不會保存它被加載之前的任何頻率轉換信息。
::
@@ -63,14 +62,14 @@ cpufreq stats提供了以下統計數據(在下面詳細解釋)。
- **reset**
-只寫屬性,可用於重置統計計數器。這對於評估不同調節器下的系統行爲非常有用,且無需重啓。
+只寫屬性,可用於重置統計計數器。這對於評估不同調節器的系統行爲非常有用,且無需重啓。
- **time_in_state**
-此項給出了這個CPU所支持的每個頻率所花費的時間。cat輸出的每一行都會有"<frequency>
-<time>"對,表示這個CPU在<frequency>上花費了<time>個usertime單位的時間。這裡的
-usertime單位是10mS(類似於/proc中輸出的其他時間)。
+此文件給出了在本CPU支持的每個頻率上分別花費的時間。cat輸出的每一行都是一個"<frequency>
+<time>"對,表示這個CPU在<frequency>上花費了<time>個usertime單位的時間。輸出的每一行對應
+一個CPU支持的頻率。這裏usertime單位是10mS(類似於/proc導出的其它時間)。
::
@@ -84,7 +83,7 @@ usertime單位是10mS(類似於/proc中輸出的其他時間)。
- **total_trans**
-給出了這個CPU上頻率轉換的總次數。cat的輸出將有一個單一的計數,這就是頻率轉換的總數。
+此文件給出了這個CPU頻率轉換的總次數。cat的輸出是一個計數值,它就是頻率轉換的總次數。
::
@@ -93,10 +92,10 @@ usertime單位是10mS(類似於/proc中輸出的其他時間)。
- **trans_table**
-這將提供所有CPU頻率轉換的細粒度信息。這裡的cat輸出是一個二維矩陣,其中一個條目<i, j>(第
+本文件提供所有CPU頻率轉換的細粒度信息。這裏的cat輸出是一個二維矩陣,其中一個條目<i, j>(第
i行,第j列)代表從Freq_i到Freq_j的轉換次數。Freq_i行和Freq_j列遵循驅動最初提供給cpufreq
-核的頻率表的排序順序,因此可以排序(升序或降序)或不排序。 這裡的輸出也包含了每行每列的實際
-頻率值,以便更好地閱讀。
+核心的頻率表的排列順序,因此可以已排序(升序或降序)或未排序。這裏的輸出也包含了實際
+頻率值,分別按行和按列顯示,以便更好地閱讀。
如果轉換表大於PAGE_SIZE,讀取時將返回一個-EFBIG錯誤。
@@ -114,7 +113,7 @@ i行,第j列)代表從Freq_i到Freq_j的轉換次數。Freq_i行和Freq_j列
3. 配置cpufreq-stats
============================
-要在你的內核中配置cpufreq-stats::
+按以下方式在你的內核中配置cpufreq-stats::
Config Main Menu
Power management options (ACPI, APM) --->
@@ -123,7 +122,7 @@ i行,第j列)代表從Freq_i到Freq_j的轉換次數。Freq_i行和Freq_j列
[*] CPU frequency translation statistics
-"CPU Frequency scaling" (CONFIG_CPU_FREQ) 應該被啓用以配置cpufreq-stats。
+"CPU Frequency scaling" (CONFIG_CPU_FREQ) 應該被啓用,以支持配置cpufreq-stats。
"CPU frequency translation statistics" (CONFIG_CPU_FREQ_STAT)提供了包括
time_in_state、total_trans和trans_table的統計數據。
diff --git a/Documentation/translations/zh_TW/cpu-freq/index.rst b/Documentation/translations/zh_TW/cpu-freq/index.rst
index 1a8e680f95ed..ce717dd6dcd5 100644
--- a/Documentation/translations/zh_TW/cpu-freq/index.rst
+++ b/Documentation/translations/zh_TW/cpu-freq/index.rst
@@ -28,10 +28,10 @@ Author: Dominik Brodowski <linux@brodo.de>
郵件列表
------------
-這裡有一個 CPU 頻率變化的 CVS 提交和通用列表,您可以在這裡報告bug、問題或提交補丁。要發
+這裏有一個 CPU 頻率變化的 CVS 提交和通用列表,您可以在這裏報告bug、問題或提交補丁。要發
布消息,請發送電子郵件到 linux-pm@vger.kernel.org。
-連結
+鏈接
-----
FTP檔案:
* ftp://ftp.linux.org.uk/pub/linux/cpufreq/
--
2.34.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH v3 4/6] docs/zh_TW: update filesystems
2023-08-07 12:00 [PATCH v3 0/6] docs/zh_TW: update zh_TW's documentation from an ascensive aspect Hu Haowen
2023-08-07 12:00 ` [PATCH v3 2/6] docs/zh_TW: update arch Hu Haowen
2023-08-07 12:00 ` [PATCH v3 3/6] docs/zh_TW: update cpu-freq Hu Haowen
@ 2023-08-07 12:00 ` Hu Haowen
2023-08-07 12:00 ` [PATCH v3 6/6] docs/zh_TW: turn zh_CN's folder references and headers into zh_TW's ones Hu Haowen
2023-08-11 20:24 ` [PATCH v3 0/6] docs/zh_TW: update zh_TW's documentation from an ascensive aspect Jonathan Corbet
4 siblings, 0 replies; 6+ messages in thread
From: Hu Haowen @ 2023-08-07 12:00 UTC (permalink / raw)
To: corbet; +Cc: Hu Haowen, linux-doc, linux-kernel
Update zh_TW's filesystems documentation concentrating on the following
aspects:
* The file tree structure changes of the main documentation;
* Some changes and ideas from zh_CN translation;
* Removal for several obsoleted contents within the zh_TW translation
or those which are not exising anymore in the main documentation.
* Replacements for some incorrect words and phrases in traditional
Chinese or those which are odd within their context being hard for
readers to comprehend.
Signed-off-by: Hu Haowen <src.res.211@gmail.com>
---
.../zh_TW/filesystems/debugfs.rst | 38 +++++++++----------
.../translations/zh_TW/filesystems/index.rst | 2 +-
.../translations/zh_TW/filesystems/sysfs.txt | 16 ++++----
.../translations/zh_TW/filesystems/tmpfs.rst | 32 ++++++++--------
.../zh_TW/filesystems/virtiofs.rst | 8 ++--
5 files changed, 47 insertions(+), 49 deletions(-)
diff --git a/Documentation/translations/zh_TW/filesystems/debugfs.rst b/Documentation/translations/zh_TW/filesystems/debugfs.rst
index 270dd94fddf1..45347ae1ccd2 100644
--- a/Documentation/translations/zh_TW/filesystems/debugfs.rst
+++ b/Documentation/translations/zh_TW/filesystems/debugfs.rst
@@ -23,8 +23,8 @@ Debugfs
Debugfs是內核開發人員在用戶空間獲取信息的簡單方法。與/proc不同,proc只提供進程
-信息。也不像sysfs,具有嚴格的「每個文件一個值「的規則。debugfs根本沒有規則,開發
-人員可以在這裡放置他們想要的任何信息。debugfs文件系統也不能用作穩定的ABI接口。
+信息。也不像sysfs,具有嚴格的“每個文件一個值“的規則。debugfs根本沒有規則,開發
+人員可以在這裏放置他們想要的任何信息。debugfs文件系統也不能用作穩定的ABI接口。
從理論上講,debugfs導出文件的時候沒有任何約束。但是[1]實際情況並不總是那麼
簡單。即使是debugfs接口,也最好根據需要進行設計,並儘量保持接口不變。
@@ -34,8 +34,8 @@ Debugfs通常使用以下命令安裝::
mount -t debugfs none /sys/kernel/debug
(或等效的/etc/fstab行)。
-debugfs根目錄默認僅可由root用戶訪問。要更改對文件樹的訪問,請使用「 uid」,「 gid」
-和「 mode」掛載選項。請注意,debugfs API僅按照GPL協議導出到模塊。
+debugfs根目錄默認僅可由root用戶訪問。要更改對文件樹的訪問,請使用“ uid”,“ gid”
+和“ mode”掛載選項。請注意,debugfs API僅按照GPL協議導出到模塊。
使用debugfs的代碼應包含<linux/debugfs.h>。然後,首先是創建至少一個目錄來保存
一組debugfs文件::
@@ -54,8 +54,8 @@ debugfs根目錄默認僅可由root用戶訪問。要更改對文件樹的訪問
struct dentry *parent, void *data,
const struct file_operations *fops);
-在這裡,name是要創建的文件的名稱,mode描述了訪問文件應具有的權限,parent指向
-應該保存文件的目錄,data將存儲在產生的inode結構體的i_private欄位中,而fops是
+在這裏,name是要創建的文件的名稱,mode描述了訪問文件應具有的權限,parent指向
+應該保存文件的目錄,data將存儲在產生的inode結構體的i_private字段中,而fops是
一組文件操作函數,這些函數中實現文件操作的具體行爲。至少,read()和/或
write()操作應提供;其他可以根據需要包括在內。同樣的,返回值將是指向創建文件
的dentry指針,錯誤時返回ERR_PTR(-ERROR),系統不支持debugfs時返回值爲ERR_PTR
@@ -81,7 +81,7 @@ file_size是初始文件大小。其他參數跟函數debugfs_create_file的相
struct dentry *parent, u64 *value);
這些文件支持讀取和寫入給定值。如果某個文件不支持寫入,只需根據需要設置mode
-參數位。這些文件中的值以十進位表示;如果需要使用十六進位,可以使用以下函數
+參數位。這些文件中的值以十進制表示;如果需要使用十六進制,可以使用以下函數
替代::
void debugfs_create_x8(const char *name, umode_t mode,
@@ -93,7 +93,7 @@ file_size是初始文件大小。其他參數跟函數debugfs_create_file的相
void debugfs_create_x64(const char *name, umode_t mode,
struct dentry *parent, u64 *value);
-這些功能只有在開發人員知道導出值的大小的時候才有用。某些數據類型在不同的架構上
+這些功能只有在開發人員知道導出值的大小的時候纔有用。某些數據類型在不同的架構上
有不同的寬度,這樣會使情況變得有些複雜。在這種特殊情況下可以使用以下函數::
void debugfs_create_size_t(const char *name, umode_t mode,
@@ -101,7 +101,7 @@ file_size是初始文件大小。其他參數跟函數debugfs_create_file的相
不出所料,此函數將創建一個debugfs文件來表示類型爲size_t的變量。
-同樣地,也有導出無符號長整型變量的函數,分別以十進位和十六進位表示如下::
+同樣地,也有導出無符號長整型變量的函數,分別以十進制和十六進制表示如下::
struct dentry *debugfs_create_ulong(const char *name, umode_t mode,
struct dentry *parent,
@@ -125,7 +125,7 @@ file_size是初始文件大小。其他參數跟函數debugfs_create_file的相
讀取此文件將獲得atomic_t值,寫入此文件將設置atomic_t值。
-另一個選擇是通過以下結構體和函數導出一個任意二進位數據塊::
+另一個選擇是通過以下結構體和函數導出一個任意二進制數據塊::
struct debugfs_blob_wrapper {
void *data;
@@ -136,10 +136,10 @@ file_size是初始文件大小。其他參數跟函數debugfs_create_file的相
struct dentry *parent,
struct debugfs_blob_wrapper *blob);
-讀取此文件將返回由指針指向debugfs_blob_wrapper結構體的數據。一些驅動使用「blobs」
-作爲一種返回幾行(靜態)格式化文本的簡單方法。這個函數可用於導出二進位信息,但
+讀取此文件將返回由指針指向debugfs_blob_wrapper結構體的數據。一些驅動使用“blobs”
+作爲一種返回幾行(靜態)格式化文本的簡單方法。這個函數可用於導出二進制信息,但
似乎在主線中沒有任何代碼這樣做。請注意,使用debugfs_create_blob()命令創建的
-所有文件是只讀的。
+所有文件是隻讀的。
如果您要轉儲一個寄存器塊(在開發過程中經常會這麼做,但是這樣的調試代碼很少上傳
到主線中。Debugfs提供兩個函數:一個用於創建僅寄存器文件,另一個把一個寄存器塊
@@ -163,7 +163,7 @@ file_size是初始文件大小。其他參數跟函數debugfs_create_file的相
void debugfs_print_regs32(struct seq_file *s, struct debugfs_reg32 *regs,
int nregs, void __iomem *base, char *prefix);
-「base」參數可能爲0,但您可能需要使用__stringify構建reg32數組,實際上有許多寄存器
+“base”參數可能爲0,但您可能需要使用__stringify構建reg32數組,實際上有許多寄存器
名稱(宏)是寄存器塊在基址上的字節偏移量。
如果要在debugfs中轉儲u32數組,可以使用以下函數創建文件::
@@ -172,7 +172,7 @@ file_size是初始文件大小。其他參數跟函數debugfs_create_file的相
struct dentry *parent,
u32 *array, u32 elements);
-「array」參數提供數據,而「elements」參數爲數組中元素的數量。注意:數組創建後,數組
+“array”參數提供數據,而“elements”參數爲數組中元素的數量。注意:數組創建後,數組
大小無法更改。
有一個函數來創建與設備相關的seq_file::
@@ -183,8 +183,8 @@ file_size是初始文件大小。其他參數跟函數debugfs_create_file的相
int (*read_fn)(struct seq_file *s,
void *data));
-「dev」參數是與此debugfs文件相關的設備,並且「read_fn」是一個函數指針,這個函數在
-列印seq_file內容的時候被回調。
+“dev”參數是與此debugfs文件相關的設備,並且“read_fn”是一個函數指針,這個函數在
+打印seq_file內容的時候被回調。
還有一些其他的面向目錄的函數::
@@ -199,7 +199,7 @@ file_size是初始文件大小。其他參數跟函數debugfs_create_file的相
調用debugfs_rename()將爲現有的debugfs文件重命名,可能同時切換目錄。 new_name
函數調用之前不能存在;返回值爲old_dentry,其中包含更新的信息。可以使用
-debugfs_create_symlink()創建符號連結。
+debugfs_create_symlink()創建符號鏈接。
所有debugfs用戶必須考慮的一件事是:
@@ -219,6 +219,6 @@ dentry值可以爲NULL或錯誤值,在這種情況下,不會有任何文件
如果將對應頂層目錄的dentry傳遞給以上函數,則該目錄下的整個層次結構將會被刪除。
-注釋:
+註釋:
[1] http://lwn.net/Articles/309298/
diff --git a/Documentation/translations/zh_TW/filesystems/index.rst b/Documentation/translations/zh_TW/filesystems/index.rst
index 4e5dde0dca3c..415abfe327c1 100644
--- a/Documentation/translations/zh_TW/filesystems/index.rst
+++ b/Documentation/translations/zh_TW/filesystems/index.rst
@@ -12,7 +12,7 @@
Linux Kernel中的文件系統
========================
-這份正在開發的手冊或許在未來某個輝煌的日子裡以易懂的形式將Linux虛擬\
+這份正在開發的手冊或許在未來某個輝煌的日子裏以易懂的形式將Linux虛擬\
文件系統(VFS)層以及基於其上的各種文件系統如何工作呈現給大家。當前\
可以看到下面的內容。
diff --git a/Documentation/translations/zh_TW/filesystems/sysfs.txt b/Documentation/translations/zh_TW/filesystems/sysfs.txt
index 280824cc7e5d..a401739d0914 100644
--- a/Documentation/translations/zh_TW/filesystems/sysfs.txt
+++ b/Documentation/translations/zh_TW/filesystems/sysfs.txt
@@ -1,5 +1,3 @@
-SPDX-License-Identifier: GPL-2.0
-
Chinese translated version of Documentation/filesystems/sysfs.rst
If you have any comment or update to the content, please contact the
@@ -61,7 +59,7 @@ Documentation/core-api/kobject.rst 文檔以獲得更多關於 kobject 接口的
任何 kobject 在系統中註冊,就會有一個目錄在 sysfs 中被創建。這個
目錄是作爲該 kobject 的父對象所在目錄的子目錄創建的,以準確地傳遞
-內核的對象層次到用戶空間。sysfs 中的頂層目錄代表著內核對象層次的
+內核的對象層次到用戶空間。sysfs 中的頂層目錄代表着內核對象層次的
共同祖先;例如:某些對象屬於某個子系統。
Sysfs 在與其目錄關聯的 kernfs_node 對象中內部保存一個指向實現
@@ -198,7 +196,7 @@ Sysfs 將會爲每次讀寫操作調用一次這個方法。這使得這些方
不會不太高。
這使得用戶空間可以局部地讀和任意的向前搜索整個文件。如果用戶空間
- 向後搜索到零或使用『0』偏移執行一個pread(2)操作,show()方法將
+ 向後搜索到零或使用‘0’偏移執行一個pread(2)操作,show()方法將
再次被調用,以重新填充緩存。
- 在寫方面(write(2)),sysfs 希望在第一次寫操作時得到整個緩衝區。
@@ -253,7 +251,7 @@ static DEVICE_ATTR(name, S_IRUGO, show_name, store_name);
(注意:真正的實現不允許用戶空間設置設備名。)
-頂層目錄布局
+頂層目錄佈局
~~~~~~~~~~~~
sysfs 目錄的安排顯示了內核數據結構之間的關係。
@@ -272,23 +270,23 @@ fs/
devices/ 包含了一個設備樹的文件系統表示。他直接映射了內部的內核
設備樹,反映了設備的層次結構。
-bus/ 包含了內核中各種總線類型的平面目錄布局。每個總線目錄包含兩個
+bus/ 包含了內核中各種總線類型的平面目錄佈局。每個總線目錄包含兩個
子目錄:
devices/
drivers/
-devices/ 包含了系統中出現的每個設備的符號連結,他們指向 root/ 下的
+devices/ 包含了系統中出現的每個設備的符號鏈接,他們指向 root/ 下的
設備目錄。
-drivers/ 包含了每個已爲特定總線上的設備而掛載的驅動程序的目錄(這裡
+drivers/ 包含了每個已爲特定總線上的設備而掛載的驅動程序的目錄(這裏
假定驅動沒有跨越多個總線類型)。
fs/ 包含了一個爲文件系統設立的目錄。現在每個想要導出屬性的文件系統必須
在 fs/ 下創建自己的層次結構(參見Documentation/filesystems/fuse.rst)。
dev/ 包含兩個子目錄: char/ 和 block/。在這兩個子目錄中,有以
-<major>:<minor> 格式命名的符號連結。這些符號連結指向 sysfs 目錄
+<major>:<minor> 格式命名的符號鏈接。這些符號鏈接指向 sysfs 目錄
中相應的設備。/sys/dev 提供一個通過一個 stat(2) 操作結果,查找
設備 sysfs 接口快捷的方法。
diff --git a/Documentation/translations/zh_TW/filesystems/tmpfs.rst b/Documentation/translations/zh_TW/filesystems/tmpfs.rst
index 8d753a34785b..16c188436b41 100644
--- a/Documentation/translations/zh_TW/filesystems/tmpfs.rst
+++ b/Documentation/translations/zh_TW/filesystems/tmpfs.rst
@@ -13,18 +13,18 @@ Tmpfs
Tmpfs是一個將所有文件都保存在虛擬內存中的文件系統。
-tmpfs中的所有內容都是臨時的,也就是說沒有任何文件會在硬碟上創建。
+tmpfs中的所有內容都是臨時的,也就是說沒有任何文件會在硬盤上創建。
如果卸載tmpfs實例,所有保存在其中的文件都會丟失。
-tmpfs將所有文件保存在內核緩存中,隨著文件內容增長或縮小可以將不需要的
-頁面swap出去。它具有最大限制,可以通過「mount -o remount ...」調整。
+tmpfs將所有文件保存在內核緩存中,隨着文件內容增長或縮小可以將不需要的
+頁面swap出去。它具有最大限制,可以通過“mount -o remount ...”調整。
和ramfs(創建tmpfs的模板)相比,tmpfs包含交換和限制檢查。和tmpfs相似的另
-一個東西是RAM磁碟(/dev/ram*),可以在物理RAM中模擬固定大小的硬碟,並在
+一個東西是RAM磁盤(/dev/ram*),可以在物理RAM中模擬固定大小的硬盤,並在
此之上創建一個普通的文件系統。Ramdisks無法swap,因此無法調整它們的大小。
由於tmpfs完全保存於頁面緩存和swap中,因此所有tmpfs頁面將在/proc/meminfo
-中顯示爲「Shmem」,而在free(1)中顯示爲「Shared」。請注意,這些計數還包括
+中顯示爲“Shmem”,而在free(1)中顯示爲“Shared”。請注意,這些計數還包括
共享內存(shmem,請參閱ipcs(1))。獲得計數的最可靠方法是使用df(1)和du(1)。
tmpfs具有以下用途:
@@ -45,7 +45,7 @@ tmpfs具有以下用途:
tmpfs的前身(shm fs)才能使用SYSV共享內存)
3) 很多人(包括我)都覺的在/tmp和/var/tmp上掛載非常方便,並具有較大的
- swap分區。目前循環掛載tmpfs可以正常工作,所以大多數發布都應當可以
+ swap分區。目前循環掛載tmpfs可以正常工作,所以大多數發佈都應當可以
使用mkinitrd通過/tmp訪問/tmp。
4) 也許還有更多我不知道的地方:-)
@@ -58,11 +58,11 @@ size tmpfs實例分配的字節數限制。默認值是不swap時物理RAM
如果tmpfs實例過大,機器將死鎖,因爲OOM處理將無法釋放該內存。
nr_blocks 與size相同,但以PAGE_SIZE爲單位。
nr_inodes tmpfs實例的最大inode個數。默認值是物理內存頁數的一半,或者
- (有高端內存的機器)低端內存RAM的頁數,二者以較低者為準。
+ (有高端內存的機器)低端內存RAM的頁數,二者以較低者爲準。
========= ===========================================================
這些參數接受後綴k,m或g表示千,兆和千兆字節,可以在remount時更改。
-size參數也接受後綴%用來限制tmpfs實例占用物理RAM的百分比:
+size參數也接受後綴%用來限制tmpfs實例佔用物理RAM的百分比:
未指定size或nr_blocks時,默認值爲size=50%
如果nr_blocks=0(或size=0),block個數將不受限制;如果nr_inodes=0,
@@ -71,26 +71,26 @@ inode個數將不受限制。這樣掛載通常是不明智的,因爲它允許
場景下的訪問。
tmpfs具有爲所有文件設置NUMA內存分配策略掛載選項(如果啓用了CONFIG_NUMA),
-可以通過「mount -o remount ...」調整
+可以通過“mount -o remount ...”調整
======================== =========================
mpol=default 採用進程分配策略
(請參閱 set_mempolicy(2))
mpol=prefer:Node 傾向從給定的節點分配
-mpol=bind:NodeList 只允許從指定的鍊表分配
+mpol=bind:NodeList 只允許從指定的鏈表分配
mpol=interleave 傾向於依次從每個節點分配
mpol=interleave:NodeList 依次從每個節點分配
mpol=local 優先本地節點分配內存
======================== =========================
-NodeList格式是以逗號分隔的十進位數字表示大小和範圍,最大和最小範圍是用-
-分隔符的十進位數來表示。例如,mpol=bind0-3,5,7,9-15
+NodeList格式是以逗號分隔的十進制數字表示大小和範圍,最大和最小範圍是用-
+分隔符的十進制數來表示。例如,mpol=bind0-3,5,7,9-15
帶有有效NodeList的內存策略將按指定格式保存,在創建文件時使用。當任務在該
文件系統上創建文件時,會使用到掛載時的內存策略NodeList選項,如果設置的話,
由調用任務的cpuset[請參見Documentation/admin-guide/cgroup-v1/cpusets.rst]
以及下面列出的可選標誌約束。如果NodeLists爲設置爲空集,則文件的內存策略將
-恢復爲「默認」策略。
+恢復爲“默認”策略。
NUMA內存分配策略有可選標誌,可以用於模式結合。在掛載tmpfs時指定這些可選
標誌可以在NodeList之前生效。
@@ -107,12 +107,12 @@ Documentation/admin-guide/mm/numa_memory_policy.rst列出所有可用的內存
請注意,如果內核不支持NUMA,那麼使用mpol選項掛載tmpfs將會失敗;nodelist指定不
在線的節點也會失敗。如果您的系統依賴於此,但內核會運行不帶NUMA功能(也許是安全
revocery內核),或者具有較少的節點在線,建議從自動模式中省略mpol選項掛載選項。
-可以在以後通過「mount -o remount,mpol=Policy:NodeList MountPoint」添加到掛載點。
+可以在以後通過“mount -o remount,mpol=Policy:NodeList MountPoint”添加到掛載點。
要指定初始根目錄,可以使用如下掛載選項:
==== ====================
-模式 權限用八進位數字表示
+模式 權限用八進制數字表示
uid 用戶ID
gid 組ID
==== ====================
@@ -129,7 +129,7 @@ inode32 使用32位inode
在32位內核上,默認是inode32,掛載時指定inode64會被拒絕。
在64位內核上,默認配置是CONFIG_TMPFS_INODE64。inode64避免了單個設備上可能有多個
-具有相同inode編號的文件;比如32位應用程式使用glibc如果長期訪問tmpfs,一旦達到33
+具有相同inode編號的文件;比如32位應用程序使用glibc如果長期訪問tmpfs,一旦達到33
位inode編號,就有EOVERFLOW失敗的危險,無法打開大於2GiB的文件,並返回EINVAL。
所以'mount -t tmpfs -o size=10G,nr_inodes=10k,mode=700 tmpfs /mytmpfs'將在
diff --git a/Documentation/translations/zh_TW/filesystems/virtiofs.rst b/Documentation/translations/zh_TW/filesystems/virtiofs.rst
index 2b05e84375dd..05274d9e0843 100644
--- a/Documentation/translations/zh_TW/filesystems/virtiofs.rst
+++ b/Documentation/translations/zh_TW/filesystems/virtiofs.rst
@@ -21,7 +21,7 @@ virtiofs: virtio-fs 主機<->客機共享文件系統
介紹
====
-Linux的virtiofs文件系統實現了一個半虛擬化VIRTIO類型「virtio-fs」設備的驅動,通過該\
+Linux的virtiofs文件系統實現了一個半虛擬化VIRTIO類型“virtio-fs”設備的驅動,通過該\
類型設備實現客機<->主機文件系統共享。它允許客機掛載一個已經導出到主機的目錄。
客機通常需要訪問主機或者遠程系統上的文件。使用場景包括:在新客機安裝時讓文件對其\
@@ -42,12 +42,12 @@ Linux的virtiofs文件系統實現了一個半虛擬化VIRTIO類型「virtio-fs
guest# mount -t virtiofs myfs /mnt
-請查閱 https://virtio-fs.gitlab.io/ 了解配置QEMU和virtiofsd守護程序的詳細信息。
+請查閱 https://virtio-fs.gitlab.io/ 瞭解配置QEMU和virtiofsd守護程序的詳細信息。
內幕
====
由於virtio-fs設備將FUSE協議用於文件系統請求,因此Linux的virtiofs文件系統與FUSE文\
-件系統客戶端緊密集成在一起。客機充當FUSE客戶端而主機充當FUSE伺服器,內核與用戶空\
+件系統客戶端緊密集成在一起。客機充當FUSE客戶端而主機充當FUSE服務器,內核與用戶空\
間之間的/dev/fuse接口由virtio-fs設備接口代替。
FUSE請求被置於虛擬隊列中由主機處理。主機填充緩衝區中的響應部分,而客機處理請求的完成部分。
@@ -55,7 +55,7 @@ FUSE請求被置於虛擬隊列中由主機處理。主機填充緩衝區中的
將/dev/fuse映射到虛擬隊列需要解決/dev/fuse和虛擬隊列之間語義上的差異。每次讀取\
/dev/fuse設備時,FUSE客戶端都可以選擇要傳輸的請求,從而可以使某些請求優先於其他\
請求。虛擬隊列有其隊列語義,無法更改已入隊請求的順序。在虛擬隊列已滿的情況下尤
-其關鍵,因爲此時不可能加入高優先級的請求。爲了解決此差異,virtio-fs設備採用「hiprio」\
+其關鍵,因爲此時不可能加入高優先級的請求。爲了解決此差異,virtio-fs設備採用“hiprio”\
(高優先級)虛擬隊列,專門用於有別於普通請求的高優先級請求。
--
2.34.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH v3 6/6] docs/zh_TW: turn zh_CN's folder references and headers into zh_TW's ones
2023-08-07 12:00 [PATCH v3 0/6] docs/zh_TW: update zh_TW's documentation from an ascensive aspect Hu Haowen
` (2 preceding siblings ...)
2023-08-07 12:00 ` [PATCH v3 4/6] docs/zh_TW: update filesystems Hu Haowen
@ 2023-08-07 12:00 ` Hu Haowen
2023-08-11 20:24 ` [PATCH v3 0/6] docs/zh_TW: update zh_TW's documentation from an ascensive aspect Jonathan Corbet
4 siblings, 0 replies; 6+ messages in thread
From: Hu Haowen @ 2023-08-07 12:00 UTC (permalink / raw)
To: corbet; +Cc: Hu Haowen, linux-doc, linux-kernel
Some contents under zh_TW's translation folder contain folder references
and headers that refer to zh_CN's locations. Hence replace them.
Signed-off-by: Hu Haowen <src.res.211@gmail.com>
---
.../translations/zh_TW/admin-guide/README.rst | 6 +++---
.../zh_TW/admin-guide/reporting-issues.rst | 12 ++++++------
.../zh_TW/admin-guide/reporting-regressions.rst | 10 +++++-----
.../zh_TW/admin-guide/security-bugs.rst | 2 +-
.../translations/zh_TW/arch/arm64/booting.txt | 2 +-
.../zh_TW/arch/arm64/silicon-errata.txt | 2 +-
.../translations/zh_TW/process/1.Intro.rst | 14 +++++++-------
.../translations/zh_TW/process/4.Coding.rst | 2 +-
.../translations/zh_TW/process/5.Posting.rst | 14 +++++++-------
.../translations/zh_TW/process/8.Conclusion.rst | 4 ++--
.../process/code-of-conduct-interpretation.rst | 2 +-
.../zh_TW/process/code-of-conduct.rst | 2 +-
.../translations/zh_TW/process/coding-style.rst | 4 ++--
.../translations/zh_TW/process/howto.rst | 12 ++++++------
.../zh_TW/process/management-style.rst | 4 ++--
.../zh_TW/process/stable-kernel-rules.rst | 2 +-
.../zh_TW/process/submit-checklist.rst | 6 +++---
.../zh_TW/process/submitting-patches.rst | 16 ++++++++--------
18 files changed, 58 insertions(+), 58 deletions(-)
diff --git a/Documentation/translations/zh_TW/admin-guide/README.rst b/Documentation/translations/zh_TW/admin-guide/README.rst
index 4cb581f5994a..e132993abce6 100644
--- a/Documentation/translations/zh_TW/admin-guide/README.rst
+++ b/Documentation/translations/zh_TW/admin-guide/README.rst
@@ -284,12 +284,12 @@ Linux內核6.x版本 <http://kernel.org/>
-----------
如果您發現了一些可能由於內核缺陷所導致的問題,請參閱:
-Documentation/translations/zh_CN/admin-guide/reporting-issues.rst 。
+Documentation/translations/zh_TW/admin-guide/reporting-issues.rst 。
想要理解內核錯誤報告,請參閱:
-Documentation/translations/zh_CN/admin-guide/bug-hunting.rst 。
+Documentation/translations/zh_TW/admin-guide/bug-hunting.rst 。
更多用GDB調試內核的信息,請參閱:
-Documentation/translations/zh_CN/dev-tools/gdb-kernel-debugging.rst
+Documentation/translations/zh_TW/dev-tools/gdb-kernel-debugging.rst
和 Documentation/dev-tools/kgdb.rst 。
diff --git a/Documentation/translations/zh_TW/admin-guide/reporting-issues.rst b/Documentation/translations/zh_TW/admin-guide/reporting-issues.rst
index fe5a5a07d51a..ff2d406ab4d5 100644
--- a/Documentation/translations/zh_TW/admin-guide/reporting-issues.rst
+++ b/Documentation/translations/zh_TW/admin-guide/reporting-issues.rst
@@ -301,7 +301,7 @@ Documentation/admin-guide/reporting-regressions.rst 對此進行了更詳細的
添加到迴歸跟蹤列表中,以確保它不會被忽略。
什麼是安全問題留給您自己判斷。在繼續之前,請考慮閱讀
-Documentation/translations/zh_CN/admin-guide/security-bugs.rst ,
+Documentation/translations/zh_TW/admin-guide/security-bugs.rst ,
因爲它提供瞭如何最恰當地處理安全問題的額外細節。
當發生了完全無法接受的糟糕事情時,此問題就是一個“非常嚴重的問題”。例如,
@@ -385,7 +385,7 @@ Linux內核破壞了它處理的數據或損壞了它運行的硬件。當內核
核未被污染,那麼它應該以“Not infected”結束;如果你看到“Tainted:”且後跟一些
空格和字母,那就被污染了。
-如果你的內核被污染了,請閱讀 Documentation/translations/zh_CN/admin-guide/tainted-kernels.rst
+如果你的內核被污染了,請閱讀 Documentation/translations/zh_TW/admin-guide/tainted-kernels.rst
以找出原因。設法消除污染因素。通常是由以下三種因素之一引起的:
1. 發生了一個可恢復的錯誤(“kernel Oops”),內核污染了自己,因爲內核知道在
@@ -798,7 +798,7 @@ Linux 首席開發者 Linus Torvalds 認爲 Linux 內核永遠不應惡化,這
重現它。
有一個叫做“二分”的過程可以來尋找變化,這在
-Documentation/translations/zh_CN/admin-guide/bug-bisect.rst 文檔中進行了詳細
+Documentation/translations/zh_TW/admin-guide/bug-bisect.rst 文檔中進行了詳細
的描述,這個過程通常需要你構建十到二十個內核鏡像,每次都嘗試在構建下一個鏡像
之前重現問題。是的,這需要花費一些時間,但不用擔心,它比大多數人想象的要快得多。
多虧了“binary search二分搜索”,這將引導你在源代碼管理系統中找到導致迴歸的提交。
@@ -984,7 +984,7 @@ Documentation/admin-guide/reporting-regressions.rst ;它還提供了大量其
報告,請將報告的文本轉發到這些地址;但請在報告的頂部加上註釋,表明您提交了
報告,並附上工單鏈接。
-更多信息請參見 Documentation/translations/zh_CN/admin-guide/security-bugs.rst 。
+更多信息請參見 Documentation/translations/zh_TW/admin-guide/security-bugs.rst 。
發佈報告後的責任
@@ -1198,7 +1198,7 @@ FLOSS 問題報告的人看,詢問他們的意見。同時徵求他們關於
前一段基本粗略地概述了“二分”方法。一旦報告出來,您可能會被要求做一個正確的
報告,因爲它允許精確地定位導致問題的確切更改(然後很容易被恢復以快速修復問題)。
因此如果時間允許,考慮立即進行適當的二分。有關如何詳細信息,請參閱“對迴歸的
-特別關照”部分和文檔 Documentation/translations/zh_CN/admin-guide/bug-bisect.rst 。
+特別關照”部分和文檔 Documentation/translations/zh_TW/admin-guide/bug-bisect.rst 。
如果成功二分的話,請將“罪魁禍首”的作者添加到收件人中;同時抄送所有在
signed-off-by鏈中的人,您可以在提交消息的末尾找到。
@@ -1217,7 +1217,7 @@ signed-off-by鏈中的人,您可以在提交消息的末尾找到。
即使是微小的、看似明顯的代碼變化,有時也會帶來新的、完全意想不到的問題。穩
定版和長期支持內核的維護者非常清楚這一點,因此他們只對這些內核進行符合
-Documentation/translations/zh_CN/process/stable-kernel-rules.rst 中所列出的
+Documentation/translations/zh_TW/process/stable-kernel-rules.rst 中所列出的
規則的修改。
複雜或有風險的修改不符合條件,因此只能應用於主線。其他的修復很容易被回溯到
diff --git a/Documentation/translations/zh_TW/admin-guide/reporting-regressions.rst b/Documentation/translations/zh_TW/admin-guide/reporting-regressions.rst
index d7dcb2a26564..38149b0f6493 100644
--- a/Documentation/translations/zh_TW/admin-guide/reporting-regressions.rst
+++ b/Documentation/translations/zh_TW/admin-guide/reporting-regressions.rst
@@ -28,7 +28,7 @@ Torvalds立下了此規則並確保它被落實。
能用,那麼你就碰見迴歸問題了。注意,新內核需要使用類似配置編譯;更多相關細
節參見下方。
-#. 按照 Documentation/translations/zh_CN/admin-guide/reporting-issues.rst 中
+#. 按照 Documentation/translations/zh_TW/admin-guide/reporting-issues.rst 中
所說的報告你的問題,該文檔已經包含了所有關於迴歸的重要方面,爲了方便起見也
複製到了下面。兩個重點:在報告主題中使用“[REGRESSION]”開頭並抄送或轉發到
`迴歸郵件列表 <https://lore.kernel.org/regressions/>`_
@@ -71,7 +71,7 @@ Torvalds立下了此規則並確保它被落實。
如何報告迴歸?
~~~~~~~~~~~~~~
-只需按照 Documentation/translations/zh_CN/admin-guide/reporting-issues.rst 中
+只需按照 Documentation/translations/zh_TW/admin-guide/reporting-issues.rst 中
所說的報告你的問題,該文檔已經包含了要點。下面幾點概述了一下只在迴歸中重要的
方面:
@@ -133,8 +133,8 @@ regzbot發送的每週迴歸報告,可能會出現延遲。 這樣的延誤會
如何找到罪魁禍首?
~~~~~~~~~~~~~~~~~~
-如 Documentation/translations/zh_CN/admin-guide/reporting-issues.rst (簡要)
-和 Documentation/translations/zh_CN/admin-guide/bug-bisect.rst (詳細)中所
+如 Documentation/translations/zh_TW/admin-guide/reporting-issues.rst (簡要)
+和 Documentation/translations/zh_TW/admin-guide/bug-bisect.rst (詳細)中所
述,執行二分。聽起來工作量很大,但大部分情況下很快就能找到罪魁禍首。如果這很
困難或可靠地重現問題很耗時,請考慮與其他受影響的用戶合作,一起縮小搜索範圍。
@@ -364,7 +364,7 @@ Regzbot還支持其他一些主要由開發人員或迴歸追蹤人員使用的
..
如本文件開頭所述,本文以GPL-2.0+或CC-BY-4.0許可發行。如您想僅在CC-BY-4.0許
可下重分發本文,請用“Linux內核開發者”作爲作者,並用如下鏈接作爲來源:
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/translations/zh_CN/admin-guide/reporting-regressions.rst
+ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/translations/zh_TW/admin-guide/reporting-regressions.rst
..
注意:本RST文件內容只有在來自Linux內核源代碼時是使用CC-BY-4.0許可的,因爲經
過處理的版本(如經內核的構建系統)可能包含來自使用更嚴格許可證的文件的內容。
diff --git a/Documentation/translations/zh_TW/admin-guide/security-bugs.rst b/Documentation/translations/zh_TW/admin-guide/security-bugs.rst
index c0e9fc247695..a2e196b3ad6a 100644
--- a/Documentation/translations/zh_TW/admin-guide/security-bugs.rst
+++ b/Documentation/translations/zh_TW/admin-guide/security-bugs.rst
@@ -24,7 +24,7 @@ Linux內核開發人員非常重視安全性。因此我們想知道何時發現
人員那裏獲得額外的幫助,以理解和修復安全漏洞。
與任何缺陷一樣,提供的信息越多,診斷和修復就越容易。如果您不清楚哪些信息有用,
-請查看“Documentation/translations/zh_CN/admin-guide/reporting-issues.rst”中
+請查看“Documentation/translations/zh_TW/admin-guide/reporting-issues.rst”中
概述的步驟。任何利用漏洞的攻擊代碼都非常有用,未經報告者同意不會對外發布,除
非已經公開。
diff --git a/Documentation/translations/zh_TW/arch/arm64/booting.txt b/Documentation/translations/zh_TW/arch/arm64/booting.txt
index af1bd2d7eec1..80487c86d3eb 100644
--- a/Documentation/translations/zh_TW/arch/arm64/booting.txt
+++ b/Documentation/translations/zh_TW/arch/arm64/booting.txt
@@ -9,7 +9,7 @@ help. Contact the Chinese maintainer if this translation is outdated
or if there is a problem with the translation.
M: Will Deacon <will.deacon@arm.com>
-zh_CN: Fu Wei <wefu@redhat.com>
+zh_TW: Fu Wei <wefu@redhat.com>
zh_TW: Hu Haowen <src.res@email.cn>
C: 55f058e7574c3615dea4615573a19bdb258696c6
---------------------------------------------------------------------
diff --git a/Documentation/translations/zh_TW/arch/arm64/silicon-errata.txt b/Documentation/translations/zh_TW/arch/arm64/silicon-errata.txt
index 9d1f49a6b6e7..cdcb3b338cb1 100644
--- a/Documentation/translations/zh_TW/arch/arm64/silicon-errata.txt
+++ b/Documentation/translations/zh_TW/arch/arm64/silicon-errata.txt
@@ -9,7 +9,7 @@ help. Contact the Chinese maintainer if this translation is outdated
or if there is a problem with the translation.
M: Will Deacon <will.deacon@arm.com>
-zh_CN: Fu Wei <wefu@redhat.com>
+zh_TW: Fu Wei <wefu@redhat.com>
zh_TW: Hu Haowen <src.res@email.cn>
C: 1926e54f115725a9248d0c4c65c22acaf94de4c4
---------------------------------------------------------------------
diff --git a/Documentation/translations/zh_TW/process/1.Intro.rst b/Documentation/translations/zh_TW/process/1.Intro.rst
index 53f3f3135d47..a5ac77942bef 100644
--- a/Documentation/translations/zh_TW/process/1.Intro.rst
+++ b/Documentation/translations/zh_TW/process/1.Intro.rst
@@ -26,31 +26,31 @@
的自動可用性、多種形式的社區支持以及影響內核開發方向的能力。提供給Linux內核
的代碼必須在與GPL兼容的許可證下可用。
-:ref:`cn_development_process` 介紹了開發過程、內核發佈週期和合並窗口的機制。
+:ref:`tw_development_process` 介紹了開發過程、內核發佈週期和合並窗口的機制。
涵蓋了補丁開發、審查和合並週期中的各個階段。還有一些關於工具和郵件列表的討論?
鼓勵希望開始內核開發的開發人員跟蹤並修復缺陷以作爲初步練習。
-:ref:`cn_development_early_stage` 包括項目的早期規劃,重點是儘快讓開發社區
+:ref:`tw_development_early_stage` 包括項目的早期規劃,重點是儘快讓開發社區
參與進來。
-:ref:`cn_development_coding` 是關於編程過程的;介紹了其他開發人員遇到的幾個
+:ref:`tw_development_coding` 是關於編程過程的;介紹了其他開發人員遇到的幾個
陷阱。也涵蓋了對補丁的一些要求,並且介紹了一些工具,這些工具有助於確保內核
補丁是正確的。
-:ref:`cn_development_posting` 描述發佈補丁以供評審的過程。爲了讓開發社區能
+:ref:`tw_development_posting` 描述發佈補丁以供評審的過程。爲了讓開發社區能
認真對待,補丁必須被正確格式化和描述,並且必須發送到正確的地方。遵循本節中的
建議有助於確保您的工作能被較好地接納。
-:ref:`cn_development_followthrough` 介紹了發佈補丁之後發生的事情;工作在這時
+:ref:`tw_development_followthrough` 介紹了發佈補丁之後發生的事情;工作在這時
還遠遠沒有完成。與審閱者一起工作是開發過程中的一個重要部分;本節提供了一些
關於如何在這個重要階段避免問題的提示。當補丁被合併到主線中時,開發人員要注意
不要假定任務已經完成。
-:ref:`cn_development_advancedtopics` 介紹了兩個“高級”主題:使用Git管理補丁
+:ref:`tw_development_advancedtopics` 介紹了兩個“高級”主題:使用Git管理補丁
和查看其他人發佈的補丁。
-:ref:`cn_development_conclusion` 總結了有關內核開發的更多信息,附帶有相關資源
+:ref:`tw_development_conclusion` 總結了有關內核開發的更多信息,附帶有相關資源
鏈接。
這個文檔是關於什麼的
diff --git a/Documentation/translations/zh_TW/process/4.Coding.rst b/Documentation/translations/zh_TW/process/4.Coding.rst
index 96b8c0bd8423..8b7b4a3248c8 100644
--- a/Documentation/translations/zh_TW/process/4.Coding.rst
+++ b/Documentation/translations/zh_TW/process/4.Coding.rst
@@ -32,7 +32,7 @@
********
內核長期以來都有其標準的代碼風格,如
-:ref:`Documentation/translations/zh_CN/process/coding-style.rst <cn_codingstyle>`
+:ref:`Documentation/translations/zh_TW/process/coding-style.rst <tw_codingstyle>`
中所述。在多數時候,該文檔中描述的準則至多被認爲是建議性的。因此,內核中存在
大量不符合代碼風格準則的代碼。這種代碼的存在會給內核開發人員帶來兩方面的危害。
diff --git a/Documentation/translations/zh_TW/process/5.Posting.rst b/Documentation/translations/zh_TW/process/5.Posting.rst
index caef6e0b31a5..2bd87b8358d5 100644
--- a/Documentation/translations/zh_TW/process/5.Posting.rst
+++ b/Documentation/translations/zh_TW/process/5.Posting.rst
@@ -22,8 +22,8 @@
內核開發社區已經發展出一套用於發佈補丁的約定和過程;遵循這些約定和過程將使
參與其中的每個人的生活更加輕鬆。本文檔試圖描述這些約定的部分細節;更多信息
也可在以下文檔中找到
-:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
-和 :ref:`Documentation/translations/zh_CN/process/submit-checklist.rst <cn_submitchecklist>`。
+:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
+和 :ref:`Documentation/translations/zh_TW/process/submit-checklist.rst <tw_submitchecklist>`。
何時寄送
--------
@@ -154,7 +154,7 @@
其傳遞給diff。
上面提到的標籤(tag)用於描述各種開發人員如何與這個補丁的開發相關聯。
-:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
+:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
文檔中對它們進行了詳細描述;下面是一個簡短的總結。每一行的格式如下:
::
@@ -165,14 +165,14 @@
- Signed-off-by: 這是一個開發人員的證明,證明他或她有權提交補丁以包含到內核
中。這表明同意開發者來源認證協議,其全文見
- :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
+ :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 <cn_submittingpatches>`
+ :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
- Acked-by: 表示另一個開發人員(通常是相關代碼的維護人員)同意補丁適合包含
在內核中。
@@ -180,7 +180,7 @@
- Tested-by: 聲明某人已經測試了補丁並確認它可以工作。
- Reviewed-by: 表示某開發人員已經審查了補丁的正確性;有關詳細信息,請參閱
- :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
+ :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
- Reported-by: 指定報告此補丁修復的問題的用戶;此標記用於表示感謝。
@@ -197,7 +197,7 @@
無法被另一端接受,並且通常不會進行任何詳細檢查。如果有任何疑問,先把補丁寄
給你自己,讓你自己確定它是完好無損的。
- :ref:`Documentation/translations/zh_CN/process/email-clients.rst <cn_email_clients>`
+ :ref:`Documentation/translations/zh_TW/process/email-clients.rst <tw_email_clients>`
提供了一些有用的提示,可以讓特定的郵件客戶端正常發送補丁。
- 你確定你的補丁沒有荒唐的錯誤嗎?您應該始終通過scripts/checkpatch.pl檢查
diff --git a/Documentation/translations/zh_TW/process/8.Conclusion.rst b/Documentation/translations/zh_TW/process/8.Conclusion.rst
index 3ae08a41fd78..cac4b794c84a 100644
--- a/Documentation/translations/zh_TW/process/8.Conclusion.rst
+++ b/Documentation/translations/zh_TW/process/8.Conclusion.rst
@@ -19,9 +19,9 @@
關於Linux內核開發和相關主題的信息來源很多。首先是在內核源代碼分發中找到的
文檔目錄。頂級
-:ref:`Documentation/translations/zh_CN/process/howto.rst <cn_process_howto>`
+:ref:`Documentation/translations/zh_TW/process/howto.rst <tw_process_howto>`
文件是一個重要的起點;
-:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
+:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
也是所有內核開發人員都應該閱讀的內容。許多內部內核API都是使用kerneldoc機制
記錄的;“make htmldocs”或“make pdfdocs”可用於以HTML或PDF格式生成這些文檔
(儘管某些發行版提供的tex版本會遇到內部限制,無法正確處理文檔)。
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 70293eb332b9..843ba484abdc 100644
--- a/Documentation/translations/zh_TW/process/code-of-conduct-interpretation.rst
+++ b/Documentation/translations/zh_TW/process/code-of-conduct-interpretation.rst
@@ -11,7 +11,7 @@
Linux內核貢獻者契約行爲準則解釋
===============================
-:ref:`cn_code_of_conduct` 準則是一個通用文檔,旨在爲幾乎所有開源社區提供一套規則。
+:ref:`tw_code_of_conduct` 準則是一個通用文檔,旨在爲幾乎所有開源社區提供一套規則。
每個開源社區都是獨一無二的,Linux內核也不例外。因此,本文描述了Linux內核社區中
如何解釋它。我們也不希望這種解釋隨着時間的推移是靜態的,並將根據需要進行調整。
diff --git a/Documentation/translations/zh_TW/process/code-of-conduct.rst b/Documentation/translations/zh_TW/process/code-of-conduct.rst
index 588bc364f6ed..2eb9be27d64b 100644
--- a/Documentation/translations/zh_TW/process/code-of-conduct.rst
+++ b/Documentation/translations/zh_TW/process/code-of-conduct.rst
@@ -72,5 +72,5 @@ https://www.contributor-covenant.org/version/1/4/code-of-conduct.html 獲取。
解釋
====
-有關Linux內核社區如何解釋此文檔,請參閱 :ref:`cn_code_of_conduct_interpretation`
+有關Linux內核社區如何解釋此文檔,請參閱 :ref:`tw_code_of_conduct_interpretation`
diff --git a/Documentation/translations/zh_TW/process/coding-style.rst b/Documentation/translations/zh_TW/process/coding-style.rst
index d49b9db21011..3f9f75808f98 100644
--- a/Documentation/translations/zh_TW/process/coding-style.rst
+++ b/Documentation/translations/zh_TW/process/coding-style.rst
@@ -543,7 +543,7 @@ Linux 裏這是提倡的做法,因爲這樣可以很簡單的給讀者提供
也可以加上它做這些事情的原因。
當註釋內核 API 函數時,請使用 kernel-doc 格式。詳見
-Documentation/translations/zh_CN/doc-guide/index.rst 和 scripts/kernel-doc 。
+Documentation/translations/zh_TW/doc-guide/index.rst 和 scripts/kernel-doc 。
長 (多行) 註釋的首選風格是:
@@ -816,7 +816,7 @@ dev_info() 等等。對於那些不和某個特定設備相關連的信息,<li
內核提供了下面的一般用途的內存分配函數:
kmalloc(), kzalloc(), kmalloc_array(), kcalloc(), vmalloc() 和 vzalloc()。
請參考 API 文檔以獲取有關它們的詳細信息:
-Documentation/translations/zh_CN/core-api/memory-allocation.rst 。
+Documentation/translations/zh_TW/core-api/memory-allocation.rst 。
傳遞結構體大小的首選形式是這樣的:
diff --git a/Documentation/translations/zh_TW/process/howto.rst b/Documentation/translations/zh_TW/process/howto.rst
index ae19d1eda30f..a22901728a2b 100644
--- a/Documentation/translations/zh_TW/process/howto.rst
+++ b/Documentation/translations/zh_TW/process/howto.rst
@@ -65,7 +65,7 @@ Linux內核使用GNU C和GNU工具鏈開發。雖然它遵循ISO C11標準,但
Linux內核源代碼都是在GPL(通用公共許可證)的保護下發布的。要了解這種許可
的細節請查看源代碼主目錄下的COPYING文件。Linux內核許可準則和如何使用
`SPDX <https://spdx.org/>` 標誌符說明在這個文件中
-:ref:`Documentation/translations/zh_CN/process/license-rules.rst <cn_kernel_licensing>`
+:ref:`Documentation/translations/zh_TW/process/license-rules.rst <tw_kernel_licensing>`
如果你對它還有更深入問題請聯繫律師,而不要在Linux內核郵件組上提問。因爲
郵件組裏的人並不是律師,不要期望他們的話有法律效力。
@@ -91,12 +91,12 @@ Linux內核代碼中包含有大量的文檔。這些文檔對於學習如何與
:ref:`Documentation/process/changes.rst <changes>`
文件給出了用來編譯和使用內核所需要的最小軟件包列表。
- :ref:`Documentation/translations/zh_CN/process/coding-style.rst <cn_codingstyle>`
+ :ref:`Documentation/translations/zh_TW/process/coding-style.rst <tw_codingstyle>`
描述Linux內核的代碼風格和理由。所有新代碼需要遵守這篇文檔中定義的規
範。大多數維護者只會接收符合規定的補丁,很多人也只會幫忙檢查符合風格
的代碼。
- :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
+ :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
這兩份文檔明確描述如何創建和發送補丁,其中包括(但不僅限於):
- 郵件內容
@@ -115,7 +115,7 @@ Linux內核代碼中包含有大量的文檔。這些文檔對於學習如何與
https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html
- :ref:`Documentation/translations/zh_CN/process/stable-api-nonsense.rst <cn_stable_api_nonsense>`
+ :ref:`Documentation/translations/zh_TW/process/stable-api-nonsense.rst <tw_stable_api_nonsense>`
論證內核爲什麼特意不包括穩定的內核內部API,也就是說不包括像這樣的特
性:
@@ -130,7 +130,7 @@ Linux內核代碼中包含有大量的文檔。這些文檔對於學習如何與
如果你認爲自己發現了Linux內核的安全性問題,請根據這篇文檔中的步驟來
提醒其他內核開發者並幫助解決這個問題。
- :ref:`Documentation/translations/zh_CN/process/management-style.rst <cn_managementstyle>`
+ :ref:`Documentation/translations/zh_TW/process/management-style.rst <tw_managementstyle>`
描述內核維護者的工作方法及其共有特點。這對於剛剛接觸內核開發(或者對
它感到好奇)的人來說很重要,因爲它解釋了很多對於內核維護者獨特行爲的
@@ -333,7 +333,7 @@ MAINTAINERS文件中可以找到不同話題對應的郵件列表。
這幾行。將你的評論加在被引用的段落之間而不要放在郵件的頂部。
如果你在郵件中附帶補丁,請確認它們是可以直接閱讀的純文本(如
-:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
+:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
文檔中所述)。內核開發者們不希望遇到附件或者被壓縮了的補丁。只有這樣才能
保證他們可以直接評論你的每行代碼。請確保你使用的郵件發送程序不會修改空格
和製表符。一個防範性的測試方法是先將郵件發送給自己,然後自己嘗試是否可以
diff --git a/Documentation/translations/zh_TW/process/management-style.rst b/Documentation/translations/zh_TW/process/management-style.rst
index 2d373f71e976..80d5db27a8de 100644
--- a/Documentation/translations/zh_TW/process/management-style.rst
+++ b/Documentation/translations/zh_TW/process/management-style.rst
@@ -31,7 +31,7 @@ Linux內核管理風格
不管怎樣,這裏是:
-.. _cn_decisions:
+.. _tw_decisions:
1)決策
-------
@@ -111,7 +111,7 @@ Linux內核管理風格
但是,爲了做好作爲內核管理者的準備,最好記住不要燒掉任何橋樑,不要轟炸任何
無辜的村民,也不要疏遠太多的內核開發人員。事實證明,疏遠人是相當容易的,而
親近一個疏遠的人是很難的。因此,“疏遠”立即屬於“不可逆”的範疇,並根據
-:ref:`cn_decisions` 成爲絕不可以做的事情。
+:ref:`tw_decisions` 成爲絕不可以做的事情。
這裏只有幾個簡單的規則:
diff --git a/Documentation/translations/zh_TW/process/stable-kernel-rules.rst b/Documentation/translations/zh_TW/process/stable-kernel-rules.rst
index 4c66eb448eaa..5da43e010102 100644
--- a/Documentation/translations/zh_TW/process/stable-kernel-rules.rst
+++ b/Documentation/translations/zh_TW/process/stable-kernel-rules.rst
@@ -36,7 +36,7 @@
- 沒有“理論上的競爭條件”,除非能給出競爭條件如何被利用的解釋。
- 不能存在任何的“瑣碎的”修正(拼寫修正,去掉多餘空格之類的)。
- 必須被相關子系統的維護者接受。
- - 必須遵循Documentation/translations/zh_CN/process/submitting-patches.rst裏的規則。
+ - 必須遵循Documentation/translations/zh_TW/process/submitting-patches.rst裏的規則。
向穩定版代碼樹提交補丁的過程:
------------------------------
diff --git a/Documentation/translations/zh_TW/process/submit-checklist.rst b/Documentation/translations/zh_TW/process/submit-checklist.rst
index 942962d1e2f4..00924da85e2b 100644
--- a/Documentation/translations/zh_TW/process/submit-checklist.rst
+++ b/Documentation/translations/zh_TW/process/submit-checklist.rst
@@ -16,7 +16,7 @@ Linux內核補丁提交檢查單
如果開發人員希望看到他們的內核補丁提交更快地被接受,那麼他們應該做一些基本
的事情。
-這些都是在 Documentation/translations/zh_CN/process/submitting-patches.rst
+這些都是在 Documentation/translations/zh_TW/process/submitting-patches.rst
和其他有關提交Linux內核補丁的文檔中提供的。
1) 如果使用工具,則包括定義/聲明該工具的文件。不要依賴其他頭文件來引入您使用
@@ -39,7 +39,7 @@ Linux內核補丁提交檢查單
4) PPC64是一種很好的交叉編譯檢查體系結構,因爲它傾向於對64位的數使用無符號
長整型。
-5) 按 Documentation/translations/zh_CN/process/coding-style.rst 所述檢查您的
+5) 按 Documentation/translations/zh_TW/process/coding-style.rst 所述檢查您的
補丁是否爲常規樣式。在提交之前使用補丁樣式檢查器 ``scripts/checkpatch.pl``
檢查是否有輕微的衝突。您應該能夠處理您的補丁中存在的所有
違規行爲。
@@ -54,7 +54,7 @@ Linux內核補丁提交檢查單
回報的。
9) 通過 sparse 清查。
- (參見 Documentation/translations/zh_CN/dev-tools/sparse.rst )
+ (參見 Documentation/translations/zh_TW/dev-tools/sparse.rst )
10) 使用 ``make checkstack`` 和 ``make namespacecheck`` 並修復他們發現的任何
問題。
diff --git a/Documentation/translations/zh_TW/process/submitting-patches.rst b/Documentation/translations/zh_TW/process/submitting-patches.rst
index ac1c3bb78adb..12042f60fb8f 100644
--- a/Documentation/translations/zh_TW/process/submitting-patches.rst
+++ b/Documentation/translations/zh_TW/process/submitting-patches.rst
@@ -25,8 +25,8 @@
的改動被接受的機會.
本文檔以較爲簡潔的行文給出了大量建議。關於內核開發流程如何進行的詳細信息,
-參見: 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 。
@@ -162,7 +162,7 @@ xyzzy do frotz”或“[I]changed xyzzy to do frotz”,就好像你在命令
----------------
檢查您的補丁是否違反了基本樣式規定,詳細信息參見
-Documentation/translations/zh_CN/process/coding-style.rst
+Documentation/translations/zh_TW/process/coding-style.rst
中找到。如果不這樣做,只會浪費審閱者的時間,並且會導致你的補丁被拒絕,甚至
可能沒有被閱讀。
@@ -209,7 +209,7 @@ torvalds@linux-foundation.org 。他收到的郵件很多,所以一般來說
如果您有修復可利用安全漏洞的補丁,請將該補丁發送到 security@kernel.org 。對於
嚴重的bug,可以考慮短期禁令以允許分銷商(有時間)向用戶發佈補丁;在這種情況下,
顯然不應將補丁發送到任何公共列表。
-參見 Documentation/translations/zh_CN/admin-guide/security-bugs.rst 。
+參見 Documentation/translations/zh_TW/admin-guide/security-bugs.rst 。
修復已發佈內核中嚴重錯誤的補丁程序應該抄送給穩定版維護人員,方法是把以下列行
放進補丁的籤準區(注意,不是電子郵件收件人)::
@@ -217,7 +217,7 @@ torvalds@linux-foundation.org 。他收到的郵件很多,所以一般來說
Cc: stable@vger.kernel.org
除了本文件之外,您還應該閱讀
-Documentation/translations/zh_CN/process/stable-kernel-rules.rst 。
+Documentation/translations/zh_TW/process/stable-kernel-rules.rst 。
如果更改影響到用戶側內核接口,請向手冊頁維護人員(如維護人員文件中所列)發送
手冊頁補丁,或至少發送更改通知,以便一些信息進入手冊頁。還應將用戶空間API
@@ -248,7 +248,7 @@ Linus 和其他的內核開發者需要閱讀和評論你提交的改動。對
例外:如果你的郵路損壞了補丁,那麼有人可能會要求你使用MIME重新發送補丁。
-請參閱 Documentation/translations/zh_CN/process/email-clients.rst
+請參閱 Documentation/translations/zh_TW/process/email-clients.rst
以獲取有關配置電子郵件客戶端以使其不受影響地發送補丁的提示。
回覆審閱意見
@@ -443,7 +443,7 @@ Fixes: 指示補丁修復了之前提交的一個問題。它可以便於確定
附加Fixes:標籤不會改變穩定內核規則流程,也不改變所有穩定版補丁抄送
stable@vger.kernel.org的要求。有關更多信息,請閱讀
- Documentation/translations/zh_CN/process/stable-kernel-rules.rst 。
+ Documentation/translations/zh_TW/process/stable-kernel-rules.rst 。
.. _zh_the_canonical_patch_format:
@@ -647,7 +647,7 @@ Greg Kroah-Hartman,“如何惹惱內核子系統維護人員”
不!!!別再發巨型補丁炸彈給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>
--
2.34.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v3 0/6] docs/zh_TW: update zh_TW's documentation from an ascensive aspect
2023-08-07 12:00 [PATCH v3 0/6] docs/zh_TW: update zh_TW's documentation from an ascensive aspect Hu Haowen
` (3 preceding siblings ...)
2023-08-07 12:00 ` [PATCH v3 6/6] docs/zh_TW: turn zh_CN's folder references and headers into zh_TW's ones Hu Haowen
@ 2023-08-11 20:24 ` Jonathan Corbet
4 siblings, 0 replies; 6+ messages in thread
From: Jonathan Corbet @ 2023-08-11 20:24 UTC (permalink / raw)
To: Hu Haowen; +Cc: Hu Haowen, linux-doc, linux-kernel
Hu Haowen <src.res.211@gmail.com> writes:
> Update zh_TW's documentation concentrating on the following aspects:
>
> * The file tree structure changes of the main documentation;
> * Some changes and ideas from zh_CN translation;
> * Removal for several obsoleted contents within the zh_TW translation
> or those which are not exising anymore in the main documentation.
> * Replacements for some incorrect words and phrases in traditional
> Chinese or those which are odd within their context being hard for
> readers to comprehend.
>
> v3:
> * Remove the fancy character thoroughly asked by Corbet.
>
> v2:
> * Remove the fancy character U+feff (ZERO WIDTH NO-BREAK SPACE) reported by Corbet
> in https://lore.kernel.org/lkml/87bkg5dp6x.fsf@meer.lwn.net/.
>
> v1:
> https://lore.kernel.org/lkml/20230720132729.1821-1-src.res.211@gmail.com/
>
So this series does not even come close to applying to docs-next; it
includes things like the email-address change that you sent me a month
ago. What are you generating it against?
Please. We have been through a few too many rounds of this at this
point. If you can send me something I can apply against my tree, I'll
look at it, but *make sure* it's a reasonable patch series before you
send it again.
jon
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-08-11 20:25 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-08-07 12:00 [PATCH v3 0/6] docs/zh_TW: update zh_TW's documentation from an ascensive aspect Hu Haowen
2023-08-07 12:00 ` [PATCH v3 2/6] docs/zh_TW: update arch Hu Haowen
2023-08-07 12:00 ` [PATCH v3 3/6] docs/zh_TW: update cpu-freq Hu Haowen
2023-08-07 12:00 ` [PATCH v3 4/6] docs/zh_TW: update filesystems Hu Haowen
2023-08-07 12:00 ` [PATCH v3 6/6] docs/zh_TW: turn zh_CN's folder references and headers into zh_TW's ones Hu Haowen
2023-08-11 20:24 ` [PATCH v3 0/6] docs/zh_TW: update zh_TW's documentation from an ascensive aspect Jonathan Corbet
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).