RFC-0041：支持统一服务和设备

RFC-0041：支持统一服务和设备
状态已接受
区域
  • FIDL
说明

引入了服务的概念，即协议的集合，其中可能包含一个或多个集合实例。
作者
提交日期（年-月-日）2019-04-08
审核日期（年-月-日）2019-04-23

修改此 RFC

修改 RFC 元数据

摘要

引入了服务的概念，即协议的集合，其中可能包含一个或多个集合实例。

设计初衷

目前，在组件框架内，服务被定义为单个协议，并且在 /svc 下的进程命名空间中只能存在该协议的一个实例。这会导致我们无法描述更复杂的关系：

  • 以两种不同形式表示的服务，具体取决于使用方 - 例如，当协议有两个不同的版本（如 FontProvider 和 FontProviderV2）时
  • 一种分为两部分的服务，用于根据访问权限级别授予功能，例如常规访问权限与管理访问权限，如 Directory 和 DirectoryAdmin，其中后者提供特权访问权限
  • 一种由许多不同协议组成的供不同消费者使用的服务，例如，Power 用于电源管理，Ethernet 用于网络堆栈
  • 具有多个实例的服务 - 例如，提供 AudioRenderer 的多个音频设备，或公开 Printer 的多个打印机

这种灵活性可让服务更清晰地表达，而无需使用服务中心等变通方法。凭借这种灵活性，我们可以将设备定义为服务。 具体而言，我们计划将 /svc/$Protocol（表示“每个进程命名空间只能有一个协议”）演变为：

/svc/$Service/$Instance/$Member

而是引入了两个额外的间接层：服务（例如打印机、以太网）和实例（例如 default、deskjet_by_desk、e80::d189:3247:5fb6:5808）。协议的路径将包含以下部分：

  • $Service - 服务的完全限定类型，如 FIDL 中所声明
  • $Instance - 服务的实例名称，其中“default”按惯例用于表示首选（或唯一）可用实例
  • $Member - FIDL 中声明的服务成员名称，其中该成员的声明类型表示预期协议

设计

服务类型

我们先来考虑一下我们打算支持的各种服务：

  • 单个唯一协议：一个实例，一个协议：

    /svc/fuchsia.Scheduler/default/profile_provider

  • 多种协议的组合：一个实例，多个协议：

    /svc/fuchsia.Time/default/network
                      .../rough

  • 具有单一协议的多个服务实例：多个实例，一个协议：

    /svc/fuchsia.hardware.Block/0/device
                        .../1/device

  • 多个实例，具有不同的协议集：多个实例，多个协议：

    /svc/fuchsia.Wlan/ff:ee:dd:cc:bb:aa/device
                                .../power
              .../00:11:22:33:44:55/access_point
                                .../power

语言

为了向 FIDL 引入服务的概念并支持各种风格，我们将对 FIDL 语言进行以下更改：

  1. 添加 service 关键字。
  2. 移除 Discoverable 属性。

借助 service 关键字，我们可以编写服务声明，用于将一组协议定义为服务的成员。例如，我们可以按如下方式声明不同的服务变体：

  • 单个唯一协议：一个实例，一个协议：

    service Scheduler {
  fuchsia.scheduler.ProfileProvider profile_provider;
};

  • 多种协议的组合：一个实例，多个协议：

    service Time {
  fuchsia.time.Provider network;
  fuchsia.time.Provider rough;
};

  • 具有单一协议的多个服务实例：多个实例，一个协议：

    service Block {
  fuchsia.hardware.block.Device device;
};

  • 多个实例，具有不同的协议集：多个实例，多个协议

    service Wlan {
  fuchsia.hardware.ethernet.Device device;
  fuchsia.wlan.AccessPoint access_point;
  fuchsia.hardware.Power power;
};

一个服务声明可以有多个使用相同协议的成员，但每个成员声明必须使用不同的标识符。 请参阅上文中的“多种协议的组合”。

如果某服务的实例可能包含与另一实例不同的协议集，则服务声明会声明任何实例中可能存在的所有协议。请参阅上文中的“多个实例，具有不同的协议集”。

服务声明不会提及服务的特定实例的名称或提供服务的组件的 URI，这由组件框架根据组件清单声明和运行时对其 API 的使用来决定。

语言绑定

语言绑定将进行修改，以便更方便地连接到服务。 具体而言，它们将更加注重服务，例如：

  • 连接到服务的“默认”实例，使用单一协议：一个实例，一个协议：

    • C++：
    Scheduler scheduler = Scheduler::Open();
