translate completely

Lyrance · Lyrance · commit 3676ddca1c85 · 2023-04-06T23:48:57.000+08:00
diff --git a/docs/CantripRootserver.md b/docs/CantripRootserver.md
@@ -1,4 +1,4 @@
-
+<!--
 ## CantripOS capDL rootserver application
 
 The other main Rust piece of CantripOS is the rootserver application that is located in
@@ -34,3 +34,33 @@ when it starts up. If you want verbose logging enable `LOG_DEBUG` or `LOG_TRACE`
 in the Cargo.toml.
 
 ### [Next Section: Depending on CantripOS Rust crates](CrateDependencies.md)
+-->
+
+## CantripOS的capDL根服务器应用程序
+
+CantripOS的另一个主要Rust组件是位于*projects/capdl/cantrip-os-rootserver*中的根服务器应用程序。
+这取决于*cantrip-os-common*的*capdl*和*model*子模块。
+虽然可以使用CMake设置在CAmkES项目的easy-settings.cmake文件中选择cantrip-os-rootserver或基于C的capdl-loader-app；
+例如，`projects/cantrip/easy-settings.cmake`中有：
+
+```
+#set(CAPDL_LOADER_APP "capdl-loader-app" CACHE STRING "")
+set(CAPDL_LOADER_APP "cantrip-os-rootserver" CACHE STRING "")
+```
+
+但不建议使用capdl-loader-app，因为它缺少仅在cantrip-os-rootserver中才有的重要功能。
+
+cantrip-os-rootserver和capdl-loader-app之间最重要的区别是：
+
+- 支持在退出时回收根服务器的内存。
+- 支持CantripOS CAmkES特性（例如MemoryManager、RTReply caps）。
+- 减少内存消耗。
+
+否则，cantrip-os-rootserver应该提供相同的功能，
+尽管某些功能未经测试（例如CONFIG_CAPDL_LOADER_STATIC_ALLOC）和/或未经充分测试（例如CONFIG_CAPDL_LOADER_CC_REGISTERS）。
+
+请注意，许多cmake根服务器配置参数没有传递到Rust代码中。您可能需要在cantrip-os-rootserver和/或cantrip-os-model（cantrip-os-common）的Cargo.toml中调整功能。
+
+默认情况下，cantrip-os-rootserver在启动时会打印有关capDL规范的信息。如果您想启用详细日志记录，请在Cargo.toml中启用LOG_DEBUG或LOG_TRACE。
+
+### [下一章: 依赖CantripOS的Rust crates](CrateDependencies.md)
diff --git a/docs/CrateDependencies.md b/docs/CrateDependencies.md
@@ -1,12 +1,19 @@
-
+<!--
 ### Depending on CantripOS Rust crates
 
 To use CantripOS crates you can reference them from a local repository or
 directly from GitHub using git; e.g. in a Config.toml:
+-->
+### 依赖CantripOS的Rust crates
+
+要使用CantripOS crates，您可以从本地存储库或直接从GitHub使用git引用它们；例如，在Config.toml中：
+
 ```
 cantrip-os-common = { path = "../system/components/cantrip-os-common" }
 cantrip-os-common = { git = "https://github.com/AmbiML/sparrow-cantrip-full" }
 ```
+
+<!--
 NB: the git usage depends on cargo's support for searching for a crate
 named "cantrip-os-common" in the cantrip repo.
 
@@ -15,23 +22,35 @@ Note that many CantripOS crates need the seL4 kernel configuration
 cantrip-os-common/sel4-config crate that is used by a build.rs to import
 kernel configuration parameters as Cargo features. In a Cargo.toml create
 a features manifest with the kernel parameters you need e.g.
+-->
+
+注意：git的使用取决于cargo是否支持在cantrip仓库中搜索名为“cantrip-os-common”的crate。
+
+请注意，许多CantripOS crate需要seL4内核配置（例如，知道是否配置了MCS）。
+这由cantrip-os-common/sel4-config crate处理，
+该crate由build.rs使用以将内核配置参数导入Cargo功能。
+在Cargo.toml中，使用您需要的内核参数创建一个特性清单，例如：
 
 ```
 [features]
 default = []
 # Used by sel4-config to extract kernel config
 CONFIG_PRINTING = []
 ```
-
+<!--
 then specify build-dependencies:
+-->
+接着指定 build-dependencies:
 
 ```
 [build-dependencies]
 # build.rs depends on SEL4_OUT_DIR = "${ROOTDIR}/out/cantrip/kernel"
 sel4-config = { path = "../../cantrip/apps/system/components/cantrip-os-common/src/sel4-config" }
 ```
-
+<!--
 and use a build.rs that includes at least:
+-->
+并使用至少包含以下内容的 build.rs：
 
 ```
 extern crate sel4_config;
@@ -55,11 +74,18 @@ fn main() {
     }
 }
 ```
-
+<!--
 Note how build.rs expects an SEL4_OUT_DIR environment variable that has the path to
 the top of the kernel build area. The build-sparrow.sh script sets this for you but, for
 example, if you choose to run ninja directly you will need it set in your environment.
 
 Similar to SEL4_OUT_DIR the cantrip-os-common/src/sel4-sys crate that has the seL4 system
 call wrappers for Rust programs requires an SEL4_DIR envronment variable that has the
 path to the top of the kernel sources. This also is set by build-sparrow.sh.
