RFC-0089：核心领域变体

摘要

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

设计初衷

如今，组件框架的 CFv2 中的核心领域是组件，它包含 v2 系统中的大多数其他打包组件。此组件只有一个版本，因此每个产品都具有相同的静态 v2 组件集以及这些组件的功能路由。这会导致出现既没有用途也不会运行的组件，以及向组件提供过于广泛的功能，因为核心领域必须构建为所有产品配置的并集。

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

一些组件已从 v1 sys 领域迁移到 v2 core 领域，预计 2021 年第二季度的迁移速度将加快。

鉴于上述情况，我们需要能够根据运行 CFv2 领域的产品来定制 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 中，而 ZBI 已经是产品专用的。

所有商品上都存在的组件将位于通用基础中，并且仅为某些商品上未包含的组件创建分片。如果添加了一个新产品，该产品希望排除某些组件（直到那时，这些组件都包含在所有先前产品中），则会将此组件从通用基础重构到分片中。

会话和产品专用路由

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

一种是让会话管理器路由所有产品的所有功能的超集。在这种情况下，不可用功能的路由将在核心领域失败。

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

从会话的角度来看，这两种选择看起来是相同的。

实现

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

如需查看不完整但功能正常的实现，以演示此方法的工作原理 ，请点击此处。

性能

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

安全注意事项

此提案会导致不应在产品上运行的组件不存在于该产品上。它还将使我们能够为组件提供其运行的产品所需的功能，而不是始终为组件提供它们可能需要在不同产品之间使用的功能的并集。

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

隐私注意事项

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

测试

产品所有者需要确保其产品中包含所需的组件，并且测试涵盖这些组件的存在。 虽然由于产品专用软件包集，情况已经如此，但此处提出的核心领域变体增加了一个额外的点，产品定义可能会意外遗漏一个重要组件。这导致产品所有者需要承担略高的负担，以确保测试配置与产品配置保持一致。

文档

产品所有者可设置的确切 GN 实参将在 GN 中定义它们的位置进行记录。此外，我们还将维护 Markdown 文档，其中描述了每个清单分片及其对产品核心领域的影响。