Merge tag 'Chinese-docs-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/alexs/linux into tmp

Chinese translation docs for 7.1

This is the Chinese translation subtree for 7.1. It includes
the following changes:
        - Add the rust docs translation
        - Fix an inconsistent statement in dev-tools/testing-overview
        - sync process/2.Process.rst with English version

Above patches are tested by 'make htmldocs'

Signed-off-by: Alex Shi <alexs@kernel.org>

6 files changed, 427 insertions, 109 deletions

diff --git a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
index 286ed6b01f65..8bdc51b47b5e 100644
--- a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
+++ b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
@@ -154,7 +154,7 @@ Smatch和Coccinelle的强项
 Coccinelle可能是最容易写检查的。它在预处理器之前工作，所以用Coccinelle
 检查宏中的错误更容易。Coccinelle还能为你创建补丁，这是其他工具无法做到的。
 
-例如，用Coccinelle你可以从 ``kmalloc_array(x, size, GFP_KERNEL)``
+例如，用Coccinelle你可以从 ``kmalloc(x * size, GFP_KERNEL)``
 到 ``kmalloc_array(x, size, GFP_KERNEL)`` 进行大规模转换，这真的很
 有用。如果你只是创建一个Smatch警告，并试图把转换的工作推给维护者，他们会很
 恼火。你将不得不为每个警告争论是否真的可以溢出。
diff --git a/Documentation/translations/zh_CN/process/2.Process.rst b/Documentation/translations/zh_CN/process/2.Process.rst
index 31b0e2c994f6..ca00672c313e 100644
--- a/Documentation/translations/zh_CN/process/2.Process.rst
+++ b/Documentation/translations/zh_CN/process/2.Process.rst
@@ -23,21 +23,18 @@
 总览
 ----
 
-内核开发人员使用一个松散的基于时间的发布过程，每两到三个月发布一次新的主要
-内核版本。最近的发布历史记录如下：
-
-	======  =================
-	5.0	2019年3月3日
-	5.1	2019年5月5日
-	5.2	2019年7月7日
-	5.3	2019年9月15日
-	5.4	2019年11月24日
-	5.5	2020年1月6日
-	======  =================
-
-每个5.x版本都是一个主要的内核版本，具有新特性、内部API更改等等。一个典型的5.x
-版本包含大约13000个变更集，变更了几十万行代码。因此，5.x是Linux内核开发的前
-沿；内核使用滚动开发模型，不断集成重大变化。
+内核开发使用一个松散的、基于时间的滚动发布（rolling release）开发模型。
+一个新的主内核发行版本（作为示例，我们将其称为 9.x） [1]_ 大约每两到三个月
+发布一次，它带来了新特性、内部 API 的更改等。一个典型的版本包含大约 13,000
+个变更集（changesets），涉及几十万行代码的修改。最近的发行版本及其日期可以
+在这里找到
+`维基百科 <https://en.wikipedia.org/wiki/Linux_kernel_version_history>`_
+
+
+.. [1] 严格来说，Linux 内核并不采用语义化版本号方案，而是将 9.x 这一组数字
+       作为一个整体来标识主发行版本号。对于每一个版本，x 都会递增，但只有
+       当 x 被认为足够大时，9 才会递增（例如：Linux 5.0 是紧随 Linux 4.20
+       之后发布的）。
 
 对于每个版本的补丁合并，遵循一个相对简单的规则。在每个开发周期的开头，“合并
 窗口”被打开。这时，被认为足够稳定（并且被开发社区接受）的代码被合并到主线内
@@ -48,8 +45,8 @@
 提前收集、测试和分级的。稍后将详细描述该过程的工作方式。）
 
 合并窗口持续大约两周。在这段时间结束时，Linus Torvalds将声明窗口已关闭，并
-释放第一个“rc”内核。例如，对于目标为5.6的内核，在合并窗口结束时发生的释放
-将被称为5.6-rc1。-rc1 版本是一个信号，表示合并新特性的时间已经过去，稳定下一
+释放第一个“rc”内核。例如，对于目标为9.x的内核，在合并窗口结束时发生的释放
+将被称为9.x-rc1。-rc1 版本是一个信号，表示合并新特性的时间已经过去，稳定下一
 个内核的时间已经到来。
 
 在接下来的6到10周内，只有修复问题的补丁才应该提交给主线。有时会允许更大的
