RFC-0089：核心领域变体

摘要

在产品定义中设置的 GN 变量用于在该产品的组件框架中生成自定义核心领域。

设计初衷

目前，组件框架 CFv2 中的核心领域是 v2 系统中包含大多数其他打包组件的组件。此组件只有一个版本，因此每个产品都具有一组相同的静态 v2 组件和这些组件的功能路由。这会导致存在没有用途且永远不会运行的组件，并且向组件提供过于宽泛的功能，因为核心领域必须构建为所有产品配置的联合。

此外，v1 组件框架支持在构建时有条件地为特定产品将功能和组件添加到 sys 领域。随着组件从 v1 迁移到 v2，已经依赖于此的组件将进一步加剧当前模型的问题，因为核心领域需要有一个定义，能够同时满足每个产品的要求。

部分组件已从 v1 sys 领域迁移到 v2 core 领域，预计 2021 年第 2 季度迁移速度将加快。

因此，我们需要能够根据运行 CFv2 领域的产品来量身定制 CFv2 领域的中央结构的确切内容。

范围

此设计旨在在更高级且面向未来的解决方案准备就绪之前，在极短的时间内实现其他组件迁移。此设计不适用于非树型产品，也不适合作为长期解决方案。PDK 旨在实现树外产品组装，将以更全面的方式解决本文中提到的相同问题。

设计

核心领域清单的内容将拆分为一个通用基础和 CML 分片，其中包含产品可选择包含的组件及其 capability 路线。例如，目前 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 中，而 ZBI 已是产品专用。

所有产品中都存在的所有组件都将位于通用基准中，系统只会为某些产品中不包含的组件创建分片。如果添加了新产品，并且希望排除之前所有产品中都包含的某些组件，则系统会将此组件从通用基础重构到分片中。

会话和产品专用路由

如果核心领域中的产品专用功能需要通过会话管理器路由到会话，则有两种可能的选项。

一种方法是让会话管理器将所有产品的所有功能的超集进行路由。在这种情况下，核心网域中无法使用功能的路由会失败。

第二种方法是使用基于分片的方法来构建产品专用会话管理器清单，与此提案中针对核心领域所述的方法相同。在这种情况下，会话管理器领域将无法为不可用功能进行路由。这种方法需要让会话管理器和核心分片列表保持同步，并且会增加构建复杂性和维护成本。

从会话的角度来看，这两种方法看起来是完全相同的。

实现

此更改可以在单个 Gerrit CL 中进行。由于 GN 参数具有默认值，因此产品定义可以添加替换项，以便稍后启用所需的功能。

如需查看一个尚未完成但可正常运行的实现，以便了解此方法的运作方式，请点击此处。

性能

由于此提案中的所有工作都在构建时进行，因此不会对运行时性能产生任何影响。

安全注意事项

此提案会导致在不存在相应组件的设备上运行不应在该设备上运行的组件。这还将使我们能够为组件提供其所运行产品所需的功能，而不是总是向组件提供它们可能需要的跨产品功能组合。

此提案将导致 CFv2 领域结构有多个可能的变体，这会导致安全审核和工具（例如审核）需要能够处理新机制，并且产品之间的共享基础会减少。

隐私注意事项

此提案将导致组件仅存在于应在其上运行的产品中，并且永远不会获得过于广泛的功能，这两点都有可能提高系统的隐私保护保证。

测试

产品所有者需要确保其产品包含所需的组件，并且测试涵盖了这些组件的存在情况。虽然由于产品专用软件包集，这种情况已经存在，但这里提出的核心领域变体又增加了一个可能导致产品定义意外遗漏重要组件的方面。这会导致产品所有者承担更大的工作量，以确保测试配置与产品配置保持一致。

文档

产品所有者可以设置的确切 GN 参数将在 GN 中定义它们的位置记录下来。此外，我们还将维护 Markdown 文档，其中会说明每个清单分片及其对产品核心领域的影响。