此页面由 Cloud Translation API 翻译。

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

RFC-0041：支持统一服务和设备
状态	已接受
领域	FIDL
说明	引入服务的概念，这是协议集合，其中可能包含一个或多个集合实例。
作者	abdulla@google.com jeffbrown@google.com pascallouis@google.com abarth@google.com
提交日期（年-月-日）	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 中声明的那样），其中该成员声明的类型表示预期协议

设计

服务风格

我们首先考虑一下我们所支持的各种服务类型：

单个唯一协议：ONE 个实例、ONE 协议：

/svc/fuchsia.Scheduler/default/profile_provider

多个协议的组合：ONE 个实例、MANY 个协议：

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

一项服务的多个实例，使用单个协议：MANY 个实例，ONE 协议：
```
/svc/fuchsia.hardware.Block/0/device
                        .../1/device
```

采用不同协议集的多个实例：MANY 个实例、MANY 协议：

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

语言

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

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

service 关键字允许我们编写服务声明，我们可以使用该声明将一组协议定义为服务的成员。例如，我们可以声明不同的服务口味，如下所示：

单个唯一协议：ONE 个实例、ONE 协议：

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

多个协议的组合：ONE 个实例、MANY 个协议：

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

一项服务的多个实例，使用单个协议：MANY 个实例，ONE 协议：
```
service Block {
  fuchsia.hardware.block.Device device;
};
```

多个实例，采用不同的协议集：MANY 个实例、MANY 协议

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

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

当服务实例包含与另一个实例不同的协议集时，该服务声明会声明任何实例中可能存在的所有可能协议。请参阅上文中的“使用不同协议集的多个实例”。

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

语言绑定

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

使用单个协议连接到服务的“默认”实例：ONE 个实例、ONE 协议：

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();

通过多种协议连接到服务的“默认”实例：ONE实例、MANY协议：

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();

使用单个协议连接到某项服务的多个实例：MANY 个实例、ONE 协议：

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();

使用多种协议连接到一项服务的多个实例：MANY 个实例、MANY 协议：

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_installation 检索）。

// 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 阶段

修改 module_manager，使 v2 组件支持服务的新目录架构。
修改 appmgr 和 sysmgr，以便组件 v1 支持新的服务目录架构。

第 2 阶段

添加了对服务声明的支持。
修改语言绑定以生成服务。

第 3 阶段

请为具有 Discoverable 属性的所有协议创建适当的服务声明。> 注意：在此阶段，我们应验证服务的旧目录架构和新目录架构之间是否不存在 name > 冲突。
迁移所有源代码以使用服务。

第 4 阶段

从 FIDL 文件中移除所有 Discoverable 属性。
从 FIDL 和语言绑定中移除了对 Discoverable 的支持。
从 module_manager、appmgr 和 sysmgr 中移除了对旧目录架构的支持。

文档和示例

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

术语库

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

服务声明描述了服务提供商作为单元提供的功能。它由服务名称和零个或多个已命名的成员协议组成，客户端用于与该 capability 进行交互。

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

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 未知的其他实例，用户将需要列出服务的目录并找到该实例，然后再进行连接。

对构建和二进制文件大小的影响微乎其微，因为后端必须为特定语言绑定生成服务定义。

安全性

该方案将使我们能够执行更精细的访问权限控制，因为我们可以将服务拆分为具有不同访问权限的不同协议。

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

测试

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

缺点、替代方案和未知情况

具体问题如下：

为什么服务声明属于 FIDL？
协议、服务和组件之间有什么区别？
为服务实例提议的扁平拓扑是否具有足够的表现力？
我们应如何逐步扩展服务？
如果组件实例希望公开与单个底层逻辑资源相关的多项服务，该如何表达？

问题 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：协议、服务和组件之间有什么区别？

协议声明描述了可能通过通道发送或接收的一组消息及其二进制表示法。
服务声明描述了服务提供商作为一个单元提供的功能。它由服务名称和零个或多个已命名的成员协议组成，客户端使用这些协议与 capability 进行交互。
- 同一协议可能会作为服务声明的成员多次出现；成员的名称表示协议的预期解释。
  - 例如：service Foo { fuchsia.io.File logs; fuchsia.io.File journal; };