+-->
+
+请注意，build.rs 需要一个名为 SEL4_OUT_DIR 的环境变量，该变量包含内核构建区域的路径。
+build-sparrow.sh 脚本会为您设置它，但是如果您选择直接运行 ninja，您需要在环境中设置它。
+
+类似于 SEL4_OUT_DIR，cantrip-os-common/src/sel4-sys crate 具有用于 Rust 程序的 seL4 系统调用包装器，
+需要一个名为 SEL4_DIR 的环境变量，该变量包含内核源代码的路径。build-sparrow.sh 也会设置此变量。
diff --git a/docs/MemoryFootprint.md b/docs/MemoryFootprint.md
@@ -1,4 +1,4 @@
-
+<!--
 ## Memory footprint
 
 A release build for Sparrow fits in ~1.5MiB of memory and boots to
@@ -22,3 +22,17 @@ communication between applications and the *SDKRuntime* is a prototype
 of a native Rust implementation that demonstrates where we're headed.
 
 ### [Next Section: CantripOS capDL rootserver application](CantripRootserver.md)
+-->
+
+## 内存占用
+
+Sparrow的发布构建适合占用约1.5MiB的内存，并在4MiB的内存中引导到运行系统。
+引导机制（使用capDL和rootserver）实际上需要~2倍的空闲内存占用才能达到运行状态（因为rootserver实例化系统的开销）。
+kmem.sh脚本可用于分析内存使用情况。系统服务应该轻松适应1MiB的内存空间，但由于CAmkES开销（例如，每个线程的成本），它们显著膨胀。
+我们使用kmem和 [bloaty 工具](https://github.com/google/bloaty) 来评估内存使用情况。
+
+为了将内存使用减少到<1MiB，我们正在将CAmkES的运行时替换为本机Rust框架。
+这也应通过扩展借用检查器的范围并使优化器能够跨越CAmkES C <> Rust运行时边界工作来提高性能和鲁棒性，这是CAmkES基于C的实现的副产品。
+用于应用程序和*SDKRuntime*之间通信的RPC机制是原生Rust实现的原型，展示了我们的发展方向。
+
+### [下一章: CantripOS的capDL根服务器应用程序](CantripRootserver.md)
diff --git a/docs/PlatformDependencies.md b/docs/PlatformDependencies.md
@@ -1,3 +1,4 @@
+<!--
 
 ## Target platform dependencies
 
@@ -8,6 +9,14 @@ top-level feature through the cargo command line to effect the cargo dependency
 For example, in `DebugConsole/cantrip-debug-console/Cargo.toml` configuration of the
 platform-specific UART support for the command line interpreter is done with:
 
+-->
+
+## 目标平台依赖
+
+sel4-config机制用于导入seL4内核配置，只有在***编译***Rust代码时才会动态设置功能。
+目标平台依赖项（如设备驱动程序）通过将顶层功能通过cargo命令行传递来处理cargo依赖项进程。
+例如，在`DebugConsole/cantrip-debug-console/Cargo.toml`中，针对命令行解释器的平台特定UART支持的配置是这样完成的：
+
 ```
 [features]
 default = [
@@ -18,9 +27,12 @@ autostart_support = ["default-uart-client"]
 CONFIG_PLAT_BCM2837 = []
 CONFIG_PLAT_SPARROW = ["cantrip-uart-client"]
 ```
-
+<!--
 The CONFIG_PLAT_* features mirror the seL4 kernel config parameters and can be
 used to select an optional dependency:
+-->
+
+CONFIG_PLAT_*功能与seL4内核配置参数相对应，可用于选择可选依赖项：
 
 ```
 [dependencies]
@@ -29,13 +41,15 @@ default-uart-client = { path = "../default-uart-client", optional = true }
 ...
 cantrip-uart-client = { path = "../cantrip-uart-client", optional = true }
 ```
-
+<!--
 The platform feature is injected into the build process in *build/cantrip.mk* with:
+-->
+平台功能通过*build/cantrip.mk*中的以下内容注入到构建过程中：
 
 ```
 cmake ... -DRUST_GLOBAL_FEATURES=${CONFIG_PLATFORM} ...
 ```
-
+<!--
 In addition to including platform-dependencies in the build process they
 may also need to be included in the CAmkES assembly; this done by having
 the `system.camkes` file platform-specific.
@@ -49,3 +63,13 @@ returns SDKError::NoPlatformSupport.
 This is done so applications have a stable ABI.
 
 ### [Next Section: Testing](Testing.md)
+-->
+
+除了在构建过程中包含平台依赖项，它们还可能需要包含在CAmkES组装中；这通过使`system.camkes`文件特定于平台来完成。
+例如，`platforms/sparrow/system.camkes`连接了UARTDriver、MlCoordinator、MailboxDriver和TimerService组件。
+
+一些系统服务（如SDKRuntime）已准备好条件包含依赖服务；
+例如，如果不存在MlCoordinator服务，则所有与模型相关的SDK调用都会返回SDKError::NoPlatformSupport。
+这样做是为了让应用程序拥有稳定的ABI。
+
+### [下一章: 测试支持](Testing.md)
