Fuchsia术语

预览


本文件的目的是为fuchsia中使用的一系列技术术语提供简短的定义。

添加新的定义

  • 定义应该是一项高水准的描述。通常不会多于两到三句。
  • 当需要使用另一个重要的技术术语作为描述的一部分时,请考虑为该术语添加一个定义,并从原始定义链接到它。
  • 一个定义应该由一个链接列表来补充,该列表指向更详细的文档和相关主题。

条款


代理(Agent)

代理是组件可以在会话上下文的后台执行的角色。代理的生命周期不与任何故事绑定,它是每个会话的一个单例,并向其他组件提供服务。代理可以由其他组件或系统调用,以响应诸如推送通知之类的触发器。代理可以向组件提供服务,发送和接收消息,并提出建议,为用户提供建议。

应用管理器(AppMgr)

应用程序管理器(AppMgr)负责启动组件并管理这些组件运行的名称空间。这是DevMgr在Fuchsia作业中启动的第一个流程。

Banjo

Banjo是一种定义用于在驱动程序之间通信的协议的语言。它与FIDL的不同之处在于,它指定了一个ABI供驱动程序相互调用,而不是IPC协议。

Base shell

平台保证的软件功能集,它提供了一个基本的面向用户的界面,用于引导、首次使用、身份验证、会话shell的转义和选择以及设备恢复。

bootfs

bootfs RAM磁盘包含引导过程早期所需的文件,此时没有其他文件系统可用。它是ZBI的一部分,由bootsvc解压并提供服务。在早期引导过程完成后,将在/boot处挂载引导文件。

  • Documentation

bootsvc

bootsvc是fuchsia启动的第二个进程。它为引导程序(bootfs)提供了一个文件系统服务,并提供了一个加载器服务,用于从相同的引导程序加载程序。启动这些服务之后,它将加载第三个程序,默认为devmgr。

  • Documentation

Bus Driver

具有多个子设备的驱动程序。例如,像PCI这样的硬件接口指定一个拓扑,其中一个控制器用于与连接到它的多个设备进行接口。在这种情况下,控制器的驱动程序将是总线驱动程序。

Cache directory

类似于data directory,但是缓存目录的内容可以在任何时候被系统清除,比如当设备处于存储压力时。以标准方式映射到组件实例的名称空间中的/缓存。

  • Testing isolated cache storage

Capability

Capability是一个结合了对象引用和一组权限的值。当程序具有某种功能时,它被授予使用该功能执行某些操作的特权。句柄(handle)是功能(Capability)的常见示例。

Capability routing

一个组件( component)通过组件实例树(component instance tree)向另一个实例提供功能(capabilities)。组件清单( Component manifests )使用服务功能(service capabilities)、目录功能( directory capabilities)和存储功能(storage capabilities)的语法定义路由如何发生。

能力路由是一个组件v2( components v2)概念

expose

组件实例(component instance)可以使用expose manifest关键字来指示它使父组件能够路由。父组件可以提供由任何子组件向其他子组件或父组件公开的功能,但是他们不能自己使用它来避免依赖循环。

offer

组件实例(component instance)可以使用offer manifest关键字将公开给它的功能路由到它的一个子实例(公开它的子实例除外)。

use

组件实例可以使用use manifest关键字来使用其父实例提供的功能。

Channel

通道是Zircon提供的IPC基元。它是一种双向的、类似于数据流的传输,可以传输包括句柄(Handles.)在内的小消息。FIDL协议通常使用通道作为其底层传输。

  • Channel Overview

Component

组件(Component)是fuchsia上可执行软件的一个单元。组件支持功能路由( capability routing)、软件组合、隔离边界、执行之间的连续性和自省

Component collection

组件实例树(component instance tree )中的一个节点,其子节点是动态实例化的,而不是在组件清单(component manifest.)中静态定义的。

组件集合是一个组件v2(components v2 )概念。

Component declaration