@@ -84,11 +81,14 @@
 开发人员的目标是在稳定发布之前修复所有已知的回归。在现实世界中，这种完美是
 很难实现的；在这种规模的项目中，变数太多了。需要说明的是，延迟最终版本只会
 使问题变得更糟；等待下一个合并窗口的更改将变多，导致下次出现更多的回归错误。
-因此，大多数5.x内核都有一些已知的回归错误，不过，希望没有一个是严重的。
+因此，大多数内核发布时都会带有一部分已知的回归问题，不过希望它们都不是严重
+的问题。
 
 一旦一个稳定的版本发布，它的持续维护工作就被移交给“稳定团队”，目前由
-Greg Kroah-Hartman领导。稳定团队将使用5.x.y编号方案不定期地发布稳定版本的
-更新。要合入更新版本，补丁必须（1）修复一个重要的缺陷，且（2）已经合并到
+Greg Kroah-Hartman领导。稳定团队将使用9.x.y编号方案不定期地发布稳定版本的
+更新。
+
+要合入更新版本，补丁必须（1）修复一个重要的缺陷，且（2）已经合并到
 下一个开发版本主线中。内核通常会在其初始版本后的一个以上的开发周期内收到
 稳定版更新。例如，5.2内核的历史如下（2019年）：
 
@@ -105,17 +105,10 @@ Greg Kroah-Hartman领导。稳定团队将使用5.x.y编号方案不定期地发
 
 5.2.21是5.2版本的最终稳定更新。
 
-有些内核被指定为“长期”内核；它们将得到更长时间的支持。在本文中，当前的长期
-内核及其维护者是：
+有些内核被指定为“长期”内核；它们将得到更长时间的支持。请参考以下链接
+获取当前长期支持内核版本及其维护者的列表：
 
-	======  ================================	================
-	3.16	Ben Hutchings				（长期稳定内核）
-	4.4	Greg Kroah-Hartman & Sasha Levin	（长期稳定内核）
-	4.9	Greg Kroah-Hartman & Sasha Levin
-	4.14	Greg Kroah-Hartman & Sasha Levin
-	4.19	Greg Kroah-Hartman & Sasha Levin
-	5.4	Greg Kroah-Hartman & Sasha Levin
-	======  ================================	================
+  https://www.kernel.org/category/releases.html
 
 长期支持内核的选择纯粹是维护人员是否有需求和时间来维护该版本的问题。
 目前还没有为即将发布的任何特定版本提供长期支持的已知计划。
@@ -320,7 +313,8 @@ Quilt 是一个补丁管理系统，而不是源代码管理系统。它不会�
   没有完成家庭作业的人感到不耐烦。
 
 - 避免顶部回复（把你的答案放在你要回复的引文上面的做法）。这会让你的回答更难
-  理解，印象也很差。
+  理解，印象也很差，详细请查看
+  :ref:`Documentation/process/submitting-patches.rst <interleaved_replies>`
 
 - 在正确的邮件列表发问。linux-kernel 可能是通用的讨论场所，但它不是寻找所有
   子系统开发人员的最佳场所。
diff --git a/Documentation/translations/zh_CN/rust/arch-support.rst b/Documentation/translations/zh_CN/rust/arch-support.rst
index abd708d48f82..f5ae44588a57 100644
--- a/Documentation/translations/zh_CN/rust/arch-support.rst
+++ b/Documentation/translations/zh_CN/rust/arch-support.rst
@@ -19,9 +19,10 @@
 =============  ================  ==============================================
 架构           支持水平           限制因素
 =============  ================  ==============================================
-``arm64``      Maintained        只有小端序
+``arm``        Maintained        仅 ARMv7 小端序。
+``arm64``      Maintained        仅小端序。
 ``loongarch``  Maintained        \-
-``riscv``      Maintained        只有 ``riscv64``
-``um``         Maintained        只有 ``x86_64``
-``x86``        Maintained        只有 ``x86_64``
+``riscv``      Maintained        仅 ``riscv64``，且仅限 LLVM/Clang。
+``um``         Maintained        \-
+``x86``        Maintained        仅 ``x86_64``。
 =============  ================  ==============================================
