Fuchsia命名空间

Fuchsia命名空间

命名空间是Fuchsia操作系统中文件存取和服务发现的基石。

定义

命名空间是一个综合的层级结构,包括文件、目录、套接口、服务、设备和其它的有名对象,这些对象被其环境提供给组件使用。

让我们稍微解释一下。

有名对象: 命名空间中包含的可由名字枚举和访问的对象,诸如列出一个目录的内容和打开一个文件。

综合层级结构: 命名空间为一个由对象组成的树状结构,这些对象可由其它命名空间的对象子树组合而来,从而形成一个综合的层级结构,按照惯例,其中的每个部分都被赋予一个路径前缀。

组件之命名空间: 每个组件裁剪自身的命名空间以符合自身的需求。它也可发布自身的对象到其它的命名空间中。

环境构造: 实例化组件的环境需要负责构造合适的命名空间,以便组件运行在合适的范围。

虽然本文档专注于介绍典型的绑定组件的命名空间用法,但是命名空间也可被独立的创建和使用。

命名空间实战

你可能已经花费了许多时间在Fuchsia命名空间的探索上,它们无处不在。如果你在命令行提示符下键入ls /,将会看到需要对象列表,表明这些对象在shell命令行的命名空间中时可访问的。

不同于其它操作系统,Fuchsia没有"根文件系统"。正如之前所述,命名空间基于组件而定义,并不是全局有效的,也非基于进程的。

这包含了一些有趣的隐含点:

  • 没有全局的"root"命名空间.
  • 没有类似Linux中的概念"运行在chroot-ed的环境中",因为每个组件 实质上由其私有的"root".
  • 组件接受的命名空间据其特定需求进行了裁剪.
  • 在命名空间边界之外,对象的路径可能没有意义.
  • 在某一时刻,进程可拥有访问多个截然不同的命名空间的权限.
  • 以组件为基础,控制访问文件的权限机制,也可用来控制对服务的访问,以及对其它有名对象的访问.

对象

命名空间中的成员称为对象。它们以多种形式存在,包括:

  • 文件: 包含二进制数据的对象
  • 目录: 包含其它对象的对象
  • 套接口: 打开后可建立连接的对象, 类似命名管道
  • 服务: 打开后提供FIDL服务的对象
  • 设备: 提供访问硬件资源的对象

对象的访问

为了访问命名空间中的对象,你必须已经拥有另外一个对象。典型的,在命名空间转移过程中,组件会在其命名空间的范围内接收到对象的通道句柄.

通过执行合适的FIDL接口,你也可凭空创建出一个新的对象。

给定一个对象的通道,你可以打开其子对象的通道,方法是给其发送一条FIDL消息,消息内容包含表示希望打开的子对象的相对路径表达式.

注意,你仅可访问对于已在访问对象可达的对象。没有依据环境的授权。

现在我们看一下对象的名称和路径时如何构建的.

对象名称

对象名称时一个本地唯一的标签,据此对象可安置于一个容器内(例如目录)。注意,名称是容器的子对象表的一个属性,而不是对象本身的属性。

例如,cat 指派一个对象,位于由调用Open()请求的一些不明确接收者中。

从根本上讲,对象没有名字,但是又可以有多个称呼。

对象名称由二进制8位组字符组成(字节顺序任意),受限于以下约束:

  • 最小长度1个字节.
  • 最大长度255个字节.
  • 不包含 NULs (零值字节).
  • 不包含 /.
  • 不等于 . or ...
  • 总是可比较的字节等式 (意味着区分字母大小写).

对于容器的Open()方法,对象名称是有效的参数。详见 FIDL Interfaces.

对象的命名倾向于使用可编码和可解释为人可读的UTF-8图形字符序列,但是命名空间自身并未强加这一要求。

实际上,客户有责任决定如何对用户程序呈现包含无效的、不可显示的、或者晦涩的字符序列名称。

对象的相对路径表达式

对象的相对路径表达式可以是一个对象名称,或者以/分隔的对象名称,其指定了一系列的嵌套的对象,为了定位容器中的对象需要穿越这些对象(例如目录)。

例如,house/box/cat 指定的对象位于它的容器对象box中,而box位于其容器对象house内,house位于未指明的Open()请求的接收者中。

对象的相对路径表达式总是向命名空间的深层穿越。特别的,命名空间不直接支持脱离容器的向上穿越(如通过..),但是客户可以部分的模仿此功能。

对象的相对路径表达式受以下的额外约束:

  • 最小长度1个字节.
  • 最大长度4095字节.
  • 不能以 / 开头或结尾.
  • 每个片段都是有效的对象名称.
  • 总是可比较的字节等式 (意味着区分字母大小写).

