| RFC-0089：核心领域变体 | |
|---|---|
| 状态 | 已接受 |
| 领域 |
|
| 说明 | 按产品配置生成自定义核心组件领域。 |
| 问题 | |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2021-03-04 |
| 审核日期（年-月-日） | 2021-04-19 |
摘要
产品定义中设置的 GN 变量用于生成自定义核心领域 。
设计初衷
如今，组件框架 CFv2 中的核心领域是 包含 v2 系统中的大部分其他打包组件。只有一个版本 这会使每个产品都有相同的一组静态 v2 组件以及这些组件的功能路由。这会导致 无目的、永远不会运行的现有组件；过于宽泛 因为核心领域必须构建为 是所有产品配置的并集。
此外，v1 组件框架在构建时有条件地支持
向特定产品的 sys 领域添加功能和组件。如
组件已从 v1 迁移到 v2，
将进一步加剧当前模型需要核心
在领域拥有满足所有产品要求的单一定义
。
一些组件已从 v1 sys 领域迁移到 v2
core 个大区，且迁移速度预计会在第二天加快
。
出于上述原因，我们需要能够定制 CFv2 领域的中央结构，以适应其运行的产品。
范围
此设计的目标是在非常短的时间内完成更多组件迁移。 直到一个更高级、面向未来的解决方案准备就绪。此设计并非 旨在适用于非树类产品， 合适的长期解决方案。PDK 工作，旨在实现非树 将更全面地解决这里解决的同样问题 。
设计
核心领域清单的内容将拆分为通用基础，
CML 分片包含的组件及其功能路由
（可选）。例如，/core/temperature-logger
目前，CFv2 中的组件只能在 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 文档 持续介绍每个清单分片及其对 产品的核心领域