diff --git a/Documentation/translations/zh_CN/rust/coding-guidelines.rst b/Documentation/translations/zh_CN/rust/coding-guidelines.rst
index 419143b938ed..54b902322dbc 100644
--- a/Documentation/translations/zh_CN/rust/coding-guidelines.rst
+++ b/Documentation/translations/zh_CN/rust/coding-guidelines.rst
@@ -37,6 +37,73 @@
 像内核其他部分的 ``clang-format`` 一样， ``rustfmt`` 在单个文件上工作，并且不需要
 内核配置。有时，它甚至可以与破碎的代码一起工作。
 
+导入
+~~~~
+
+``rustfmt`` 默认会以一种在合并和变基时容易产生冲突的方式格式化导入，因为在某些情况下
+它会将多个条目合并到同一行。例如：
+
+.. code-block:: rust
+
+	// Do not use this style.
+	use crate::{
+	    example1,
+	    example2::{example3, example4, example5},
+	    example6, example7,
+	    example8::example9,
+	};
+
+相反，内核使用如下所示的垂直布局：
+
+.. code-block:: rust
+
+	use crate::{
+	    example1,
+	    example2::{
+	        example3,
+	        example4,
+	        example5, //
+	    },
+	    example6,
+	    example7,
+	    example8::example9, //
+	};
+
+也就是说，每个条目占一行，只要列表中有多个条目就使用花括号。
+
+末尾的空注释可以保留这种格式。不仅如此， ``rustfmt`` 在添加空注释后实际上会将导入重
+新格式化为垂直布局。也就是说，可以通过对如下输入运行 ``rustfmt`` 来轻松地将原始示例
+重新格式化为预期的风格：
+
+.. code-block:: rust
+
+	// Do not use this style.
+	use crate::{
+	    example1,
+	    example2::{example3, example4, example5, //
+	    },
+	    example6, example7,
+	    example8::example9, //
+	};
+
+末尾的空注释适用于嵌套导入（如上所示）以及单条目导入——这有助于最小化补丁系列中的差
+异：
+
+.. code-block:: rust
+
+	use crate::{
+	    example1, //
+	};
+
+末尾的空注释可以放在花括号内的任何一行中，但建议放在最后一个条目上，因为这让人联想到其
+他格式化工具中的末尾逗号。有时在补丁系列中由于列表的变更，避免多次移动注释可能更简单。
+
+在某些情况下可能需要例外处理，即以上都不是硬性规则。也有一些代码尚未迁移到这种风格，但
+请不要引入其他风格的代码。
+
+最终目标是让 ``rustfmt`` 在稳定版本中自动支持这种格式化风格（或类似的风格），而无需
+末尾的空注释。因此，在某个时候，目标是移除这些注释。
+
 
 注释
 ----
@@ -77,6 +144,16 @@
 	    // ...
 	}
 
+这适用于公共和私有项目。这增加了与公共项目的一致性，允许在更改可见性时减少涉及的更改，
+并允许我们将来也为私有项目生成文档。换句话说，如果为私有项目编写了文档，那么仍然应该使
+用 ``///`` 。例如：
+
+.. code-block:: rust
+
+	/// My private function.
+	// TODO: ...
+	fn f() {}
+
 一种特殊的注释是 ``// SAFETY:`` 注释。这些注释必须出现在每个 ``unsafe`` 块之前，它们
 解释了为什么该块内的代码是正确/健全的，即为什么它在任何情况下都不会触发未定义行为，例如:
 
@@ -131,27 +208,27 @@ https://commonmark.org/help/
 
 这个例子展示了一些 ``rustdoc`` 的特性和内核中遵循的一些惯例:
 
-  - 第一段必须是一个简单的句子，简要地描述被记录的项目的作用。进一步的解释必须放在额
-    外的段落中。
+- 第一段必须是一个简单的句子，简要地描述被记录的项目的作用。进一步的解释必须放在额
+  外的段落中。
 
-  - 不安全的函数必须在 ``# Safety`` 部分记录其安全前提条件。
+- 不安全的函数必须在 ``# Safety`` 部分记录其安全前提条件。
 
-  - 虽然这里没有显示，但如果一个函数可能会恐慌，那么必须在 ``# Panics`` 部分描述发
-    生这种情况的条件。
+- 虽然这里没有显示，但如果一个函数可能会恐慌，那么必须在 ``# Panics`` 部分描述发
+  生这种情况的条件。
 