ProfileProviderPtr profile_provider;
scheduler.profile_provider().Connect(profile_provider.NewRequest());
    • Rust：
    let scheduler = open_service::<Scheduler>();
let profile_provider: ProfileProviderProxy = scheduler.profile_provider();

  • 连接到具有多种协议的服务的“默认”实例：一个实例，多种协议：

    • C++：
    Time time = Time::Open();
ProviderPtr network;
time.network().Connect(&network);
ProviderPtr rough;
time.rough().Connect(&rough);
    • Rust：
    let time = open_service::<Time>();
let network = time.network();
let rough = time.rough();

  • 使用单个协议连接到服务的多个实例：多个实例，一个协议：

    • C++：
    Block block_0 = Block::OpenInstance("0");
DevicePtr device_0;
block_0.device().Connect(&device_0);

Block block_1 = Block::OpenInstance("1");
DevicePtr device_1;
block_1.device().Connect(&device_1);
    • Rust：
    let block_0 = open_service_instance::<Block>("0");
let device_0 = block_0.device();
let block_1 = open_service_instance::<Block>("1");
let device_1 = block_1.device();

  • 连接到服务的多个实例，使用多种协议：多个实例，多种协议：

    • C++：
    Wlan wlan_a = Wlan::OpenInstance("ff:ee:dd:cc:bb:aa");
DevicePtr device;
wlan_a.device().Connect(&device);
Power power_a;
wlan_a.power().Connect(&power_a);

Wlan wlan_b = Wlan::OpenInstance("00:11:22:33:44:55");
AccessPoint access_point;
wlan_b.access_point().Connect(&access_point);
Power power_b;
wlan_b.power().Connect(&power_b);
    • Rust：
    let wlan_a = open_service_instance::<Wlan>("ff:ee:dd:cc:bb:aa");
let device = wlan_a.device();
let power_a = wlan_a.power();

let wlan_b = open_service_instance::<Wlan>("00:11:22:33:44:55");
let access_point = wlan_b.access_point();
let power_b = wlan_b.power();

以下示例展示了建议的函数签名。

请注意，Open() 和 OpenInstance() 方法还接受一个可选参数来指定命名空间。默认情况下，将使用进程的全局命名空间（可以使用 fdio_ns_get_installed 进行检索）。

// Generated code.
namespace my_library {
class MyService final {
public:
  // Opens the "default" instance of the service.
  //
  // |ns| the namespace within which to open the service or nullptr to use
  // the process's "global" namespace as defined by |fdio_ns_get_installed()|.
  static MyService Open(fdio_ns_t* ns = nullptr) {
    return OpenInstance(fidl::kDefaultInstanceName, ns);
  }

  // Opens the specified instance of the service.
  //
  // |name| the name of the instance, must not be nullptr
  // |ns| the namespace within which to open the service or nullptr to use
  // the process's "global" namespace as defined by |fdio_ns_get_installed()|.
  static MyService OpenInstance(const std::string& instance_name,
                                fdio_ns_t* ns = nullptr);

  // Opens the instance of the service located within the specified directory.
  static MyService OpenAt(zxio_t* directory);
  static MyService OpenAt(fuchsia::io::DirectoryPtr directory);

  // Opens a directory of available service instances.
  //
  // |ns| the namespace within which to open the service or nullptr to use
  // the process's "global" namespace as defined by |fdio_ns_get_installed()|.
  static fidl::ServiceDirectory<MyService> OpenDirectory(fdio_ns_t* ns = nullptr) {
    return fidl::ServiceDirectory<MyService>::Open(ns);
  }

  // Gets a connector for service member "foo".
  fidl::ServiceConnector<MyService, MyProtocol> foo() const;

  // Gets a connector for service member "bar".
  fidl::ServiceConnector<MyService, MyProtocol> bar() const;

  /* more stuff like constructors, destructors, etc... */
}

以及绑定代码：

/// FIDL bindings code.
namespace fidl {
constexpr char[] kDefaultInstanceName = "default";

// Connects to a particular protocol offered by a service.
template <typename Service, typename Protocol>
class ServiceConnector final {
public:
   zx_status_t Connect(InterfaceRequest<Protocol> request);
};

// A directory of available service instances.
template <typename Service>
class ServiceDirectory final {
public:
  // Opens a directory of available service instances.
  //
  // |ns| the namespace within which to open the service or nullptr to use
  // the process's "global" namespace as defined by |fdio_ns_get_installed()|.
  static ServiceDirectory Open(fdio_ns_t* ns = nullptr);

