The purpose of this document is to provide short definitions for a collection of technical terms used in Fuchsia.
An agent is a role a component can play to execute in the background in the context of a session. An agent's life cycle is not tied to any story, is a singleton per session, and provides services to other components. An agent can be invoked by other components or by the system in response to triggers like push notifications. An agent can provide services to components, send and receive messages, and make proposals to give suggestions to the user.
The Application Manager (AppMgr) is responsible for launching components and managing the namespaces in which those components run. It is the first process started in the fuchsia job by the DevMgr.
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.
The platform-guaranteed set of software functionality which provides a basic user-facing interface for boot, first-use, authentication, escape from and selection of session shells, and device recovery.
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 /boot.
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 devmgr.
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 which 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 expose 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 cycles.
A component instance may use the offer manifest keyword to route a capability that was exposed to it to one of its children (other than the child that exposed it).
A component instance may use the use manifest keyword to consume a capability that was offered to it by its parent.
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.
A node in the component instance tree whose children are dynamically instantiated rather than statically defined in a component manifest.
Component collection is a components v2 concept.
A component declaration is a FIDL table (fuchsia.sys2.ComponentDecl) that includes information about a component’s runtime configuration, capabilities it exposes, offers, and uses, and facets.
Component declaration is a components v2 concept.
An application framework for declaring and managing components, consisting of build tools, APIs, conventions, and system services.
One of possibly many instances of a particular component at runtime. A component instance has its own environment and lifecycle independent of other instances.
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 in static capability routing 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 which 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.
In Components v2, a component manifest is a file with a .cm extension, that encodes a component declaration.
Additional metadata that is carried in a component manifest. This is an extension point to the component framework.
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 SDK libraries such as libsys and libsvc.
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.
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 private directory within which a component instance may store data local to the device, canonically mapped to /data in the component instance’s namespace.
A Device Host (DevHost) is a process containing one or more device drivers. They are created by the Device Manager, as needed, to provide isolation between drivers for stability and security.
The Device Manager (DevMgr) is responsible for enumerating, loading, and managing the life cycle of device drivers, as well as low level system tasks (providing filesystem servers for the boot filesystem, launching AppMgr, and so on).
The Driver Development Kit is the documentation, APIs, and ABIs necessary to build Zircon Device Drivers. Device drivers are implemented as ELF shared libraries loaded by Zircon's Device Manager.
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 is a dynamic shared library which DevMgr can load into a DevHost and that enables, and controls one or more devices.
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.
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.
The Fuchsia API Surface is the combination of the Fuchsia System Interface and the client libraries included in the Fuchsia SDK.
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 echo_dart's meta directory, from the fuchsia.com repository, its URL is fuchsia-pkg://fuchsia.com/echo_dart#meta/echo_client_dart.cmx.
The Fuchsia SDK is a collection of libraries and tools that the Fuchsia project provides to Fuchsia developers. Among other things, the Fuchsia SDK contains a definition of the Fuchsia System Interface as well as a number of client libraries.
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 (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 which 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 repository.
A Handle is how a userspace process refers to a kernel object. They can be passed to other processes over Channels.
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 introspection. It enables tools to access detailed structural information about realms and component instances at runtime, such as their names, job and process ids, and published services.
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 Job is a kernel object that groups a set of related processes, their child processes and their jobs (if any). Every process in the system belongs to a job and all jobs form a single rooted tree.
A kernel object is a kernel data structure which 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.
Ledger is a distributed storage system for Fuchsia. Applications use Ledger either directly or through state synchronization primitives exposed by the Modular framework that are based on Ledger under-the-hood.
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 module is a role a component can play to participate in a story. Every component can be be used as a module, but typically a module is asked to show UI. Additionally, a module can have a module metadata file which describes the Module's data compatibility and semantic role.
Fuchsia's standard C library (libc) is based on Musl Libc.
A namespace is the composite hierarchy of files, directories, sockets, services, and other named objects which are offered to components by their environment.
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.
A file system directory where a component may expose capabilities for others to use.
Package is an overloaded term. Package may refer to a Fuchsia Package or a GN build package.
A tool in Zircon that installs partition images to internal storage of a device.
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.
In components v1, realm is synonymous to environment.
In components v2, a realm is a subtree of component instances in the component instance tree. It acts as a container for component instances and capabilities in the subtree.
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.
The system compositor. Includes views, input, compositor, and GPU services.
A sequential device driver is a hardware driver that will only service a single request at a time. The core driver synchronizes and serializes all requests.
A service is an implementation of a FIDL interface. Components can offer their creator a set of services, which the creator can either use directly or offer to other components.
Services can also be obtained by interface name from a Namespace, which lets the component that created the namespace pick the implementation of the interface. Long-running services, such as Scenic, are typically obtained through a Namespace, which lets many clients connect to a common implementation.
A capability that permits communicating with a service 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.
Service capability is a components v2 concept.
An interactive session with one or more users. Has a session shell, which manages the UI for the session, and zero or more stories. A device might have multiple sessions, for example if users can interact with the device remotely or if the device has multiple terminals.
The replaceable set of software functionality that works in conjunction with devices to create an environment in which people can interact with mods, agents and suggestions.
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:
Storage capability is a components v2 concept.
A user-facing logical container encapsulating human activity, satisfied by one or more related modules. Stories allow users to organize activities in ways they find natural, without developers having to imagine all those ways ahead of time.
The system responsible for the visual presentation of a story. Includes the presenter component, plus structure and state information read from each story.
userboot is the first process started by the Zircon kernel. It is loaded from the kernel image in the same way as the [vDSO](#Virtual Dynamic Shared Object), instead of being loaded from a filesystem. Its primary purpose is to load the second process, bootsvc, from the bootfs.
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 SDK and Zircon DDK it exists as libzircon.so for the purpose of having something to pass to the linker representing the vDSO.
A Virtual Memory Address Range (VMAR) is a Zircon kernel object that controls where and how Virtual Memory Objects may be mapped into the address space of a process.
A Virtual Memory Object (VMO) is a Zircon kernel object that represents a collection of pages (or the potential for pages) which may be read, written, mapped into the address space of a process, or shared with another process by passing a Handle over a Channel.
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 which 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_channel_create(), zx_handle_t, ZX_EVENT_SIGNALED, etc) and libraries (libzx in particular).
The native low-level system debugger.