-    请注意，恐慌应该是非常少见的，只有在有充分理由的情况下才会使用。几乎在所有的情况下，
-    都应该使用一个可失败的方法，通常是返回一个 ``Result``。
+  请注意，恐慌应该是非常少见的，只有在有充分理由的情况下才会使用。几乎在所有的情况下，
+  都应该使用一个可失败的方法，通常是返回一个 ``Result``。
 
-  - 如果提供使用实例对读者有帮助的话，必须写在一个叫做``# Examples``的部分。
+- 如果提供使用实例对读者有帮助的话，必须写在一个叫做``# Examples``的部分。
 
-  - Rust项目（函数、类型、常量……）必须有适当的链接(``rustdoc`` 会自动创建一个
-    链接)。
+- Rust项目（函数、类型、常量……）必须有适当的链接(``rustdoc`` 会自动创建一个
+  链接)。
 
-  - 任何 ``unsafe`` 的代码块都必须在前面加上一个 ``// SAFETY:`` 的注释，描述里面
-    的代码为什么是正确的。
+- 任何 ``unsafe`` 的代码块都必须在前面加上一个 ``// SAFETY:`` 的注释，描述里面
+  的代码为什么是正确的。
 
-    虽然有时原因可能看起来微不足道，但写这些注释不仅是记录已经考虑到的问题的好方法，
-    最重要的是，它提供了一种知道没有额外隐含约束的方法。
+  虽然有时原因可能看起来微不足道，但写这些注释不仅是记录已经考虑到的问题的好方法，
+  最重要的是，它提供了一种知道没有额外隐含约束的方法。
 
 要了解更多关于如何编写Rust和拓展功能的文档，请看看 ``rustdoc`` 这本书，网址是:
 
@@ -170,6 +247,22 @@ https://commonmark.org/help/
        /// [`struct mutex`]: srctree/include/linux/mutex.h
 
 
+C FFI 类型
+----------
+
+Rust 内核代码使用类型别名（如 ``c_int``）来引用 C 类型（如 ``int``），这些别名可
+以直接从 ``kernel`` 预导入（prelude）中获取。请不要使用 ``core::ffi`` 中的别
+名——它们可能无法映射到正确的类型。
+
+这些别名通常应该直接通过其标识符引用，即作为单段路径。例如：
+
+.. code-block:: rust
+
+	fn f(p: *const c_char) -> c_int {
+	    // ...
+	}
+
+
 命名
 ----
 
@@ -202,3 +295,144 @@ Rust内核代码遵循通常的Rust命名空间:
 
 也就是说， ``GPIO_LINE_DIRECTION_IN`` 的等价物将被称为 ``gpio::LineDirection::In`` 。
 特别是，它不应该被命名为 ``gpio::gpio_line_direction::GPIO_LINE_DIRECTION_IN`` 。