  // Gets the underlying directory.
  zxio_t* directory() const;

  // Gets a list of all available instances of the service.
  std::vector<std::string> ListInstances();

  // Opens an instance of the service.
  Service OpenInstance(const std::string& name);

  // Begins watching for services to be added or removed.
  //
  // Invokes the provided |callback| to report all currently available services
  // then reports incremental changes.  The callback must outlive the returned
  // |Watcher| object.
  //
  // The watch ends when the returned |Watcher| object is destroyed.
  [[nodiscard]] Watcher Watch(WatchCallback* callback,
                              async_dispatcher_t* dispatcher = nullptr);

  // Keeps watch.
  //
  // This object has RAII semantics.  The watch ends once the watcher has
  // been destroyed.
  class Watcher final {
  public:
    // Ends the watch.
    ~Watcher();
  };

  // Callback invoked when service instances are added or removed.
  class WatchCallback {
  public:
    virtual void OnInstanceAdded(std::string name) = 0;
    virtual void OnInstanceRemoved(std::string name) = 0;
    virtual void OnError(zx_status_t error) = 0;
  };
}

语言绑定将在此基础上进一步扩展，提供便捷的方法来迭代服务实例，并监视是否有新的实例可用。

服务演变

为了使服务不断发展，我们可以随着时间的推移向其中添加新协议。为了保持源代码兼容性，不应移除现有协议，否则源代码兼容性可能会被破坏，因为用户可能依赖于通过语言绑定从服务生成的代码。

由于服务中的所有协议实际上都是可选的，因此它们可能会在运行时提供，也可能不会提供，并且组件应针对这种可能性进行构建，这简化了我们在发展服务时面临的一系列问题：

  • 您可以随时向服务添加协议成员
  • 应避免移除协议成员（为了实现源代码兼容性）
  • 重命名协议成员涉及添加新协议成员，并保留现有协议成员

为了发展服务本身，我们也有类似的限制。无法保证服务存在于组件的命名空间内，并且服务可以在命名空间内的多个不同位置显示，因此：

  • 您可以随时添加服务
  • 应避免移除服务（为了实现源代码兼容性）
  • 重命名服务涉及复制服务并使用新名称，同时保留服务的原始副本（以实现源代码兼容性）

可能的扩展程序

我们预计 service 实例最终会成为“一等公民”，并允许作为消息的一部分，就像 protocol P 句柄可以作为 P 或 request<P> 传递一样。例如，对于 service S，这可能采用 service_instance<S> 这样的形式。我们会确保可以延长，但目前不会为此投入工作。

我们为扩展可能的成员类型（不仅限于允许协议）留出了空间（并计划这样做）。例如，我们可能希望通过服务公开 VMO (handle<vmo>)：

service DesignedService {
    ...
    handle<vmo>:readonly logo; // gif87a
};

实施策略

此提案应分阶段实施，以免破坏现有代码。

第 1 阶段
  1. 修改了 component_manager，使组件 v2 支持新的服务目录架构。
  2. 修改了 appmgr 和 sysmgr，使组件 v1 支持新的服务目录架构。
第 2 阶段
  1. 添加了对服务声明的支持。
  2. 修改语言绑定以生成服务。
第 3 阶段
  1. 对于具有 Discoverable 属性的所有协议，请创建相应的服务声明。 > 注意：在此阶段，我们应验证服务的新旧目录架构之间是否可能发生名称冲突。
  2. 迁移所有源代码以使用服务。
第 4 阶段
  1. 从 FIDL 文件中移除所有 Discoverable 属性。
  2. 从 FIDL 和语言绑定中移除了对 Discoverable 的支持。
  3. 从 component_manager、appmgr 和 sysmgr 中移除了对旧目录架构的支持。

文档和示例

我们需要扩展 FIDL 教程，以说明服务声明的用法以及它们如何与协议交互。然后，我们会说明服务的不同结构：单例与多实例，以及如何使用语言绑定。

术语库

协议声明描述了一组可能通过渠道发送或接收的消息及其二进制表示形式。

服务声明描述了服务提供方以单元形式提供的功能。 它由服务名称和零个或多个客户端用于与功能互动的具名成员协议组成。

同一协议可能会多次显示为服务声明的成员，其中成员的名称表示协议的预期解释：

service Foo {
    fuchsia.io.File logs;
    fuchsia.io.File journal;
};

组件声明描述了可执行软件的单元，包括组件二进制文件的位置以及它打算使用、公开或提供给其他组件的功能（例如服务）。

此信息通常在软件包中编码为组件清单文件：

// frobinator.cml
{
    "uses": [{ "service": "fuchsia.log.LogSink" }],
    "exposes": [{ "service": "fuchsia.frobinator.Frobber" }],
    "offers": [{
        "service": "fuchsia.log.LogSink",
        "from": "realm",
        "to": [ "#child" ]
    }],
    "program": { "binary": ... }
    "children": { "child": ... }
}

服务实例是一种符合给定服务声明的功能。 在 Fuchsia 上，它以目录的形式表示。 其他系统可能会使用不同的服务发现机制。

组件实例是具有自己的私有沙盒的组件的特定实例。在运行时，它通过打开其传入命名空间中的目录来使用其他组件提供的服务实例。相反，它通过在出站目录中显示自己的服务实例，将其公开给其他组件。组件管理器充当服务发现的代理。

