RFC-0182：废弃了 config-data

摘要

此 RFC 建议：

• 将 [config-data] 机制声明为已弃用。
• 为现有用例建立许可名单。
• 随着时间的推移，逐渐取代现有的 config-data 版本 解决方案。
• 最终从 Fuchsia 中移除了对 config-data 的支持。

设计初衷

此 RFC 的近期目标是就创建 用于现有 config-data 用量的许可名单，以及“不增加” 许可名单。与这一直接目标无关的额外信息是 以及应各相关方要求提供的额外背景信息。

[config-data] 是一种配置文件机制，用于修改 提供特定文件 访问该组件的命名空间。

config-data 用于创建“远处的恐怖动作”使用未强制执行的合同 或惯例。这有问题 因为软件包名称不实用 与 Fuchsia SDK Surface 一起进行版本控制，并随着时间推移而不断演变， 就像声明支持窗口并允许软过渡一样。体验 已经表明，基于软件包名称的合同会导致运行时变得脆弱 且维护成本很高。

此外，由于 config-data 会将开发者软件包中的内容与 包含配置文件的基础软件包中的内容，那么这会创建 令人困惑的开发者体验，开发者不得不推送新版 但在运行时看到旧的配置文件。开发者经常会问 为什么他们推送的是更新版本的应用包 在 /config/data 下看到了过时的文件，而没有意识到这些文件 来自不同的软件包要向开发者解释此行为， 例如“基础软件包” 采用了抽象化功能，因此不可取。更不必说 经常会因为工作流程不一致而降低工作效率。

config-data对于解决演员在 需要影响 将超出其直接控制范围使用 config-data， 可用于编写代码 从而调节源自别处的组件的行为。

在某些情况下，组件和配置具有相同的来源，但用户 仍然倾向于使用 config-data 作为集成点。这样，用户就可以 来生成一个软件包并旁加载不同的配置值， 组件。在生成大量映像时 多个软件包的性能较高，例如，如果每个软件包变种都需要 单独上传到后续集成点。

如今，config-data 存在多个替代选项。其中包括 根据配置目录 目录功能 结构化配置 通过协议功能提供配置，以及 打包配置文件 。

尽管弃用现有的 config-data 以及该功能本身，我们应该让新用法转向现代化 并敦促现有使用者迁移到现代替代方案。

在这种情况下，最佳做法是为 config_data() GN 规则，并使用现有用法对其进行初始化。许可名单 预计随着时间的推移会趋于零， 如果不确定现代替代方案是否适用，就会被列入许可名单。时间 允许新的用法，更改允许，应说明理由 以减少代码审核流失。

利益相关方

• 组件框架团队：创建了 config-data 及其当前的替代方案。
• 构建团队：config-data 构建时逻辑的维护人员。
• 软件组装团队：config-data 组装时逻辑的维护人员。
• config-data的当前用户（分布在多个团队中）。

教员：

• hjfreyer@google.com

审核者：

• aaronwood@google.com
• adamperry@google.com
• awolter@google.com
• ddorwin@google.com
• fmil@google.com
• geb@google.com
• jsankey@google.com
• kpozin@google.com
• wez@google.com
• yaar@google.com
• ypomortsev@google.com

社交化：

组件框架和软件汇编团队已审核了此 RFC 的草稿 技术主管

背景

config-data 的运作方式

在旧版 appmgr（也称为 CFv1）中，config-data 是通过匹配 已启动组件的软件包名称与 config-data 中的子目录相对应 基础软件包。如果找到了匹配项，就会提供相应的子目录 已启动组件的命名空间中的 /config/data 下。

您可以通过指定要提供的文件、路径来定义 config-data 它们在组件的传入命名空间中可用（通过 惯例，在 /config/data 下），以及组件的一个或多个软件包名称 这些文件应在这些路径中提供

例如，组件可能会请求使用配置文件，如下所示：

{
    use: [
        {
            directory: "config-data",
            rights: [ "r*" ],
            path: "/config/data",
        },
    ],
}

这表示该组件要求嵌入器提供 名为“config-data”的目录功能 框架位于 /config/data，以允许依赖于 /config/data 的现有代码 使其无需修改即可运行

父组件或大区可能包含以下声明：

{
    children: [
        {
            name: "font-provider",
            url: "fuchsia-pkg://fuchsia.com/fonts#meta/font-provider.cm",
        },
    ],
    offer: [
        {
            directory: "config-data",
            from: "parent",
            to: [ "#font-provider" ],
            subdir: "fonts",
        },
    ],
}

此方法接受包含多个子目录的 config-data（位于 父级，并路由包含配置数据的 example 子目录 传递给该组件

config-data 的内容可能来自 build 定义，如下所示：

import("//build/config.gni")

config_data("example_config_data") {
  for_pkg = "example"
  sources = [
    "file1.dat",
    "file2.dat",
    ...
  ]
  outputs = [ "{{source_file_part}}" ]
}

构建系统会收集上述目标和其他类似目标， 名为 config-data 的软件包的内容。接下来是专门构建的路由规则 以路由方式发送 config-data 软件包的所有内容，并将其整理为 （如上面显示的 for_pkg 参数所示）的子目录中， 和其他位置，它们通过进一步配置为不同的 组件使用它们