+
+
+代码检查提示（Lints）
+---------------------
+
+在 Rust 中，可以在局部 ``allow`` 特定的警告（诊断信息、代码检查提示（lint）），
+使编译器忽略给定函数、模块、代码块等中给定警告的实例。
+
+这类似于 C 中的 ``#pragma GCC diagnostic push`` + ``ignored`` + ``pop``
+[#]_：
+
+.. code-block:: c
+
+	#pragma GCC diagnostic push
+	#pragma GCC diagnostic ignored "-Wunused-function"
+	static void f(void) {}
+	#pragma GCC diagnostic pop
+
+.. [#] 在这个特定情况下，可以使用内核的 ``__{always,maybe}_unused`` 属性
+       （C23 的 ``[[maybe_unused]]``）；然而，此示例旨在反映下文讨论的 Rust 中
+       的等效代码检查提示。
+
+但要简洁得多：
+
+.. code-block:: rust
+
+	#[allow(dead_code)]
+	fn f() {}
+
+凭借这一点，可以更方便地默认启用更多诊断（即在 ``W=`` 级别之外）。特别是那些可能有
+一些误报但在其他方面非常有用的诊断，保持启用可以捕获潜在的错误。
+
+在此基础上，Rust 提供了 ``expect`` 属性，更进一步。如果警告没有产生，它会让编译器
+发出警告。例如，以下代码将确保当 ``f()`` 在某处被调用时，我们必须移除该属性：
+
+.. code-block:: rust
+
+	#[expect(dead_code)]
+	fn f() {}
+
+如果我们不这样做，编译器会发出警告::
+
+	warning: this lint expectation is unfulfilled
+	 --> x.rs:3:10
+	  |
+	3 | #[expect(dead_code)]
+	  |          ^^^^^^^^^
+	  |
+	  = note: `#[warn(unfulfilled_lint_expectations)]` on by default
+
+这意味着 ``expect`` 不会在不需要时被遗忘，这可能发生在以下几种情况中：
+
+- 开发过程中添加的临时属性。
+
+- 编译器、Clippy 或自定义工具中代码检查提示的改进可能消除误报。
+
+- 当代码检查提示不再需要时，因为预期它会在某个时候被移除，例如上面的
+  ``dead_code`` 示例。
+
+这也增加了剩余 ``allow`` 的可见性，并减少了误用的可能性。
+
+因此，优先使用 ``expect`` 而不是 ``allow``，除非：
+
+- 条件编译在某些情况下触发警告，在其他情况下不触发。
+
+  如果与总的相比，只有少数情况触发（或不触发）警告，那么可以考虑使用条件
+  ``expect``（即 ``cfg_attr(..., expect(...))``）。否则，使用 ``allow`` 可
+  能更简单。
+
+- 在宏内部，不同的调用可能会创建在某些情况下触发警告而在其他情况下不触发的展开代码。
+
+- 当代码可能在某些架构上触发警告但在其他架构上不触发时，例如到 C FFI 类型的 ``as``
+  转换。
+
+作为一个更详细的示例，考虑以下程序：
+
+.. code-block:: rust
+
+	fn g() {}
+
+	fn main() {
+	    #[cfg(CONFIG_X)]
+	    g();
+	}
+
+这里，如果 ``CONFIG_X`` 未设置，函数 ``g()`` 是死代码。我们可以在这里使用
+``expect`` 吗？
+
+.. code-block:: rust
+
+	#[expect(dead_code)]
+	fn g() {}
+
+	fn main() {
+	    #[cfg(CONFIG_X)]
+	    g();
+	}
+
+如果 ``CONFIG_X`` 被设置，这将产生代码检查提示，因为在该配置中它不是死代码。因
+此，在这种情况下，我们不能直接使用 ``expect``。
+
+一个简单的可能性是使用 ``allow``：
+
+.. code-block:: rust
+
+	#[allow(dead_code)]
+	fn g() {}
+
+	fn main() {
+	    #[cfg(CONFIG_X)]
+	    g();
+	}
+
+另一种方法是使用条件 ``expect``：
+
+.. code-block:: rust
+
+	#[cfg_attr(not(CONFIG_X), expect(dead_code))]
+	fn g() {}
+
+	fn main() {
+	    #[cfg(CONFIG_X)]
+	    g();
+	}
+
+这将确保如果有人在某处引入了对 ``g()`` 的另一个调用（例如无条件的），那么将会被发现
+它不再是死代码。然而， ``cfg_attr`` 比简单的 ``allow`` 更复杂。
+
+因此，当涉及多个配置或者代码检查提示可能由于非局部更改（如 ``dead_code``）而触发
+时，使用条件 ``expect`` 可能不值得。
+
+有关 Rust 中诊断的更多信息，请参阅：
+
+	https://doc.rust-lang.org/stable/reference/attributes/diagnostics.html
+
+错误处理
+--------
+
+有关 Rust for Linux 特定错误处理的背景和指南，请参阅：
+
+	https://rust.docs.kernel.org/kernel/error/type.Result.html#error-codes-in-c-and-rust
diff --git a/Documentation/translations/zh_CN/rust/index.rst b/Documentation/translations/zh_CN/rust/index.rst
index 5347d4729588..138e057bee44 100644
--- a/Documentation/translations/zh_CN/rust/index.rst
+++ b/Documentation/translations/zh_CN/rust/index.rst
@@ -12,16 +12,6 @@ Rust
 
 与内核中的Rust有关的文档。若要开始在内核中使用Rust，请阅读 quick-start.rst 指南。
 
-Rust 实验
----------
-Rust 支持在 v6.1 版本中合并到主线，以帮助确定 Rust 作为一种语言是否适合内核，
-即是否值得进行权衡。
-
-目前，Rust 支持主要面向对 Rust 支持感兴趣的内核开发人员和维护者，
-以便他们可以开始处理抽象和驱动程序，并帮助开发基础设施和工具。
-
-如果您是终端用户，请注意，目前没有适合或旨在生产使用的内置驱动程序或模块，
-并且 Rust 支持仍处于开发/实验阶段，尤其是对于特定内核配置。
 
 代码文档
 --------
@@ -50,10 +40,3 @@ Rust 支持在 v6.1 版本中合并到主线，以帮助确定 Rust 作为一种
     testing
 
 你还可以在 :doc:`../../../process/kernel-docs` 中找到 Rust 的学习材料。
-
-.. only::  subproject and html
-
-   Indices
-   =======
-
-   * :ref:`genindex`
diff --git a/Documentation/translations/zh_CN/rust/quick-start.rst b/Documentation/translations/zh_CN/rust/quick-start.rst
index 8616556ae4d7..5f0ece6411f5 100644
--- a/Documentation/translations/zh_CN/rust/quick-start.rst
+++ b/Documentation/translations/zh_CN/rust/quick-start.rst
@@ -13,16 +13,138 @@
 
 本文介绍了如何开始使用Rust进行内核开发。
 
+安装内核开发所需的 Rust 工具链有几种方式。一种简单的方式是使用 Linux 发行版的软件包
+（如果它们合适的话）——下面的第一节解释了这种方法。这种方法的一个优势是，通常发行版会
+匹配 Rust 和 Clang 所使用的 LLVM。
+
+另一种方式是使用 `kernel.org <https://kernel.org/pub/tools/llvm/rust/>`_ 上提
+供的预构建稳定版本的 LLVM+Rust。这些与 :ref:`获取 LLVM <zh_cn_getting_llvm>` 中的精
+简快速 LLVM 工具链相同，并添加了 Rust for Linux 支持的 Rust 版本。提供了两套工具
+链："最新 LLVM" 和 "匹配 LLVM"（请参阅链接了解更多信息）。
+
+或者，接下来的两个 "依赖" 章节将解释每个组件以及如何通过 ``rustup``、Rust 的独立
+安装程序或从源码构建来安装它们。
+
+本文档的其余部分解释了有关如何入门的其他方面。
+
+
+发行版
+------
+
+Arch Linux
+**********
+
+Arch Linux 提供较新的 Rust 版本，因此通常开箱即用，例如::
+
+	pacman -S rust rust-src rust-bindgen
+
+
+Debian
+******
+
+Debian 13（Trixie）以及 Testing 和 Debian Unstable（Sid）提供较新的 Rust 版
+本，因此通常开箱即用，例如::
+
+	apt install rustc rust-src bindgen rustfmt rust-clippy
+
+
+Fedora Linux
+************
+
+Fedora Linux 提供较新的 Rust 版本，因此通常开箱即用，例如::
+
+	dnf install rust rust-src bindgen-cli rustfmt clippy
+
+
+Gentoo Linux
+************
+
+Gentoo Linux（尤其是 testing 分支）提供较新的 Rust 版本，因此通常开箱即用，
+例如::
+
+	USE='rust-src rustfmt clippy' emerge dev-lang/rust dev-util/bindgen
+
+可能需要设置 ``LIBCLANG_PATH``。
+
+
+Nix
+***
+
+Nix（unstable 频道）提供较新的 Rust 版本，因此通常开箱即用，例如::
+
+	{ pkgs ? import <nixpkgs> {} }:
+	pkgs.mkShell {
+	  nativeBuildInputs = with pkgs; [ rustc rust-bindgen rustfmt clippy ];
+	  RUST_LIB_SRC = "${pkgs.rust.packages.stable.rustPlatform.rustLibSrc}";
+	}
+
+
+openSUSE
+********
+
+openSUSE Slowroll 和 openSUSE Tumbleweed 提供较新的 Rust 版本，因此通常开箱
+即用，例如::
+
+	zypper install rust rust1.79-src rust-bindgen clang
+
+
+Ubuntu
+******
+
+25.04
+~~~~~
+
+最新的 Ubuntu 版本提供较新的 Rust 版本，因此通常开箱即用，例如::
+
+	apt install rustc rust-src bindgen rustfmt rust-clippy
+
+此外，需要设置 ``RUST_LIB_SRC``，例如::
+
+	RUST_LIB_SRC=/usr/src/rustc-$(rustc --version | cut -d' ' -f2)/library
+
+为方便起见，可以将 ``RUST_LIB_SRC`` 导出到全局环境中。
+
+
+24.04 LTS 及更早版本
+~~~~~~~~~~~~~~~~~~~~
+
+虽然 Ubuntu 24.04 LTS 及更早版本仍然提供较新的 Rust 版本，但它们需要一些额外的配
+置，使用带版本号的软件包，例如::
+
+	apt install rustc-1.80 rust-1.80-src bindgen-0.65 rustfmt-1.80 \
+		rust-1.80-clippy
+	ln -s /usr/lib/rust-1.80/bin/rustfmt /usr/bin/rustfmt-1.80
+	ln -s /usr/lib/rust-1.80/bin/clippy-driver /usr/bin/clippy-driver-1.80
+
+这些软件包都不会将其工具设置为默认值；因此应该显式指定它们，例如::
+
+	make LLVM=1 RUSTC=rustc-1.80 RUSTDOC=rustdoc-1.80 RUSTFMT=rustfmt-1.80 \
+		CLIPPY_DRIVER=clippy-driver-1.80 BINDGEN=bindgen-0.65
+
+或者，修改 ``PATH`` 变量将 Rust 1.80 的二进制文件放在前面，并将 ``bindgen`` 设
+置为默认值，例如::
+
+	PATH=/usr/lib/rust-1.80/bin:$PATH
+	update-alternatives --install /usr/bin/bindgen bindgen \
+		/usr/bin/bindgen-0.65 100
+	update-alternatives --set bindgen /usr/bin/bindgen-0.65
+
+使用带版本号的软件包时需要设置 ``RUST_LIB_SRC``，例如::
+
+	RUST_LIB_SRC=/usr/src/rustc-$(rustc-1.80 --version | cut -d' ' -f2)/library
+
+为方便起见，可以将 ``RUST_LIB_SRC`` 导出到全局环境中。
+
+此外， ``bindgen-0.65`` 在较新的版本（24.04 LTS 和 24.10）中可用，但在更早的版
+本（20.04 LTS 和 22.04 LTS）中可能不可用，因此可能需要手动构建 ``bindgen``
+（请参见下文）。
+
 
 构建依赖
 --------
 
 本节描述了如何获取构建所需的工具。
 
-其中一些依赖也许可以从Linux发行版中获得，包名可能是 ``rustc`` , ``rust-src`` ,
-``rust-bindgen`` 等。然而，在写这篇文章的时候，它们很可能还不够新，除非发行版跟踪最
-新的版本。
-
 为了方便检查是否满足要求，可以使用以下目标::
 
 	make LLVM=1 rustavailable
@@ -34,15 +156,14 @@
 rustc
 *****
 
-需要一个特定版本的Rust编译器。较新的版本可能会也可能不会工作，因为就目前而言，内核依赖
-于一些不稳定的Rust特性。
+需要一个较新版本的Rust编译器。
 
 如果使用的是 ``rustup`` ，请进入内核编译目录（或者用 ``--path=<build-dir>`` 参数
-来 ``设置`` sub-command)并运行::
+来 ``设置`` sub-command)，例如运行::
 