  • 组件实例通常（但不总是）与进程一一对应。
  • 组件运行程序通常可以在同一进程中运行多个组件实例，每个实例都有自己的传入命名空间。

服务的惯用用法

向后兼容性

此提案将弃用并最终移除 FIDL 中的 Discoverable 属性。

线材格式没有任何变化。

如果您要引入新的数据类型或语言功能，请考虑您希望用户对 FIDL 定义做出哪些更改，而不会破坏生成的代码的用户。 如果您的功能对生成的语言绑定施加了任何新的来源兼容性限制，请在此处列出。

性能

在连接到服务的默认实例或已知实例（先验）时，这应该不会对 IPC 性能产生影响。

如需连接到实例 ID 未先验的另一个实例，用户需要先列出服务的目录并找到该实例，然后才能进行连接。

对 build 和二进制文件大小的影响很小，因为服务定义必须由后端针对特定语言绑定生成。

安全

此提案将允许我们实施更精细的访问权限控制，因为我们可以将服务拆分为具有不同访问权限的单独协议。

此提案对安全性没有其他影响。

测试

编译器中的单元测试，以及对兼容性测试套件的更改，以检查服务中包含的协议是否可以连接。

缺点、替代方案和未知因素

本文探讨了以下问题：

问题 1：为什么服务声明属于 FIDL？

响应

  • 我们使用 FIDL 来描述 Fuchsia 的系统 API，包括组件交换的协议。
  • 根据具体情况，同一协议可用于多种方式。 将这些协议的各种用途表示为服务，可让开发者更轻松地在每种情况下访问正确的协议集。
  • FIDL 已经提供了语言绑定，可以轻松扩展这些绑定，为开发者提供一种一致且便捷的方式来访问这些服务。

讨论

  • [ianloic] 但组件清单呢？为什么不使用 FIDL 来描述这些内容呢？
  • [jeffbrown] 组件清单描述的概念远不止 IPC 问题
  • [abdulla] 在组件清单中描述服务会导致这些服务的说明重复
  • [ianloic] 我们能否从组件的清单生成其框架？
  • [drees] 在 FIDL 中放置服务声明会强制执行特定结构，这在其他平台上是否有意义？
  • [jeffbrown] 我们希望服务的声明位于组件外部，因为它们需要在组件之间共享，这是服务交换的协议点
  • [ianloic] overnet 的服务声明可能类似
  • [pascallouis] 最好先从我们现在知道自己需要的东西入手，简单开始。后续可以根据需要进行调整。
  • [pascallouis] FIDL 是 Fuchsia 的首选，因此引入仅在该上下文中才有意义的功能是有道理的，但随着时间的推移，这些功能可能会推广到其他上下文
  • [dustingreen] 如果是单独的文件呢？
  • [pascallouis] 这些文件会非常小且孤立，如果我们将它们保留在 FIDL 中，则有机会进行静态类型检查，如果需要，稍后移动它们风险似乎很低

问题 2：协议、服务和组件之间有何区别？

响应

  • 协议声明描述了一组可能通过渠道发送或接收的消息及其二进制表示形式。
  • 服务声明描述了服务提供方以单元形式提供的功能。 它由服务名称和零个或多个客户端用于与功能互动的具名成员协议组成。
    • 同一协议可能会多次显示为服务声明的成员；成员的名称表示协议的预期解释。
      • 例如，service Foo { fuchsia.io.File logs; fuchsia.io.File journal; };

  • 组件声明描述了可执行软件的单元，包括组件二进制文件的位置以及它打算使用、公开或提供给其他组件的功能（例如服务）。

