| RFC-0089：核心领域变体 | |
|---|---|
| 状态 | 已接受 |
| 领域 |
|
| 说明 | 根据产品配置生成自定义核心组件领域。 |
| 问题 | |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2021-03-04 |
| 审核日期（年-月-日） | 2021-04-19 |
总结
产品定义中设置的 GN 变量用于为该产品的组件框架中生成自定义核心领域。
设计初衷
如今，组件框架的 CFv2 的核心领域是包含 v2 系统中大多数其他打包组件的组件。此组件只有一个版本，因此每个产品都具有一组相同的静态 v2 组件以及这些组件的功能路由。这会导致现有的两个组件都没有用途且永远不会运行，并且为组件提供的功能过于宽泛，因为必须构建核心领域，使其成为所有产品配置的并集。
此外，在构建时，v1 组件框架支持针对特定产品有条件地向 sys 领域添加功能和组件。随着组件从 v1 迁移到 v2，当前模型需要核心领域具有同时满足每个产品要求的单一定义，已经依赖于此 API 的组件会进一步加剧问题。
某些组件已从 v1 sys 领域迁移到 v2 core 领域，预计在 2021 年第二季度会加快迁移速度。
由于上述原因，我们需要能够定制 CFv2 领域的中心结构的确切内容，以适应其运行所在的产品。
范围
此设计的目标是在极短的时间内完成其他组件迁移，直到推出更先进、面向未来的解决方案。此设计并不适合使用树状产品，也不是合适的长期解决方案。PDK 工作旨在实现树外产品组装，它将更全面地解决此处讨论的相同问题。
设计
核心领域清单的内容将拆分为一个通用的基础分片和 CML 分片，其中包含产品可选择性包含的组件及其功能路由。例如，CFv2 中当前存在的 /core/temperature-logger 组件仅适用于 astro 产品。系统会将以下分片添加到单独的文件中，而不是在基本核心清单中包含与 temperature-logger 相关的内容：
{
children: [
{
name: "temperature-logger",
url: "fuchsia-pkg://fuchsia.com/temperature-logger#meta/temperature-logger.cm",
},
],
offer: [
{
protocol: "fuchsia.thermal.test.TemperatureLogger",
from: "#temperature-logger",
to: [ "#appmgr" ],
},
{
protocol: [ "fuchsia.logger.LogSink" ],
from: "parent",
to: [ "#temperature-logger" ],
},
{
directory: "dev-class",
as: "dev-temperature",
from: "parent",
to: [ "#temperature-logger" ],
subdir: "temperature",
},
{
directory: "dev-class",
as: "dev-thermal",
from: "parent",
to: [ "#temperature-logger" ],
subdir: "thermal",
},
{
directory: "config-data",
from: "parent",
to: [ "#temperature-logger" ],
subdir: "temperature-logger",
},
{
protocol: [
"fuchsia.device.Controller",
"fuchsia.hardware.temperature.Device",
],
from: "parent",
to: [ "#temperature-logger" ],
},
{
protocol: "fuchsia.tracing.provider.Registry",
from: "#appmgr",
to: [ "#temperature-logger" ],
dependency: "weak_for_migration",
},
],
}
此分片将使用 GN 模板为其创建目标，其中包含分片的路径。对于我们的 temperature-logger 示例，目标应如下所示：
core_shard("temperature_logger_shard") {
shard = "//meta/temperature-logger.shard.cml"
}
每个产品的 .gni 文件（例如 //products/workstation.gni）都能够指定它们希望包含在产品核心领域中的分片的 GN 目标。
core_realm_shards += [
"//src/sys/core:temperature_logger_shard"
]
在产品组装时，这些目标随后使用 GN 的 generated_file() 目标收集，并用作 CMC 合并操作的输入，其中要包含在产品中的分片将与核心领域的基础分片合并。在当前示例中，temperature-logger 的分片是唯一与核心基本分片合并的分片。
这个生成的核心领域将包含在相应名称源自产品的软件包中。例如，工作站产品的核心清单将以 fuchsia-pkg://fuchsia.com/core-workstation#meta/core.cm 打包。
这是因为组件是使用网址进行标识的。这些标识符遵循 Webarch 识别原则，即“全局命名会导致全局网络效应”。因此，无论网址所处的上下文如何，给定的组成部分网址都会引用同一逻辑实体。这种方法意味着，对于 Fuchsia，有一个软件场景涵盖所有产品和板级配置。如果让每个产品都能使用相同的网址来引用核心领域，而该网址背后的内容因产品而异，则不符合此原则。
由于核心领域的网址现在因产品而异，因此系统会在构建时修改根组件清单，以包含当前产品的核心领域对应的正确网址。特定于产品的根领域不需要以不同的方式（如核心领域）进行打包，因为它直接包含在特定于产品的 ZBI 中。
存在于所有产品中的所有组件都将位于同一基础上，并且仅会为未包含在某些产品中的组件创建分片。如果添加的新产品希望排除在该日期之前包含在所有先前产品中的某些组件，则此组件将从通用基础重构并重构为分片。
会话和特定于产品的路由
如果要通过会话管理器将核心领域中产品特定的功能路由到会话，有两种可能的方案。
一种方式是让会话管理器路由所有产品中所有功能的超集。在这种情况下，针对不可用功能的路由在核心领域会失败。
第二种方法是使用基于分片的方法，同时构建产品专用的会话管理器清单，这与此方案对核心领域这一过程的概述。在这种情况下，针对不可用功能的路由将在会话管理器领域失败。此方法将要求会话管理器和核心分片列表保持同步，并增加额外的构建复杂性和维护成本。
从会话的角度来看，这两个选项看起来是相同的。
实现
可以在单个 Gerrit CL 中进行此更改。由于 GN 参数具有默认值，因此产品定义可以添加替换项，以便稍后启用它们需要的功能。
如需查看完整但可正常运行的实现，演示了此方法的工作原理，请点击此处。
性能
由于此方案中的所有工作都在构建时进行，因此不会对运行时性能产生任何影响。
安全注意事项
此方案会导致组件不应该在该产品中不存在的产品上运行。此外，它还使我们能够为组件提供其运行所在产品所需的功能，而不是始终为组件提供其在不同产品之间可能需要的功能集合。
此方案可能会导致 CFv2 领域结构出现多种可能的变体，从而导致安全审核和工具（如审查）需要能够处理新的机制，同时产品之间的共享基础更少。
隐私注意事项
这种方案会导致组件仅存在于应运行它们的产品上，并且永远不会获得过于广泛的功能，这两种情况都有可能改善系统的隐私保护保证。
测试
产品所有者需要确保他们的产品中包含所需的组件，并在测试中涵盖这些组件的存在。尽管因特定于产品的软件包集而已实现这一点，但此处提出的核心领域变体会额外增加一个点，此时产品定义可能会意外地遗漏一个重要组件。这会使产品所有者在确保测试配置与产品配置保持一致方面的负担稍高一些。
文档
可供产品所有者设置的确切 GN 参数记录在 GN 中为其定义的位置。此外，我们还将维护 Markdown 文档，其中说明每个清单分片及其对产品核心领域的影响。