-	rustup override set $(scripts/min-tool-version.sh rustc)
+	rustup override set stable
 
-+这将配置你的工作目录使用正确版本的 ``rustc``，而不影响你的默认工具链。
+这将配置你的工作目录使用给定版本的 ``rustc``，而不影响你的默认工具链。
 
 请注意覆盖应用当前的工作目录（和它的子目录）。
 
@@ -54,7 +175,7 @@ rustc
 Rust标准库源代码
 ****************
 
-Rust标准库的源代码是必需的，因为构建系统会交叉编译 ``core`` 和 ``alloc`` 。
+Rust标准库的源代码是必需的，因为构建系统会交叉编译 ``core`` 。
 
 如果正在使用 ``rustup`` ，请运行::
 
@@ -64,10 +185,10 @@ Rust标准库的源代码是必需的，因为构建系统会交叉编译 ``core
 
 否则，如果使用独立的安装程序，可以将Rust源码树下载到安装工具链的文件夹中::
 
-       curl -L "https://static.rust-lang.org/dist/rust-src-$(scripts/min-tool-version.sh rustc).tar.gz" |
-               tar -xzf - -C "$(rustc --print sysroot)/lib" \
-               "rust-src-$(scripts/min-tool-version.sh rustc)/rust-src/lib/" \
-               --strip-components=3
+	curl -L "https://static.rust-lang.org/dist/rust-src-$(rustc --version | cut -d' ' -f2).tar.gz" |
+		tar -xzf - -C "$(rustc --print sysroot)/lib" \
+		"rust-src-$(rustc --version | cut -d' ' -f2)/rust-src/lib/" \
+		--strip-components=3
 
 在这种情况下，以后升级Rust编译器版本需要手动更新这个源代码树（这可以通过移除
 ``$(rustc --print sysroot)/lib/rustlib/src/rust`` ，然后重新执行上