    • 此信息通常在软件包中编码为组件清单文件。示例：

      // frobinator.cml
{
    "uses": [{ "service": "fuchsia.log.LogSink" }],
    "exposes": [{ "service": "fuchsia.frobinator.Frobber" }],
    "offers": [{ "service": "fuchsia.log.LogSink",
                 "from": "realm", "to": [ "#child" ]}],
    "program": { "binary": ... }
    "children": { "child": ... }
}

  • 服务实例是一种符合给定服务声明的功能。在 Fuchsia 上，它以目录的形式表示。 其他系统可能会使用不同的服务发现机制。

  • 组件实例是组件的特定实例，具有自己的专用沙盒。 在运行时，它通过打开其传入命名空间中的目录来使用其他组件提供的服务实例。相反，它通过在出站目录中显示自己的服务实例，将这些实例公开给其他组件。组件管理器充当服务发现的代理。

    • 组件实例通常（但不总是）与进程一一对应。
    • 组件运行程序通常可以在同一进程中运行多个组件实例，每个实例都有自己的传入命名空间。

讨论

  • [ianloic] 在选择协议组合与服务声明时，我们应提供哪些指导？
  • [abdulla] 协议组合表示协议本身高度相关，而服务表示一组（可能不相关的）功能正在共同提供
  • [pascallouis] compose 在单个渠道上多路复用协议，因此会对消息排序产生影响，而服务的各个协议具有不同的渠道
  • [jeffbrown] 可以在不同的位置进行委托，这些位置不相关，组合无法实现此功能，服务允许在运行时进行“发现”，例如列出哪些协议可用

问题 3：所提出的服务实例扁平拓扑是否具有足够的表达能力？

响应

  • 扁平拓扑易于使用，因为无需以递归方式遍历路径来定位所有实例。这会影响易用性和性能。
  • 当相关信息编码在实例名称中时，扁平拓扑结构与分层拓扑结构一样具有表现力，例如 /svc/fuchsia.Ethernet/rack.5,port.9/packet_receiver。
  • 可以使用 Open()、Open(namespace) 和 OpenAt(directory) 从不同位置访问服务。换句话说，并非所有服务都需要来自进程全局命名空间中的 `/svc"。这样一来，您就可以根据需要创建任意服务拓扑。

问题 4：我们应该如何随着时间的推移扩展服务？

响应

  • 我们可以向现有服务声明添加新成员。 添加新成员不会破坏源代码或二进制文件兼容性，因为每个成员实际上都是可选的（尝试连接到协议的操作可能会失败）。
  • 我们可以从服务声明中移除现有成员。 移除（或重命名）现有成员可能会破坏源代码和二进制文件兼容性，可能需要制定周密的迁移计划来减轻不利影响。
  • 服务的文档应明确说明该服务的预期使用或实现方式，尤其是在此类使用方式并不明显时，例如，说明服务的哪些功能已被弃用并计划移除。

  • 版本控制的预期模式：随着协议的发展，向服务添加新成员。 协议枚举（列出目录）可让客户端发现支持的内容。 示例：

    • 在版本 1 中…

      service Fonts {
    FontProvider provider;
};

protocol FontProvider {
    GimmeDaFont(string font_name) -> (fuchsia.mem.Buffer ttf);
};

    • 在版本 2 中，增量更新...

      service Fonts {
    FontProvider provider;
    FontProvider2 provider2;
};

protocol FontProvider2 {
    compose FontProvider;
    GetDefaultFontByFamily(string family) -> (string family);
};

    • 在版本 3 中，我们进行了完全重新设计...

      service Fonts {
    [Deprecated]
    FontProvider provider;
    [Deprecated]
    FontProvider provider2;
    TypefaceChooser typeface_chooser;
}

protocol TypefaceChooser {
    GetTypeface(TypefaceCriteria criteria);
};

table TypefaceCriteria {
    1: Family family;
    2: Style style;
    3: int weight;
};

问题 5：如果组件实例希望公开与单个底层逻辑资源相关的多项服务，该如何表达？

响应

  • 组件将定义通过其组件清单公开的多个服务。示例：

    // frobinator.cml
{
    ...
    "exposes": [
        { "service": "fuchsia.frobinator.Fooer" },
        { "service": "fuchsia.frobinator.Barer" },
    ],
    ...
}

  • 然后，该组件会在单个底层资源之上实现这些服务，但这些服务的用户无需了解这一事实。