组件配置

在 Fuchsia 中,这称为“组件配置”。本页介绍了组件配置,并讨论了需要配置的不同情形的一些特征。

如需详细了解 Fuchsia 为组件配置提供的不同机制,以及用于解决各个问题的机制,请参阅组件配置机制

什么是组件配置?

“组件配置数据”是提供给组件实例的数据,该实例可用于了解和适应其启动环境(例如产品主板build 类型omaha 渠道、监管区域或集成测试领域)。“组件配置”是定义、传送和使用这些数据的过程。配置组件的功能非常有用,因为它允许同一组件用于不同的上下文 - 例如,相同的组件可以用于不同的产品或不同的硬件平台。如果没有组件配置,开发者需要创建多个组件,例如“foo_for_product_a”“foo_for_product_b”和“foo_for_testing”。

组件使用各种不同的输入。其中大多数输入都可能会改变组件的行为,但只有部分输入应被视为“组件配置数据”,而不是更宽泛的“数据”,例如系统的某些状态或某些用户输入。组件配置数据与其他形式数据之间的界限可能模糊不清,但区别很重要,因为专为组件配置数据设计的机制在应用于其他情况时通常无法正常运行。例外情况不存在,但配置值如下:

  • 在组件实例的生命周期内通常是常量
  • 在一些设备上通常保持不变
  • 通常由开发者、维护人员或管理员设置,而不是由最终用户设置。

以下是典型的组件配置示例:

  • 功能标志 - 使用布尔值配置启用或停用组件的某些功能。对于在出现问题时可能需要快速停用的新功能,这通常很有用。例如,我们在 2022 年使用一个功能标志安全地支持使用 Pinweaver 加密帐号数据分区。
  • 开发板调优 - 修改组件的行为,使其适合运行该组件的开发板。例如,提供 CPU 时钟的错误中位数和错误边界。
  • 产品调整 - 修改组件的行为以适应运行该组件的产品。例如,指定应启动哪个会话组件 - 会话管理器。
  • 测试控件 - 指定在测试中使用某个组件时的不同行为。 例如,在集成测试中使用某个组件时,设置更快的重试超时,以减少运行测试所需的时间。
  • 调试控件 - 启用或停用其他组件诊断,以帮助进行调试。例如,在 eng build 而非 user build 中启用管理 FIDL 接口。

以下迹象表明数据实际上并不是组件配置数据

  • 数据由组件本身修改。会更改某些可配置状态(例如响应 FIDL 请求)的组件必须通过配置输入的变化来合理化这些更改。在这些情况下,通常必须定义两种相似但不同的状态:组件配置状态(说“default_foo”)和系统状态(说“foo”)。组件最初将 foo 设置为 default_foo,但两者随后可能会独立更改。组件拥有 foo 的状态,但配置系统拥有 default_foo 的状态。
  • 组件实例对其交互的每个组件使用不同的数据。如果服务器支持来自不同客户端的连接,并允许每个客户端定制交互,则配置为“连接配置”而不是“组件配置”。此处讨论的机制无意解决这一情况,但如上所述,可能仍存在一个组件配置状态来定义用于新连接的“默认”状态。
  • 在运行时数据频繁且快速变化。组件配置数据反映了启动组件实例的环境。大多数情况下,这些环境是不变的,但在某些情况下,环境或与环境关联的配置数据可能会在运行时发生变化。例如,用户可能会飞往其他监管区域,或者某个产品可能会启用新功能。但是,这些运行时更改的频率仍然远低于许多系统状态的更改,并且我们所讨论的机制在设计时考虑到了这种低更改率。

组件配置情况有哪些类型?

需要对组件进行配置的各种情况各不相同。本部分将逐步介绍在调查需要配置的情况时,您应考虑的一些关键问题。回答这些问题有助于您选择适当的配置机制。

谁负责设置数据?

  • 组件开发者。在这里,组件的开发者会提供配置值例如,一组用于测试的值和另一组用于生产的值,或者用于每种 build 类型的一组不同的值。
  • 产品集成商。在本示例中,负责将组件与特定产品或开发板的供应配置值集成的开发者均基于该产品或开发板。他们可能是开发该组件的人。
  • 车队管理员。在这里,管理一组设备的团队提供配置值。例如,如果发布存在问题,可以停用功能标志。
  • 设备管理员。在这里,管理设备的人员或组织负责提供值。例如,启用新的实验性功能。对于开发设备,管理员是使用设备的开发者。如果基于 Fuchsia 的产品支持企业用例,拥有设备的企业可担任设备管理员。
  • 最终用户。在此示例中,设备的最终用户会提供值,例如在设置流程中设置设备区域。

相同的配置数据可能需要由多个操作者设置,并且可能由不同操作者在不同情况下设置。例如,某项功能可能由某个产品中的产品集成商停用,但可由另一产品中的管理员设置。

数据何时修复?

  • 在发布时已修复。如果配置数据只能由组件开发者或产品集成商(在某些情况下或舰队管理员)更改,那么配置数据会在产品发布时得到解决。这意味着发布流程可以在签名之前验证配置。例如,Fuchsia 团队可以验证调试选项在正式版中是否始终处于停用状态。
  • 运行时可修改。设备管理员或最终用户(在某些情况下,或舰队管理员)能够更改的配置数据必须能够在设备运行时进行更改。

在某些产品或 build 类型中发布时,相同的配置数据可能是固定的,但在其他产品或 build 类型中,运行时可修改。

有多少组件会使用这些数据?

  • 一个组件。在大多数情况下,只需要一个组件使用配置数据。该组件的开发者可以定义数据,如果需要,可以将配置与组件实现紧密耦合。
  • 多个组件。在某些情况下,多个组件需要共享相同的配置数据,例如多个不同的组件可能需要知道一组已获批准的 SSL 根密钥。

配置是否因组件实例而异?

  • 。这里只有一个组件实例,或者有多个组件实例始终使用相同的配置值。例如,设备上读取板级架构的所有组件实例都应接收相同的值。
  • 可以。在更复杂的情况下,需要向同一组件的不同实例提供不同的配置值。集成测试中经常会发生这种情况。例如,在集成测试中运行组件实例时,其超时值可能需要低于在生产环境中运行时的超时值。

数据有多大?

  • 规模小。大多数组件的配置数据大小不大或中等;几字节到几十千字节。一个典型的例子是,组件使用几个整数来配置其性能,再加上几十个布尔值来启用实验或功能。
  • L:在某些情况下,配置数据要大得多,以兆字节为单位。例如,传感器的校准映射或大型机器学习模型的参数。