@@ -97,24 +218,21 @@ Linux发行版中可能会有合适的包，所以最好先检查一下。
 bindgen
 *******
 
-内核的C端绑定是在构建时使用 ``bindgen`` 工具生成的。这需要特定的版本。
-
-通过以下方式安装它（注意，这将从源码下载并构建该工具）::
-
-	cargo install --locked --version $(scripts/min-tool-version.sh bindgen) bindgen-cli
+内核的C端绑定是在构建时使用 ``bindgen`` 工具生成的。
 
-``bindgen`` 需要找到合适的 ``libclang`` 才能工作。如果没有找到（或者找到的
-``libclang`` 与应该使用的 ``libclang`` 不同），则可以使用 ``clang-sys``
-理解的环境变量（Rust绑定创建的 ``bindgen`` 用来访问 ``libclang``）:
+例如，通过以下方式安装它（注意，这将从源码下载并构建该工具）::
 
+	cargo install --locked bindgen-cli
 
-* ``LLVM_CONFIG_PATH`` 可以指向一个 ``llvm-config`` 可执行文件。
+``bindgen`` 使用 ``clang-sys`` crate 来查找合适的 ``libclang`` （可以静态链
+接、动态链接或在运行时加载）。默认情况下，上面的 ``cargo`` 命令会生成一个在运行时
+加载 ``libclang`` 的 ``bindgen`` 二进制文件。如果没有找到（或者应该使用与找到的
+不同的 ``libclang``），可以调整该过程，例如使用 ``LIBCLANG_PATH`` 环境变量。详
+情请参阅 ``clang-sys`` 的文档：
 