组件声明是一个FIDL表(fuchsia.sys2.ComponentDecl),其中包含关于组件的运行时配置、它公开、提供和使用的功能以及方面的信息。

组件集合是一个组件v2概念。

Component Framework

用于声明和管理组件的应用程序框架,包括构建工具、api、约定和系统服务。

  • Components v1,Components v2

Component instance

运行时某个特定组件的多个实例之一。组件实例有自己独立于其他实例的环境和生命周期。

Component instance tree

表示组件实例之间父子关系的运行时状态的树结构。如果实例A启动实例B,那么树中的A就是B的父结点。组件实例树用于静态功能路由,这样父节点就可以将功能提供给子节点使用,子节点也可以将功能公开给父节点,从而将功能公开给父节点或提供给其他子节点。

组件实例树是一个组件v2(Components v2)概念。

Component Manager

一个系统服务,它允许组件实例管理它们的子实例,并在它们之间路由功能,从而实现组件实例树。组件管理器是实现组件v2运行时的系统服务。

Component Manifest

在Components v1中,组件清单是一个JSON文件,扩展名为.cmx,其中包含关于组件的运行时配置、在名称空间中接收的服务和目录以及facet的信息。

在component v2中,组件清单是一个扩展名为.cm的文件,它编码组件声明。

  • Component manifests v2

Component Manifest Facet

组件清单中包含的附加元数据。这是组件框架的扩展点

Components v1

第一次在Fuchsia上实现的组件体系结构的简写。包括appmgr和sysmgr实现的运行时、fuchsia中定义的协议和类型。sys、构建时工具(如cmc)和SDK库(如libsys和libsvc)。

  • Components v2

Components v2

组件体系结构在其现代实现中的简写。包括component_manager实现的运行时、fuchsia中定义的协议和类型。和构建时工具,如cmc。

  • Components v1

Concurrent Device Driver

并发设备驱动程序是支持多个并发操作的硬件驱动程序。:例如,这可以通过硬件命令队列或多个设备通道实现。从核心驱动( core driver)程序的角度来看,设备有多个挂起的操作,每个操作独立完成或失败。如果驱动设备可以在内部并行化一个操作,但是一次只能有一个未完成的操作,那么使用顺序设备驱动( sequential device driver.)程序可能会更好。

** core driver**

核心驱动程序是为一类驱动程序(例如块驱动程序、以太网驱动程序)实现面向应用程序的RPC接口的驱动程序。这是hardware-agnostic。它通过banjo与硬件驱动程序通信,以满足其请求。

Data directory

一个私有目录,组件实例可以在其中存储设备本地的数据,这些数据通常映射到组件实例的名称空间中的/data。

DevHost

设备主机(DevHost)是一个包含一个或多个设备驱动程序的进程。它们是由设备管理器根据需要创建的,用于在驱动程序之间提供稳定性和安全性隔离。

DevMgr

设备管理器(DevMgr)负责枚举、加载和管理设备驱动程序的生命周期,以及低层系统任务(为引导文件系统提供文件系统服务器,启动AppMgr,等等)。

DDK

驱动程序开发工具包(The Driver Development Kit)是构建Zircon设备驱动程序所必需的文档、api和ABIs。设备驱动程序实现为ELF共享库,由Zircon的设备管理器加载。

  • DDK Overview
  • DDK includes

Directory capability

通过将文件系统目录添加到使用它的组件实例的名称空间,从而允许访问该文件系统目录的功能。如果为多个组件实例提供了相同的目录功能,那么它们将能够访问相同的底层文件系统目录。

目录功能是组件v2的概念。

  • Capability routing

Driver

驱动程序是一个动态共享库,DevMgr可以将其加载到DevHost中,从而启用和控制一个或多个设备。

  • Reference
  • Driver Sources

Environment

一组组件的容器,它提供一种方法来管理组件的生命周期并为组件提供服务。环境中的所有组件都接受对环境服务(子集)的访问。