对象的相对路径表达式是容器Open()方法有效参数。详见 FIDL Interfaces.

解释路径表达式的客户

客户解释路径表达式是一种对对象路径表达式的泛化,这些表达式含有可选的特性,客户模拟这些特性以便增强与期望存在具有根的类似文件接口程序的兼容。

技术上讲,这些特性超出了Fuchsia命名空间协议自身的范围,但是又经常使用到,所以在此描述.

  • 客户可指定其命名空间之一作为根"root". 此命名空间表示为 /.
  • 客户可通过增加单一的前缀/,来构建相对于指定根命名空间的路径.
  • 客户可使用..路径片段折叠路径,通过客户端"标准"进程来构建自容器向上穿越的路径(假设容器的路径已知).
  • 这些特性可组合在一起.

例如,/places/house/box/../sofa/cat 指定了一些客户"根"容器内位于 places/house/sofa/cat位置的对象。

包含这些可选特性的客户解释路径表达式不是有效的容器Open() 方法的参数;它们必须先由客户翻译后才能与命名空间交互。 See FIDL Interfaces.

例如,fdio在文件操作API中实现了客户一端对..路径的解释,这些API诸如open(), stat(), unlink()等.

命名空间转移

当一个组件在环境中被实例化(如,它的进程启动),它接收到一个映射了一个或多个命名空间路径前缀到对象句柄的表.

依据惯例,表中路径前缀的编码与其关联对象的有暗指意义。 例如,pkg前缀应当关联与包含组件自身二进制文件和资产的目录。

更多相关内容在下节介绍。

命名空间协定

本节描述运行在Fuchsia系统中的典型组件的命名空间常规布局.

组件命名空间的准确内容和组织依据组件的角色、类型、身份、范畴、与其它组件的关系、以及权限会有很大的不同。详见 [sandboxing.md] 中命名空间如何为组件创建沙盒sndboxes的内容.

关于你的组件期待接收自环境的命名空间的更多内容,请参考你所实现的组件类型的关联文档.

典型对象

组件命名空间可能包含的一些典型对象:

  • 组件包中的只读可执行文件和资产.
  • 私有的本地持久存储.
  • 私有的临时存储.
  • 系统、组件框架、或者启动组件的客户提供于组件的服务.
  • 设备节点 (对于驱动和特权组件).
  • 配置信息.

典型目录结构

  • pkg/: 当前程序包的内容
    • bin/: 包内的可执行二进制文件
    • lib/: 包内的共享库
    • data/: 包内的数据,如资产
  • data/: 本地持久存储 (可读写read-write, 包私有)
  • tmp/: 临时存储 (可读写, 包私有)
  • svc/: 提供给组件的服务
    • fuchsia.process.Launcher: 加载进程
    • fuchsia.logger.Log: 日志信息
    • vendor.topic.Interface: 厂商 定义服务
  • dev/: 设备树 (按照需要对特权组件可见的部分)
    • class/, …
  • hub/: 内省系统, 参见 [hub.md] (仅特权组件)
  • config/: 组件的配置数据

命名空间参与者

这里结束一些与Fuchsia命名空间协议交互或者提供支持的抽象层的信息。

文件系统

文件系统使得文件在命名空间中可用.

简单来说文件系统是一个组件,其可将其它命名空间中的对象以类似文件的形式发布。

服务

服务生存与命名空间中.

服务是众所周知的对象,提供可由命名空间发现的FIDL接口实现。

服务的名称相当与命名空间中svc分支下的路径,由此组件可访问服务的实现。

例如,Fuchsia系统默认的日志服务的名称为fuchsia.logger.Log,它在命名空间中的位置为svc/fuchsia.logger.Log.

组件

组件消耗并且扩展命名空间。

组件时一个可执行的程序对象,在一定环境下被实例化并且给与命名空间。

组件以两种方式参与Fuchsia的命名空间:

  1. 可使用接收自环境发来的命名空间中的对象,特别的,可访问自身的包内容和收到的服务。

  2. 可以命名空间的形式通过其环境发布对象,随后其环境可在收到请求时,使部分对象对其它组件可用。这是组件实现服务的方式。

环境

环境构建命名空间.

环境作为组件的容器。每个环境有责任_构建_其组件将接收的命名空间。

环境决定组件可能访问哪些对象,以及组件按照名称请求的服务如何绑定到具体的实现。

配置

组件可能有不同类型的配置数据,取决于其 Component Manifest 中列出的特性,以文件的形式在/config命名空间中显示。这些有组件的特性集所定义。

FIDL 接口

END

你可能感兴趣的:(fuchsia)