-* 或者 ``LIBCLANG_PATH`` 可以指向 ``libclang`` 共享库或包含它的目录。
+	https://github.com/KyleMayes/clang-sys#linking
 
-* 或者 ``CLANG_PATH`` 可以指向 ``clang`` 可执行文件。
-
-详情请参阅 ``clang-sys`` 的文档:
+	https://github.com/KyleMayes/clang-sys#environment-variables
 
 
 开发依赖
@@ -151,18 +269,6 @@ clippy
 独立的安装程序也带有 ``clippy`` 。
 
 
-cargo
-*****
-
-``cargo`` 是Rust的本地构建系统。目前需要它来运行测试，因为它被用来构建一个自定义的标准
-库，其中包含了内核中自定义 ``alloc`` 所提供的设施。测试可以使用 ``rusttest`` Make 目标
-来运行。
-
-如果使用的是 ``rustup`` ，所有的配置文件都已经安装了该工具，因此不需要再做什么。
-
-独立的安装程序也带有 ``cargo`` 。
-
-
 rustdoc
 *******
 
@@ -223,7 +329,7 @@ Rust支持（CONFIG_RUST）需要在 ``General setup`` 菜单中启用。在其�
 如果使用的是GDB/Binutils，而Rust符号没有被demangled，原因是工具链还不支持Rust的新v0
 mangling方案。有几个办法可以解决：
 
-  - 安装一个较新的版本（GDB >= 10.2, Binutils >= 2.36）。
+- 安装一个较新的版本（GDB >= 10.2, Binutils >= 2.36）。
 
-  - 一些版本的GDB（例如vanilla GDB 10.1）能够使用嵌入在调试信息(``CONFIG_DEBUG_INFO``)
-    中的pre-demangled的名字。
+- 一些版本的GDB（例如vanilla GDB 10.1）能够使用嵌入在调试信息(``CONFIG_DEBUG_INFO``)
+  中的pre-demangled的名字。