Escher

用于合成用户界面内容的图形库。它的设计灵感来自于现代实时和基于物理的渲染技术,尽管我们预计它渲染的大部分内容都具有不现实或程式化的适合用户界面的质量。

FAR

Fuchsia Archive Format(far)是Zircon和Fuchsia使用的文件格式。

  • FAR Spec

FBL

FBL是Fuchsia基础库,在内核和用户空间之间共享。

  • Zircon C++

fdio

fdio是Zircon IO库。它针对RemoteIO RPC协议提供了posix风格的open()、close()、read()、write()、select()、poll()等的实现。这些api是libc中不支持返回的存根,针对libfdio的链接使用函数实现覆盖了这些存根。

  • Source

FIDL

Fuchsia接口定义语言(FIDL)是一种用于定义通常在通道上使用的协议的语言。FIDL与编程语言无关,它对许多流行的语言都有绑定,包括C、c++、Dart、Go和Rust。这种方法允许用多种语言编写的系统组件无缝交互。

Flutter

Flutter是一种针对Fuchsia进行优化的功能反应型用户界面框架,被许多系统组件所使用。Flutter还可以在其他多种平台上运行,包括Android和iOS。Fuchsia本身不要求您使用任何特定的语言或用户界面框架。

Fuchsia API Surface

Fuchsia API表面是Fuchsia系统接口和包含在Fuchsia SDK中的客户端库的组合。

Fuchsia Package

Fuchsia Package是软件分发的一个单元。它是文件的集合,例如清单、元数据、零个或多个可执行文件(例如组件)和assets。可以使用fuchsia-pkg URLs标识单个的Fuchsia Packages。

fuchsia-pkg URL

fuchsia-pkg URL方案是引用存储库、包或包资源的一种方法。语法是fuchsia-pkg://[/][# ]]. E.g., 。例如,对于组件echo_client_dart。cmx发布在包echo_dart的meta目录下,从fuchsia.com存储库中,它的URL是fuchsia-pkg://fuchsia.com/echo_dart#meta/echo_client_dart.cmx。

Fuchsia SDK

Fuchsia SDK是Fuchsia项目为Fuchsia开发人员提供的库和工具的集合。此外,Fuchsia SDK包含一个Fuchsia系统接口的定义,以及一些客户端库。

Fuchsia System Interface

紫红色系统接口是紫红色操作系统向其运行的软件提供的二进制接口。:例如,vDSO的入口点以及所有FIDL协议都是Fuchsia 系统接口的一部分。

Fuchsia Volume Manager

Fuchsia卷管理器(FVM)是一个分区管理器,它将动态分配的块组(称为片)提供给虚拟块地址空间。FVM分区提供了一个块接口,允许文件系统以与常规块设备基本一致的方式与它交互。

  • Filesystems

GN

GN是一个元构建系统,它生成构建文件,因此可以用Ninja构建Fuchsia。GN速度很快,并且提供了可靠的工具来管理和探索依赖关系。GN文件,名为BUILD.gn,分布在整个存储库中。

  • Language and operation
  • Reference
  • Fuchsia build overview

Handle

句柄是用户空间进程引用内核对象的方式。它们可以通过通道传递给其他进程。

  • Reference

Hardware Driver

硬件驱动程序是控制设备的驱动程序。它接收来自其核心驱动程序的请求,并将其转换为特定于硬件的操作。硬件驱动程序力求尽可能轻量级。它们不支持RPC接口,理想情况下不支持本地工作线程(尽管这不是一个严格的要求),并且有些将具有中断处理线程。它们可以进一步分为顺序设备驱动程序( sequential device drivers)和并发设备驱动程序(concurrent device drivers)。

Hub

集线器是用于内省的门户。它使工具能够在运行时访问关于领域和组件实例的详细结构信息,例如它们的名称、作业和流程id,以及已发布的服务。

  • Hub

Jiri

