The purpose of this document is to provide short definitions for a collection of technical terms used in Fuchsia.
When adding new definitions, follow these guidelines:
- A definition should provide a high-level description of a term and in most cases should not be longer than two or three sentences.
- When another non-trivial technical term needs to be employed as part of the description, consider adding a definition for that term and linking to it from the original definition.
- A definition should be complemented by a list of links to more detailed documentation and related topics.
The Application Binary Interface (ABI) for a system is the binary-level interface to the system. Typically you don't write software that uses the system ABI directly. Instead, you write software against the system API. When the software is compiled, the binary artifact created by the compiler interfaces with the system through the ABI. Changes to the system ABI may require you to recompile your source code to account for the changes in the ABI.
A Modular concept that is being deprecated.
See Agent concept docs for more.
Banjo is a language for defining protocols that are used to communicate between drivers. It is different from FIDL in that it specifies an ABI for drivers to use to call into each other, rather than an IPC protocol.
In Components v2, a component instance binds to another component instance when it connects to a capability provided by the other component instance. This is the most common reason for a component to start.
The bootfs RAM disk contains the files needed early in the boot process when no
other filesystems are available. It is part of the ZBI,
and is decompressed and served by bootsvc. After the early boot
process is complete, the bootfs is mounted at
bootsvc is the second process started in Fuchsia. It provides a filesystem
service for the bootfs and a loader service that loads programs from
the same bootfs. After starting these services, it loads the third program,
which defaults to
A driver for a device that has multiple children. For example, hardware interfaces like PCI specify a topology in which a single controller is used to interface with multiple devices connected to it. In that situation, the driver for the controller would be a bus driver.
Similar to a data directory, except that the contents of a cache directory may be cleared by the system at any time, such as when the device is under storage pressure. Canonically mapped to /cache in the component instance’s namespace.
A capability is a value that combines an object reference and a set of rights. When a program has a capability it is conferred the privilege to perform certain actions using that capability. A handle is a common example for a capability.
A way for one component to give capabilities to another instance over the component instance tree. Component manifests define how routing takes place, with syntax for service capabilities, directory capabilities, and storage capabilities.
Capability routing is a components v2 concept.
A component instance may use the
manifest keyword to indicate that it is making a
capability available to its parent to route. Parents may offer a
capability exposed by any of their children to their other children or to their
parent, but they cannot use it themselves in order to avoid dependency
A channel is an IPC primitive provided by Zircon. It is a bidirectional, datagram-like transport that can transfer small messages including Handles. FIDL protocols typically use channels as their underlying transport.
A component is a unit of executable software on Fuchsia. Components support capability routing, software composition, isolation boundaries, continuity between executions, and introspection.
Component collection is a components v2 concept.
Component declaration is a components v2 concept.
An application framework for declaring and managing components, consisting of build tools, APIs, conventions, and system services.
Component instance tree
A tree structure that represents the runtime state of parent-child relationships between component instances. If instance A launches instance B then in the tree A will be the parent of B. The component instance tree is used to route capabilities such that parents can offer capabilities to their children to use, and children can expose capabilities for their parents to expose to their parents or offer to other children.
Component instance tree is a components v2 concept.
A system service that lets component instances manage their children and routes capabilities between them, thus implementing the component instance tree. Component Manager is the system service that implements the components v2 runtime.
In Components v1, a component manifest is a JSON file with a
.cmx extension that contains information about a component’s
runtime configuration, services and directories it receives in its
namespace, and facets.
Component Manifest Facet
Component Instance Identifier
A unique, stable identifer for a component instance. The instance id is the canonical identifier for a component instance. The component runtime uses this to key a component's persistent resources, if it has any. While a component instance's moniker may change, its instance ID remains the same.
Instance IDs are assigned to component instances using a component ID index.
A URL that identifies a component, most often used when
instantiating a component, for example
See also: fuchsia-pkg URL
A shorthand for the Component Architecture as first implemented on Fuchsia. Includes a runtime as implemented by appmgr and sysmgr, protocols and types as defined in fuchsia.sys, build-time tools such as cmc, and IDK libraries such as libsys and libsvc.
See also: Components v2
A shorthand for the Component Architecture in its modern implementation. Includes a runtime as implemented by component_manager, protocols and types as defined in fuchsia.sys2, and build-time tools such as cmc.
See also: Components v1
Concurrent Device Driver
A concurrent device driver is a hardware driver that supports multiple concurrent operations. This may be, for example, through a hardware command queue or multiple device channels. From the perspective of the core driver, the device has multiple pending operations, each of which completes or fails independently. If the driven device can internally parallelize an operation, but can only have one operation outstanding at a time, it may be better implemented with a sequential device driver.
A core driver is a driver that implements the application-facing RPC interface for a class of drivers (e.g. block drivers, ethernet drivers). It is hardware-agnostic. It communicates with a hardware driver through banjo to service its requests.
A capability that permits access to a filesystem directory by adding it to the namespace of the component instance that uses it. If multiple component instances are offered the same directory capability then they will have access to the same underlying filesystem directory.
Directory capability is a components v2 concept.
A Driver Host is a process containing one or more device drivers. They are created by the Driver Manager, as needed, to provide isolation between drivers for stability and security.
The Driver Manager (formerly devmgr or devcoordinator) is responsible for enumerating, loading, and managing the life cycle of device drivers.
A component added to a session dynamically through the
ElementManager. In addition to the
properties common to all components, Elements are also annotated by Element
Proposers. Those annotations are shared with other components within the
It is the session's responsibility to manage the lifecycle of elements.
Elements are a Session Framework concept.
Element annotations are a Session Framework concept.
Element manager is a Session Framework concept.
Element Proposer is a Session Framework concept.
A container for a set of components, which provides a way to manage their lifecycle and provision services for them. All components in an environment receive access to (a subset of) the environment's services.
Graphics library for compositing user interface content. Its design is inspired by modern real-time and physically based rendering techniques though we anticipate most of the content it renders to have non-realistic or stylized qualities suitable for user interfaces.
The Fuchsia Archive Format is a container for files to be used by Zircon and Fuchsia.
FBL is the Fuchsia Base Library, which is shared between kernel and userspace.
The Fuchsia Driver Framework is the documentation, APIs, and ABIs necessary to build Zircon Device Drivers. Device drivers are implemented as ELF shared libraries loaded by Zircon's Driver Manager.
fdio is the Zircon IO Library. It provides the implementation of posix-style
open(), close(), read(), write(), select(), poll(), etc, against the RemoteIO
RPC protocol. These APIs are return- not-supported stubs in libc, and linking
against libfdio overrides these stubs with functional implementations.
The Fuchsia Interface Definition Language (FIDL) is a language for defining protocols that are typically used over channels. FIDL is programming language agnostic and has bindings for many popular languages, including C, C++, Dart, Go, and Rust. This approach lets system components written in a variety of languages interact seamlessly.
Flutter is a functional-reactive user interface framework optimized for Fuchsia and is used by many system components. Flutter also runs on a variety of other platforms, including Android and iOS. Fuchsia itself does not require you to use any particular language or user interface framework.
FIDL Tuning Proposal. An FTP is the way developers can suggest changes to FIDL. After being written, an FTP goes through a formal review process where it is either accepted or rejected.
Fuchsia API Surface
Fuchsia emulator (FEMU)
The Fuchsia emulator (FEMU) is the default emulator for Fuchsia. It allows you to test Fuchsia components and applications without needing a Fuchsia device. FEMU is based on the Android Emulator (AEMU), which is a fork of QEMU.
A Fuchsia Package is a unit of software distribution. It is a collection of files, such as manifests, metadata, zero or more executables (e.g. Components), and assets. Individual Fuchsia Packages can be identified using fuchsia-pkg URLs.
The fuchsia-pkg URL scheme is a means
for referring to a repository, a package, or a package resource. The syntax is
fuchsia-pkg://<repo-hostname>[/<pkg-name>][#<path>]]. E.g., for the component
echo_client_dart.cmx published under the package
directory, from the
fuchsia.com repository, its URL is
Fuchsia Integrator Development Kit (IDK)
The Fuchsia IDK is a collection of libraries and tools that the Fuchsia project provides to Fuchsia developers. Among other things, the Fuchsia IDK contains a definition of the Fuchsia System Interface as well as a number of client libraries. The IDK is targeted at development environment integrators that add environment specific tooling specific to the build environment to form a full SDK.
Fuchsia System Interface
The Fuchsia System Interface is the binary interface that the Fuchsia operating system presents to software it runs. For example, the entry points into the vDSO as well as all the FIDL protocols are part of the Fuchsia System Interface.
Fuchsia Volume Manager
Fuchsia Volume Manager (FVM) is a partition manager providing dynamically allocated groups of blocks known as slices into a virtual block address space. The FVM partitions provide a block interface enabling filesystems to interact with it in a manner largely consistent with a regular block device.
GN is a meta-build system that generates build files so that Fuchsia can be
built with Ninja. GN is fast and comes with solid tools to manage and
explore dependencies. GN files, named
BUILD.gn, are located all over the
GraphicalPresenter organizes and presents graphical views.
The presented views can be annotated with
Element Annotations to communicate presentation
properties to the
GraphicalPresenter. This protocol is used, for example, when
a session component written in Rust wants to delegate presentation
logic to a child component written in Flutter, or when a session
component that manages the lifecycle of elements delegates the presentation of
element views to a child component that implements
For more information, see the GraphicalPresenter concept documentation.
GraphicalPresenter is a Session Framework concept.
A hardware driver is a driver that controls a device. It receives requests from its core driver and translates them into hardware-specific operations. Hardware drivers strive to be as thin as possible. They do not support RPC interfaces, ideally have no local worker threads (though that is not a strict requirement), and some will have interrupt handling threads. They may be further classified into sequential device drivers and concurrent device drivers.
The hub is a portal for tools to access detailed structural information about component instances at runtime, such as their names, job and process ids, and exposed capabilities.
Input pipeline client library
A client library available to session authors to simplify the consumption and routing of input events from physical hardware.
Input pipeline is a Session Framework concept.
Input pipeline InputDeviceBinding
A Rust trait in the input pipeline client library.
InputDeviceBinding represents a connection to a physical input device (e.g.
mouse, keyboard) in an input pipeline. An
InputDeviceBinding does the
- Connects to an
InputReportfile located at
InputEvents from the
The input pipeline creates and owns
InputDeviceBindings as new input
peripherals are connected to a device.
InputDeviceBinding is a Session Framework concept.
Input pipeline DeviceDescriptor
InputDeviceDescriptor describes the ranges of values a particular input
device can generate. For example, a
the keys available on the keyboard, and a
contains the maximum number of touch contacts and the range of
y-values each contact can take on.
InputDeviceDescriptor is a Session Framework concept.
Input pipeline InputDeviceEvent
A property of the Rust struct
InputDeviceEvent represents an input event from an input device.
InputDeviceEvents contain more context than the raw
InputReports they are parsed from. For example,
InputDeviceEvent::Keyboard contains all the pressed keys, as well as the key's
phase (pressed, released, etc.).
InputDeviceEvent is a Session Framework concept.
Input pipeline InputEvent
A Rust struct in the input pipeline client library.
An event from an input device containing context (a
state (e.g. phase and location of a button press). The input pipeline generates
InputEvents from hardware signals.
InputEvent is a Session Framework concept.
Input pipeline InputHandler
A Rust trait in the input pipeline client library.
- Forwards the
InputEventto the relevant client component.
- Outputs a vector of
InputEvents for the next
InputHandler is a Session Framework concept.
A stateless representation of an event from a physical input device. Zircon
InputReports from HID Reports.
Jiri is a tool for multi-repo development. It is used to checkout the Fuchsia codebase. It supports various subcommands, which makes it easy for developers to manage their local checkouts.
A kernel object is a kernel data structure that is used to regulate access to system resources such as memory, i/o, processor time and access to other processes. Userspace can only reference kernel objects via Handles.
A Kernel Object Identifier.
Little Kernel (LK) is the embedded kernel that formed the core of the Zircon Kernel. LK is more microcontroller-centric and lacks support for MMUs, userspace, system calls -- features that Zircon added.
A Modular concept that is being deprecated.
A module is a role a component can play to contribute UI to a user
experience container (story) within a Modular session. Any component that
exports a Scenic
ViewProvider can be be used as a module.
See Module concept docs for more.
A moniker identifies a specific component instance in the component tree using a topological path.
A v1 component's moniker is defined as a tuple of (path to the component's realm, component URL).
A v2 component's moniker is defined as a path to the component instance in the component instance tree.
Fuchsia's standard C library (libc) is based on Musl Libc.
An implementation of TCP, UDP, IP, and related networking protocols for Fuchsia.
Ninja is the build system executing Fuchsia builds. It is a small build system with a strong emphasis on speed. Unlike other systems, Ninja files are not supposed to be manually written but should be generated by other systems, such as GN in Fuchsia.
OpaqueTest is a Rust client-side library that sets up hermetic tests for a v2
A tool in Zircon that installs partition images to internal storage of a device.
Platform Source Tree
The Platform Source Tree is the open source code hosted on fuchsia.googlesource.com, which comprises the source code for Fuchsia. A given Fuchsia system can include additional software from outside the Platform Source Tree by adding the appropriate Fuchsia Package.
A Process is a kernel object that represents an instance of a program as a set of instructions that are executed by one or more threads together with a collection of capabilities. Every process is contained in a job.
In FIDL, a protocol groups methods and events to describe how one process interacts with another.
A capability that permits communicating with a protocol over a channel using a specified FIDL protocol. The server end of the channel is held by the component instance that provides the capability. The client end of the channel is given to the component instance that uses the capability.
Protocol capability is a components v2 concept.
A component that provides a runtime environment for other components, e.g. the ELF runner, the Dart AOT runner, the Chromium web runner.
Every component needs a runner in order to launch. Components express their dependency on a runner in the component's declaration.
When the component framework starts a component, it first determines the capabilities that the component should receive, then asks the component's runner to launch the component. The runner is responsible for creating any necessary processes, loading executable code, initializing language runtimes, handing control to the component's entry points, and terminating the component when requested by the component framework.
Scenic is a system service that composes graphical objects from multiple processes into a shared scene graph. Scenic includes views, input, compositor, and GPU services.
Sequential Device Driver
A capability that permits communicating with a service over a channel using a specified FIDL service. The server end of the channel is held by the component instance that provides the capability. The client end of the channel is given to the component instance that uses the capability.
Service capability is a components v2 concept.
A session is a component that encapsulates a product’s user experience. It is the first product-specific component started on boot after the Session Manager. Sessions typically utilize aspects of the Session Framework during their development, in automated testing, and at runtime. At runtime, there is only one session component, but it can be composed of many sub-components. For example, the session for a graphical product instantiates Scenic (graphics) as a child component.
Session is a Session Framework concept.
The session framework is a framework for building products on Fuchsia. The framework provides software libraries, FIDL protocols, developer tools, and standards that are composed to create a particular product’s user experience.
See the session framework conceptual documentation.
Session Launcher is a Session Framework concept.
The platform component, started late in the Fuchsia boot sequence, that manages the lifecycle of the session. The session manager defines the set of system capabilities provided to sessions at runtime.
Session Manager is a Session Framework concept.
A storage capability is a capability that allocates per-component isolated storage for a designated purpose within a filesystem directory. Multiple component instances may be given the same storage capability, but underlying directories that are isolated from each other will be allocated for each individual use. This is different from directory capabilities, where a specific filesystem directory is routed to a specific component instance.
Isolation is achieved because Fuchsia does not support dotdot.
There are three types of storage capabilities:
- data: a directory is added to the namespace of the component instance that uses the capability. Acts as a data directory.
- cache: same as data, but acts as a cache directory.
- meta: a directory is allocated to be used by component manager, where it will store metadata to enable features like persistent component collections.
Storage capability is a components v2 concept.
userboot is the first process started by the Zircon kernel. It is loaded from the kernel image in the same way as the vDSO, instead of being loaded from a filesystem. Its primary purpose is to load the second process, bootsvc, from the bootfs.
ViewController represents a handle to a remote View that was launched by
PresentView() on a
this handle, the caller (often, the session) can request changes--such as to
update annotations--and control the View's lifecycle. Closing the
ViewController should close the presented view, and allow the system to
reclaim its resources.
ViewHolderToken uniquely identifies an attachment point for a View in the
global scene graph. Each
ViewHolderToken has exactly one corresponding
ViewRef is a handle to a kernel object that identifies a unique View across
the system. Two
ViewRefs to the same View have the same KOID.
ViewSpec is a description of a view to be presented by a
ViewToken uniquely identifies a View, which is the root point for a subgraph
in the global scene graph. Each
ViewToken has exactly one corresponding
Virtual Dynamic Shared Object
The Virtual Dynamic Shared Object (vDSO) is a Virtual Shared Library -- it is
provided by the Zircon kernel and does not appear in the filesystem
or a package. It provides the Zircon System Call API/ABI to userspace processes
in the form of an ELF library that's "always there." In the Fuchsia IDK and
Fuchsia Driver Framework it exists as
libzircon.so for the purpose of
having something to pass to the linker representing the vDSO.
Virtual Memory Address Range
Virtual Memory Object
A Virtual Memory Object (VMO) is a Zircon kernel object that represents a collection of pages (or the potential for pages) that may be read, written, mapped into the address space of a process, or shared with another process by passing a Handle over a Channel.
Zircon Boot Image
A Zircon Boot Image (ZBI) contains everything needed during the boot process before any drivers are working. This includes the kernel image and a RAM disk for the boot filesystem.
Zedboot is a recovery image that is used to install and boot a full Fuchsia system. Zedboot is actually an instance of the Zircon kernel with a minimal set of drivers and services running used to bootstrap a complete Fuchsia system on a target device. Upon startup, Zedboot listens on the network for instructions from a bootserver that may instruct Zedboot to install a new OS. Upon completing the installation Zedboot will reboot into the newly installed system.
Zircon is the microkernel and lowest level userspace components (driver runtime environment, core drivers, libc, etc) at the core of Fuchsia. In a traditional monolithic kernel, many of the userspace components of Zircon would be part of the kernel itself.
ZX is an abbreviation of "Zircon" used in Zircon C APIs/ABIs
ZX_EVENT_SIGNALED, etc) and libraries
(libzx in particular).
The native low-level system debugger.