config-data目前的使用情况

config-data 的用例有很多。以下是一些说明示例：

• ICU 数据和 tzdata：ICU 库的数据，特别是时区数据 ("tzdata")，在运行时以 config-data 的形式提供。定义单个来源 Fuchsia 平台来源中这些数据文件的真实性信息， 从各种来源（例如 Chromium、Flutter、 Google 内部代码库等）来确保 文件。 这样可以实现一致性（例如，所有组件都同意单个 tzdata） 无论其来源如何）和效率（所有组件共享同一个 ICU） blob，而不考虑它们的构建时间或位置）。
• buildinfo 和 hwinfo 组成部分的值按以下方式提供： config-data。这些组件基于平台源代码构建而成，但可能 需要按产品进行配置目前config-data 配置机制。
• 在平台来源中定义的“设置”界面组件可配置为 在提供不同硬件的不同设备上具有不同的行为方式 。例如，SetUI 在 Astro 和 Sherlock 上的行为有所不同 通过目前受 config-data 约束的方式提供。
• 可以将平台字体提供程序组件配置为 特定产品的字体。字体文件以及描述其 属性以添加到树外产品中的 config-data 形式提供 程序集

设计和实现

将在构建时回归停止，以防止新使用 未经明确批准，config-data。现有使用情况的许可名单将 并且对此许可名单所做的更改将受 OWNERS 文件约束。 组件框架团队会指定负责人来代表 fuchsia.git 以及使用 config-data 表示其用途的花瓣。 代表将负责管理各自的许可名单 条目，例如有助于重构或定向烧毁。

实现回归停止并不重要。常见且可能 实施策略是更改 config-data GN 模板，以添加一个 具有指定可见性列表的目标的依赖项。值得注意的是，这仅涵盖 树内使用，但限制在树外使用 config-data 组装产品也很重要我们可以开发适当的机制 与 PDK 团队进行协调。

config-data 的替代选项不在本文的讨论范围之内。 RFC。提及这些替代方案时，请参阅上方链接的文档。

建立为组件提供配置的最佳做法，或 从 config-data 之外播种迁移指南，这些内容不在本文的讨论范围之内 RFC。我们仍在努力制作此类文档， 单独发布。

性能

config-data 软件包的一个具体而有趣的方面是，所有文件 会打包在路径 meta/ 下。也就是说，这些文件会在 meta.far 文件。存储在底层 blobfs 文件系统中时，文件大小 向上舍入为块大小，通常为 8KiB。归档 一起，就可以消除向上舍入带来的额外开销。这个 因为配置文件通常很多且很小 实际上，总开销可能会大于 文件。

在使用替代解决方案时，如果存储空间很重要， 应采用相同的技术或等效方法，以确保存储性能 效率。

工效学设计

config-data 的替代产品更符合人体工程学，最重要的是， 不依赖于基于软件包名称的脆弱合同和“在 距离”。

向后兼容性

从 config-data 中迁出数据有时需要以软性方式进行 过渡效果。在过渡期间，使用 配置数据必须能够接受 config-data 和 所选替代值。

安全注意事项

此 RFC 不会引入任何新的配置机制， 我们用来替代 config-data 的替代文本已存在于系统中 并经过了自己的安全审核。组件作者应 在设计或更改 安全相关功能

隐私注意事项

此 RFC 不会引入任何新的配置机制， 我们将用作 config-data 的替代方法已存在于系统中 并且经过了自己的隐私权审核。组件作者应参阅 在针对隐私敏感性设计或更改配置时注重隐私保护 功能。

测试

向 config-data 提供的替代方案都已遵循成熟的最佳做法 进行测试。如需了解特定功能进行测试，请参阅相关文档 信息。例如，请参阅有关测试结构化 配置（使用 Realm） Builder。替换结构化配置值 简单易行：

realm_builder.SetConfigValue(child_name, key, value_for_test);

当我们需要以文件形式将配置数据提供给被测组件时， 可以将文件与测试打包在一起 从测试组件（在测试领域根目录下）路由到 作为数据目录例如：

{
    ....
    capabilities: [
        {
            directory: "test_config",
            rights: [ "r*" ],
            path: "/test_config",
        },
    ],
    children: [
        {
            name: "component_under_test",
            ...
        },
    ],
    offer: [
        {
            directory: "test_config",
            from: "self",
            as: "config",
        },
    ],
}

文档

为支持从 config-data 改用此方案，我们将提供迁移指南 。迁移指南将帮助开发者选择最佳替代方案 了解应用场景，并请他们参阅其他文档。

关于人员配置和流失的注意事项

接受此 RFC 不会对 config-data，以迁移到现代替代方案。如果强制性迁移要求 应安排一个核心迁移团队来执行 大部分工作。作者提议， CFv2 迁移完成后，我们还是应该尽快 回归停止。

在安排专门的人员完成迁移之前， 许可名单（例如支持重构）应接受审核并获得批准 。

缺点、替代方案和未知问题

结构化配置是一种不断发展的新机制。例如， 表示配置所需的功能，例如 类型尚未实现。

功能路由目前不受平台版本控制的约束。它是 建立对 在 ABI 修订版本上调制功能路由，但这种机制 功能。