Jiri是一个用于多回购开发的工具。它用于检测Fuchsia代码基。它支持各种子命令,这使得开发人员很容易管理他们的本地签出。

  • Reference
  • Sub commands
  • Behaviour
  • Tips and tricks

Job

作业是一个内核对象,它对一组相关的进程、子进程和作业(如果有的话)进行分组。系统中的每个进程都属于一个作业,所有作业都形成一个根树。

  • Job Overview

Kernel Object

内核对象是内核数据结构,用于调节对系统资源的访问,如内存、i/o、处理器时间和对其他进程的访问。用户空间只能通过句柄引用内核对象。

  • Reference

KOID

内核对象标识符。

  • Kernel Object

Ledger

Ledger是Fuchsia的分布式存储系统。应用程序可以直接使用分类账,也可以通过模块化框架公开的状态同步原语来使用分类账。

LK

微核(LK)是构成Zircon核心的嵌入核。LK更以微控制器为中心,缺乏对MMUs、用户空间和系统调用的支持——Zircon增加了这些功能。

  • LK on Github

Module

模块是组件可以在故事中扮演的角色。每个组件都可以用作模块,但通常要求模块显示UI。此外,模块可以具有描述模块的数据兼容性和语义角色的模块元数据文件。

  • Module metadata format

Musl

Fuchsia的标准C库(libc)是基于Musl libc的。

  • Source
  • Musl Homepage

Namespace

名称空间是文件、目录、套接字、服务和其他命名对象的组合层次结构,这些对象由组件的环境提供给组件。

  • Fuchsia Namespace Spec

Netstack

一种用于Fuchsia的TCP、UDP、IP和相关网络协议的实现。

Ninja

Ninja是执行Fuchsia构建的构建系统。它是一个小型构建系统,非常强调速度。与其他系统不同,Ninja文件不应该手工编写,而应该由其他系统生成,比如Fuchsia的GN。

  • Manual
  • Ninja rules in GN
  • Fuchsia build overview

Outgoing directory

一个文件系统目录,组件可以在其中公开功能供其他人使用。

Package

包是一个重载术语。包可以指Fuchsia包或GN构建包。

Paver

Zircon中的一种工具,它将分区映像安装到设备的内部存储中。

  • Guide for installing Fuchsia with paver.

Platform Source Tree

平台源代码树是托管在fuchsia上的开放源代码。googlesource.com,它包含了Fuchsia的源代码。一个给定的Fuchsia系统可以通过添加适当的Fuchsia包来包含来自平台源代码树外部的附加软件。

Realm

在component v1中,领域(Realm)是环境的同义词。
在component v2中,领域(Realm)是组件实例树中组件实例的子树。它充当子树中组件实例和功能的容器。

Runner

为其他组件提供运行时环境的组件,例如ELF运行器、Dart AOT运行器、Chromium web运行器。

为了启动每一个组件都需要一个runner。组件在组件声明中表示它们对运行器的依赖。

当组件框架启动组件时,它首先确定组件应该接收的功能,然后要求组件的运行器启动组件。运行器负责创建任何必要的流程、加载可执行代码、初始化语言运行时、将控制权交给组件的入口点,以及在组件框架请求时终止组件。

  • ELF runner

Scenic

系统服务集。包括视图、输入、合成程序和GPU服务。

Sequential Device Driver

顺序设备驱动程序是一种硬件驱动程序,一次只处理一个请求。核心驱动程序同步和序列化所有请求。

Service

服务是FIDL接口的实现。组件可以向它们的创建者提供一组服务,创建者可以直接使用这些服务,也可以向其他组件提供这些服务。

还可以通过接口名称从名称空间获取服务,这让创建名称空间的组件选择接口的实现。长时间运行的服务(如Scenic)通常通过名称空间获得,该名称空间允许许多客户端连接到公共实现。

Service capability

允许使用指定的FIDL协议通过通道与服务通信的功能。通道的服务器端由提供该功能的组件实例持有。通道的客户端被提供给使用该功能的组件实例。

  • Capability routing

服务能力是一个组件v2概念。

Session

与一个或多个用户的交互会话。有一个会话shell(管理会话的UI)和零个或多个故事。一个设备可能有多个会话,例如,如果用户可以远程与该设备交互,或者该设备有多个终端。

Session Shell

可替换的软件功能集,与设备一起工作,创建一个环境,在这个环境中,人们可以与mods、代理和建议交互。

Storage capability

存储功能是在文件系统目录中为指定的目的为每个组件分配隔离存储的功能。多个组件实例可能具有相同的存储能力,但是将为每个单独使用分配彼此隔离的底层目录。这与目录功能不同,目录功能将特定的文件系统目录路由到特定的组件实例。

由于Fuchsia不支持dotdot,所以实现了隔离。

有三种类型的存储功能:

  • data:目录被添加到使用该功能的组件实例的名称空间中。充当数据目录。
  • cache:与数据相同,但充当缓存目录。
  • meta:分配一个目录供组件管理器使用,它将在其中存储元数据,以启用诸如持久组件集合之类的功能。

存储能力是组件v2的概念。

  • Capability routing
  • Storage capabilities

Story

封装人类活动的面向用户的逻辑容器,由一个或多个相关模块满足。故事允许用户以他们认为自然的方式组织活动,而无需开发人员提前想象所有这些方式。

Story Shell

负责故事的视觉呈现的系统。包括presenter组件,以及从每个故事中读取的结构和状态信息。

userboot

userboot是Zircon内核启动的第一个进程。它以与vDSO相同的方式从内核映像加载,而不是从文件系统加载。它的主要目的是从引导文件加载第二个进程bootsvc。

  • Documentation

Virtual Dynamic Shared Object

虚拟动态共享对象(vDSO)是一个虚拟共享库——它由Zircon内核提供,不会出现在文件系统或包中。它以“始终存在”的ELF库的形式向用户空间进程提供Zircon系统调用API/ABI。在Fuchsia SDK和Zircon DDK中,它以libzircon的形式存在。所以为了有东西传递给代表vDSO的链接器。

Virtual Memory Address Range

虚拟内存地址范围(VMAR)是一个Zircon内核对象,它控制虚拟内存对象可以映射到进程的地址空间的位置和方式。

  • VMAR Overview

Virtual Memory Object

虚拟内存对象(VMO)是一个Zircon内核对象,它表示一组页(或潜在的页),这些页可以读、写、映射到进程的地址空间,或者通过在通道上传递一个句柄与另一个进程共享。

  • VMO Overview

Zircon Boot Image

Zircon启动映像(ZBI)包含启动过程中任何驱动程序工作之前所需的所有内容。这包括内核映像和引导文件系统的RAM磁盘。

  • ZBI header file

Zedboot

Zedboot是一个恢复映像,用于安装和引导一个完整的Fuchsia系统。Zedboot实际上是Zircon内核的一个实例,它运行的驱动程序和服务最少,用于在目标设备上引导一个完整的Fuchsia系统。启动时,Zedboot在网络上侦听来自引导服务器的指令,这些指令可能会指示Zedboot安装一个新的操作系统。安装完成后,Zedboot将重新启动到新安装的系统中。

Zircon

Zircon是Fuchsia核心的微内核和底层用户空间组件(驱动程序运行时环境、核心驱动程序、libc等)。在传统的单片内核中,Zircon的许多用户空间组件都是内核本身的一部分。

  • Zircon Documentation
  • Zircon Concepts
  • Source

ZX

ZX是Zircon C api /ABIs (zx_channel_create()、zx_handle_t、zx_event_等)和库(特别是libzx)中使用的“Zircon”的缩写。

ZXDB

本机低级系统调试器。

  • Reference

你可能感兴趣的:(Fuchsia)