Glossary

The purpose of this document is to provide short definitions for a collection of technical terms used in Fuchsia.

To add a glossary definition, see Adding glossary entries.

Terms

Glossary area




  • The binary-level interface to the system.

    Full description

    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.


  • Fuchsia uses a bootloader with two partitions A and B, and a recovery slot.

    Full description

    Fuchsia uses a bootloader with two partitions A and B, and a recovery slot. This logic is not required to boot Zircon or run a basic Fuchsia system, but it is required to take full advantage of Fuchsia's over-the-air (OTA) update features.

    The term slot is used to refer to a set of partitions that update together. If an update fails, the partitions fall back together. This works because there are two copies of each partition on disk. By convention, the slots used for normal updates are denoted A and B, and the corresponding partitions are labeled with a suffix of "_a" or "_b". The slot used for recovery is denoted R which is chosen when neither A nor B is bootable.


    Related links
  • Keys that have a distinct special action.

    Full description

    Keys corresponding to specific actions, such as "display brightness increment", "display brightness decrement" etc, which are specifically named in the USB HID usage tables.


  • The JSON file that the product owner writes in order to specify (1) lists of product-specific packages, components, drivers, and configuration and (2) platform features and configuration. This is the configuration that encapsulates both a Product Config and a Platform Config.


    Related links
  • An Assembly Input Bundle is a self-contained directory of artifacts with a manifest file in the root describing what is included. This bundle is used internally by the Software Assembly tool. Fuchsia is composed of many packages, components, drivers, and configuration data. These elements are grouped together inside Assembly Input Bundles (AIBs) for inclusion together into the assembled product. All AIBs other than the Legacy AIBs are "platform AIBs".


    Related links
  • Language for definition protocols that communicate between drivers.

    Full description

    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 language used to write bind libraries and bind rules in a static file.


    Related links
  • A bind library is a mechanism used to define node properties. The node properties can be assigned to nodes by their parent drivers or used in the bind rules. Bind libraries are defined through the bind language.


    Related links
  • Bind rules are a defined set of conditions provided by a driver that must be satisfied in order for the driver to match to a node. The conditions are evaluated against node properties. Formerly known as a bind program.


    Related links
  • A board is a complete computer hardware platform with a CPU, memory, peripherals, and so on.

    Full description

    A board is a complete computer hardware platform with a CPU, memory, peripherals, and so on. It defines the architecture that the build produces for, and key features of the device upon which the build is intended to run. This configuration affects what drivers are included, and may also influence device-specific kernel parameters.


    Related links
  • A board driver is a specialized driver that contains the platform-specific information needed by the platform bus and controls what other drivers will be loaded by the platform bus.

    Full description

    A board driver is a specialized driver that contains the platform-specific information needed by the platform bus and controls what other drivers will be loaded by the platform bus. The board driver is the first driver loaded and parented by the platform bus.


    Related links
  • The boot filesystem that contains the files needed early in the boot process.

    Full description

    The bootfs RAM disk contains the files needed early in the boot process when no other filesystems are available. It is part of the zircon boot image, and is decompressed and served by bootsvc. After the early boot process is complete, the bootfs is mounted at `/boot`.


  • Provides a filesystem service for the bootfs and a loader service.

    Full description

    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 `component_manager`.


  • A driver that is available in the Fuchsia image and not critical for bootstrapping the system. These drivers are loaded from the system's storage, so they need to be loaded after the boot drivers have enabled storage (for example, USB drivers, networking drivers).

    Full description

    A driver that is available in the Fuchsia image and not critical for bootstrapping the system. These drivers are loaded from the system's storage, so they need to be loaded after the boot drivers have enabled storage (for example, USB drivers, networking drivers). Base drivers reside in the base packages.


  • A driver that exists in the Zircon Boot Image (ZBI) and is needed for bootstrapping the system (for example, storage drivers).

    Full description

    A driver that exists in the Zircon Boot Image (ZBI) and is needed for bootstrapping the system (for example, storage drivers). The Zircon Boot Image (ZBI) has limited space for such drivers, a constraint that does not generally apply to base drivers.


  • The process of getting Fuchsia to run on a new board.

    Full description

    Bringup is the catchall term for all of the engineering work related to getting Fuchsia to run on a new board. The term "bringup" should not be used for situations where Fuchsia support for the board already exists. For example, flashing a Fuchsia image onto a VIM3 is not bringup. The original engineering work of implementing the drivers and so on so that Fuchsia can run on the VIM3 is bringup.


    Related links
  • A driver for a device that has multiple children.

    Full description

    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. A bus driver does not necessarily correspond to a physical bus.


  • A private directory, that may be cleared by the system at any time, within which a component instance may cache data local to the device.

    Full description

    A private directory, that may be cleared by the system at any time, within which a component instance may cache data local to the device. 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.


    Related links

  • A value that combines an object reference and a set of rights.

    Full description

    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.


    Related links
  • A way for one component instance to give capabilities to another component instance.

    Full description

    A way for one component instance 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.


    Related links
  • An IPC primitive provided by Zircon.

    Full description

    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.


    Related links
  • A key that sends characters to the computer.

    Full description

    A key that sends characters to the computer. This definition does not specifically account for the effect of key composition and dead keys, which are present on certain keyboard layouts, but is operational enough for effective use.


  • A child component instance is a component instance that is owned by another instance, the parent.


    Related links
  • A node that receives resources from parent driver(s).


    Related links
  • A cloud service for storing and distributing packages. Packages can be arbitrary collections of files, but most often contain prebuilt binaries.

    Full description

    The Fuchsia project uses CIPD to download, publish, and distribute compiled software such as the Fuchsia SDK. Jiri has built-in support for versioning and downloading CIPD packages.


    Related links
  • A driver is colocated with another driver when they share the same driver host.


    Related links
  • A Driver Framework v2 (DFv2) driver that wraps a Driver Framework v1 (DFv1) driver so that the DFv1 driver can run in a DFv2 environment.


  • Components are the common abstraction that defines how all software is described, sandboxed, and executed on a Fuchsia system.

    Full description

    Components are the common abstraction that defines how all software (regardless of source, programming language, or runtime) is described, sandboxed, and executed on a Fuchsia system. Components may specify a binary executable, and may be composed of multiple child components.


    Related links
  • A node in the component instance tree whose children are dynamically instantiated rather than statically defined in a component manifest.

    Full description

    A node in the component instance tree whose children are dynamically instantiated rather than statically defined in a component manifest.


    Related links
  • The process of tailoring a component instance to the context it's running in.

    Full description

    The process of tailoring a component instance to the context it's running in. This includes defining and delivering the data that a component can use to understand and adapt to the context in which it was launched.


    Related links
  • Data supplied to a component instance that it can use to understand and adapt to the context in which it was launched.

    Full description

    Data supplied to a component instance that it can use to understand and adapt to the context in which it was launched.


    Related links
  • A FIDL table that includes information about a component.

    Full description

    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.


    Related links
  • An application framework for declaring and managing components, consisting of build tools, APIs, conventions, and system services.


    Related links
  • A specific runtime instantiation of a particular component at a specific location in the component instance tree at runtime.


    Related links
  • A tree structure that represents the runtime state of parent-child relationships component instances.

    Full description

    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.


    Related links
  • A system service that lets component instances manage their children and capability routing between them, thus implementing the component instancetree.

    Full description

    A system service that lets component instances manage their children and capability routing between them, thus implementing the component instancetree. Component manager is the system service that implements the component runtime.


    Related links
  • A binary file ending in .cm that encodes a component declaration, often distributed as part of a package. The term is sometimes used interchangeably with component manifest source.

    Full description

    A binary file ending in .cm that encodes a component declaration, often distributed as part of a package. The cmc tool generates a component manifest from a component manifest source file.


    Related links
  • A JSON5 file with a .cml extension that describes a component's declaration, and is compiled by [cmc] to produce a [component manifest].

    Full description

    A JSON5 file with a .cml extension that describes a component's declaration, and is compiled by [cmc] to produce a [component manifest].

    The file contains information about a [component]'s executable and runtime configuration (if any), any child [component]s, as well as [capability routing] between itself, its parent, and its children.


    Related links
  • Additional component manifest metadata.

    Full description

    Additional metadata that is carried in a component manifest. This is an extension point to the framework.


    Related links
  • A unique, stable identifer for a component instance.

    Full description

    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.


    Related links
  • Collective term for the component instance tree and the capability routes over that tree.

    Full description

    The component topology describes the set of relationships between component instances in a Fuchsia system. It consists of the parent-child relationships of the component instance tree as well as the capability routes over that tree.


    Related links
  • URL that identifies a component's declaration and package.

    Full description

    URL that identifies a component's declaration and package, most often used when instantiating a component. Example: fuchsia-pkg://fuchsia.com/stash#meta/stash_secure.cm.


    Related links
  • A driver that only binds to a composite node. A driver can be defined as a composite via its bind rules.


    Related links
  • A node with multiple parents. The driver that is bound to the composite node can access the combined resources provided by the parent drivers. Formerly known as a composite device.


    Related links
  • A composite node specification is a mechanism for creating a composite node. It describe the nodes that can parent the composite node and the driver that can bind to the composite node.


    Related links
  • A capability that provides a data value that a component can use for configuration. A component using a configuration capability will be able to read the value in it's structured configuration.


    Related links

  • A hardware driver that supports multiple concurrent operations.

    Full description

    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.


  • Graphical content containing a bitmap that is attached to a Transform in Flatland. Image, Viewport and FilledRect are types of Contents.

    Full description

    Graphical content containing a bitmap that is attached to a Transform in Flatland. Image, Viewport and FilledRect are types of Contents. Each Transform can have, at most, one attached Content. A Content inherits all of the attributes from its attached Transform.


  • A driver that implements the application-facing RPC interface for a class of drivers.

    Full description

    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.


  • The artifact containing Fuchsia APIs, Fuchsia tools, binaries, and metadata. Used to access the Fuchsia tools, or the Fuchsia APIs.


  • A private directory within which a component instance may store data local to the device.

    Full description

    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.


  • The ratio between the display's physical pixels and the display's device independent pixels.

    Full description

    The ratio between the display's physical pixels and the display's device independent pixels. Each logical or device independent pixel is displayed on screen by one or more physical pixels, as determined by this scale.


    Related links
  • A capability that bundles multiple capabilities together.

    Full description

    A capability that bundles multiple capabilities together. A dictionary is a key-value data collection, where the key is a capability name string and the value is a capability. The value itself may be another dictionary, which can be used to achieve directory-like nesting.


    Related links
  • A capability that permits access to a filesystem directory by adding it to the namespace of the component instance that uses it.

    Full description

    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.


    Related links
  • A dispatcher is an interface for scheduling asynchronous operations.

    Full description

    A dispatcher, when assigned to a driver, coordinates and performs asynchronous operations for the driver. A dispatcher mainly handles two tasks: it schedules asynchronous work to run on threads in a driver host and it actually runs the work on those threads on behalf of a driver.


    Related links
  • The corresponding class or data type in a target language (such as C++) used to represent a FIDL type. A domain object usually models an entity in a problem domain space.


  • A driver is a dynamic shared library that enables and controls one or more nodes.

    Full description

    A driver is a dynamic shared library that enables and controls one or more nodes. Drivers are loaded into driver hosts by the driver manager.


    Related links
  • The process where a driver is matched to a node, started, and then handed the node’s resources.

    Full description

    The process where a driver is matched to a node, started, and then handed the node’s resources. A driver bound to a node can access the node's resources and create child nodes.


    Related links
  • A process containing one or more device drivers.

    Full description

    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 index is a Fuchsia component that is responsible for keeping track of all available drivers.


  • The Driver Manager (formerly devmgr or devcoordinator) is responsible for enumerating, loading, and managing the life cycle of device drivers.


  • The process where the Driver Framework finds a driver and assigns it to a node. A driver that’s assigned to the node is considered as a matched driver.


    Related links
  • The driver runtime is an in-process runtime modeled after the Zircon kernel that enables colocated drivers to communicate with each other locally. It is much more efficient than communicating using Zircon channels.

    Full description

    The driver runtime is an in-process runtime modeled after the Zircon kernel that enables colocated drivers to communicate with each other locally. It is much more efficient than communicating using Zircon channels. It also provides a set of primitives mirroring Zircon kernel objects and a threading model for drivers which allows for the sharing of Zircon threads.


    Related links
  • The driver transport is a transport system in FIDL that's implemented on top of channels.


    Related links
  • A container for a set of components.

    Full description

    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.


  • A driver that is not included in the board configuration. These drivers are loaded from the universe package set<> at runtime.


  • Graphics library for compositing user interface content.

    Full description

    Graphics library for compositing user interface content. Its design is inspired by modern real-time and physically based rendering techniques though Fuchsia anticipates most of the content it renders to have non-realistic or stylized qualities suitable for user interfaces.


  • The artifact containing experimental Fuchsia APIs.


  • A keyword for a component instance to indicate that it is making a capability available to its parent to route.

    Full description

    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.


    Related links
  • A file system directory that contains the set of exposed capabilities for a component.

    Full description

    A file system directory provided by component manager that contains the set of capabilities exposed by a component to its parent.


    Related links
  • The Fuchsia Archive Format is a container for files to be used by Zircon and Fuchsia.


    Related links
  • FBL is the Fuchsia Base Library, which is shared between kernel and userspace.


    Related links
  • The Fuchsia driver framework is the documentation, APIs, and ABIs necessary to build Zircon device drivers.

    Full description

    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.


    Related links
  • The core Fuchsia method for talking about files and other I/O primitives are FIDL protocols over Zircon channels.

    Full description

    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. Sometimes referred to as "POSIX Lite".


    Related links
  • Fuchsia's primary tool for working with a Fuchsia system and Fuchsia tools. Example use cases include stream logs from a device and start an emulator.


    Related links
  • Fuchsia Host Objects is a set of APIs connecting `ffx` with subtools.

    Full description

    Fuchsia Host Objects is a set of APIs connecting `ffx` with subtools. It acts as a compatibility layer between the program and a device or virtual machine running Fuchsia, allowing the tool to ignore all the setup necessary to connect to the device, establish FIDL channels to services on the device, and log useful information about the interactions.


    Related links
  • A solid color rectangle can be attached to a Transform in Flatland.

    Full description

    A solid color rectangle can be attached to a Transform in Flatland. FilledRect is type of a Content.


  • The Fuchsia Interface Definition Language (FIDL) is a language for defining protocols.

    Full description

    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.


    Related links
  • A FIDL protocol that allows sending 2D graphical content to Scenic.

    Full description

    The 2D composition API for Fuchsia graphics clients. Flatland clients can construct their scene graph and send to Scenic to compose into the shared scene graph that is submitted to the display.


  • A fragment is a node that composes a Driver Framework v1 composite node. Each fragment binds to a fragment driver which provides protocols and metadata to the composite node. Only used in Driver Framework v1.


    Related links
  • Deprecated, replaced by RFC. An FTP is the way developers can suggest changes to FIDL.

    Full description

    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.


    Related links
  • The Fuchsia API Surface is the combination of the Fuchsia system interface and the client libraries included in the Fuchsia IDK.


  • The Fuchsia emulator (FEMU) is the default emulator for Fuchsia.

    Full description

    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.


    Related links
  • A scheme that refers to a repository, a package, or a package resource.

    Full description

    A scheme that refers to a repository, a package, or a package resource. The syntax is fuchsia-pkg://[/][#]]`. For example, for the component test_manager.cm published under the package test_manager's meta directory, from the fuchsia.com repository, its URL is fuchsia-pkg://fuchsia.com/test_manager#meta/test_manager.cm.


    Related links
  • An extension for Visual Studio Code (VsCode) supporting common developer workflows for Fuchsia, like environment set up, editing, debugging, and testing.


    Related links
  • The Fuchsia IDK contains a small set of libraries and tools required to start building and running programs that target Fuchsia. The contents of the IDK represent the most basic contract that the Fuchsia platform developers offer to prospective developers.


  • Set of deliverables from the Fuchsia Authors that make it easier to develop components against Fuchsia. Some artifacts include: Fuchsia SDK, Fuchsia tools, components, and editor extensions.


  • The Fuchsia SDK is the set of APIs, tools, build system integrations, and language integration artifacts produced by Fuchsia that enable the production of software and products for and with Fuchsia.


  • An integration of the Bazel build system with the Fuchsia SDK. Enables developers to compile, run, and test their software with Bazel. Supports C++ through a bundled Clang toolchain.


  • The binary interface that the Fuchsia operating system presents to software it runs.

    Full description

    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.


    Related links
  • Programs designed to help work with Fuchsia. For example, tools to compile FIDL IDL (interactive data language), or tools to get logs from a device.


  • Fuchsia Volume Manager (FVM) is a partition manager providing dynamically allocated groups of blocks known as slices into a virtual block address space.

    Full description

    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.


    Related links
  • The common name for the keys F1, F2, F3, ...

    Full description

    The common name for the keys F1, F2, F3, ...


  • GN is a meta-build system that generates build files.

    Full description

    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 repository.


    Related links
  • A FIDL protocol that organizes and presents graphical views.

    Full description

    A FIDL protocol that 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 GraphicalPresenter.


    Related links
  • A Handle is how a userspace process refers to a kernel object.

    Full description

    A Handle is how a userspace process refers to a kernel object. They can be passed to other processes over channels.


    Related links
  • A driver that controls a device.

    Full description

    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.


  • A bitmap containing pixels that can be attached to a Transform in Flatland.

    Full description

    A bitmap containing pixels that can be attached to a Transform in Flatland. Image is type of a Content.


  • This configuration file that tells the Software Assembly tooling which images to generate and how to generate them.

    Full description

    The Images Config is an internal contract between the two subsystems of Software Assembly -- Product Assembly and Image Assembly. The structure and contents of this file is subject to rapid iteration, as it is consumed only by the Software Assembly team.


    Related links
  • Relating to or describing an action to be performed inside a Fuchsia checkout.

    Full description

    For instance, checking out the Fuchsia source code is a prerequisite for performing any in-tree development. The `fx build` command is used to operate the in-tree build system.


    Related links

  • Software for sophisticated text input.

    Full description

    From MSDN: "A software component that enables a user to input text in a language that can not be represented easily on a standard keyboard."


    Related links
    • Input Method Editor API

  • API to implement IMEs

    Full description

    A FIDL API offered by the keyboard subsystem for integrating with built-in or custom made input method editors.


    Related links
    • Input Method Editor

  • Fuchsia system component for handling input-related events.

    Full description

    A library and component for processing of input-related events on Fuchsia in a sequential manner. The input pipeline mediates between driver-level input and "UI Framework" facing services. One of the input pipeline's tasks is to apply a keymap by attaching a key meaning to a key event.


    Related links
    • key event
    • key meaning
    • keymap
    • RFC-0096

  • A Rust trait in the input pipeline client library.

    Full description

    Represents a connection to a physical input device (e.g. mouse, keyboard) in an input pipeline. An InputDeviceBinding does the following:

    The input pipeline creates and owns InputDeviceBinding`s as new input peripherals are connected to a device.


    Related links

  • Describes the ranges of values a particular input device can generate.

    Full description

    A property of the Rust struct InputReport of type enum InputDeviceDescriptor and a FIDL table. For example, a InputDeviceDescriptor contains the keys available on the keyboard, and a InputDeviceDescriptor::Touch contains the maximum number of touch contacts and the range of x- and y- values each contact can take on.


    Related links
  • Represents an input event from an input device.

    Full description

    A property of the Rust struct InputEvent. InputDeviceEvent`s contain more context than the raw InputReport`s they are parsed from. For example, InputDeviceEvent::Keyboard contains all the pressed keys, as well as the key's phase (pressed, released, etc.).


    Related links

  • An event from an input device containing context (a InputDeviceDescriptor and state (e.g. phase and location of a button press). The input pipeline generates InputEvent`s from hardware signals.

    Full description

    A Rust struct in the input pipeline client library.


    Related links

  • Represents a client of InputEvent in an input pipeline. When an InputHandler receives an InputEvent, it does at least one of the following:

    Full description

    A Rust trait in the input pipeline client library.


    Related links

  • A stateless representation of an event from a physical input device.

    Full description

    A FIDL struct. Zircon generates InputReport`s from HID Reports.


    Related links
  • Jiri is a tool for multi-repo development.

    Full description

    It is used to checkout the Fuchsia codebase. It supports various subcommands, which makes it easy for developers to manage their local checkouts.


    Related links
  • A kernel object that groups a set of related processes, their child processes, and their jobs (if any).

    Full description

    Every process in the system belongs to a job and all jobs form a single rooted tree.


    Related links
  • 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.

    Full description

    Userspace can only reference kernel objects through handles.


    Related links
  • A switch that can be pressed or released.

    Full description

    A switch that can be pressed or released. Usually, but not always, it has a keycap with one or more symbols written on it. It is traditionally a mechanical, or electromechanical device, but modern input modes have seen purely software key implementations, as a user-interface element coupled with a touch-screen, or a computer mouse for actuation. ISO/IEC 9995-1:2009 does not explicitly define the term key, but notes that a keyboard has keys that can be actuated. We will use the term physical key to emphasize a key on a physical keyboard where otherwise confusion would arise.


    Related links
    • keyboard
    • keycap
    • physical key

  • Physical action to cause a key effect.

    Full description

    Doing something to a key to cause a key effect. For example, pressing a key. Actuation is probably a better term to use in general, since while each press is an actuation, not every key actuation has to be a key press. Some keys may be actuated by a tap, or a throw switch, or a twist etc. It's OK to use "key press" when talking about pressable keys in the narrow sense - such as on a standard PC keyboard. Prefer "key actuation" in formal contexts, or where precision is important.


    Related links
    • Physical key
    • Key effect

  • A key chord and its key effect, together.

    Full description

    A pair of a key chord and a key effect. For example pressing "Ctrl+O" causes the "Open File" dialog box to be shown.


    Related links
    • Key actuation
    • Key chord
    • Key effect

  • A message that reports a state change for a key.

    Full description

    A message reporting a state change associated with a single key. "Key 'A' has just been pressed" is a representation of a key event. On Fuchsia, a key event can only ever be delivered to a View that is in focus. This feature ensures that potentially sensitive keyboard input is always delivered only to the View that is permitted to receive it.


    Related links
    • Keyboard
    • Physical key
    • View

  • One or more simultaneous key actuations.

    Full description

    One or more key actuations that happen at the same time. It may be impossible to actuate a specific key chord without actuating other key chords first. For example, on mechanical keyboards, "Ctrl+Alt+Del" can not be actuated until at least one of "Ctrl", or "Alt" or "Del" is actuated first, as it is physically impossible to press all the three keys at the same time. This is not a universal definition, so expect variations across time periods, operating systems, and schools of thought. For example, KDE uses the term "chord" to mean "key sequence". But this usage seems unusual and not intuitive, as it deviates from the use of "chord" in music, so we don't follow this precedent and recommend against following it.


    Related links
    • Physical key

  • The final destination for the events generated by the keyboard subsystem.

    Full description

    A client that is the final destination for the events generated by the keyboard subsystem. Prefer the term consumer to client, since the keyboard subsystem has multiple collaborators, each of which can be a client in the context of a particular 1:1 collaboration.


    Related links
    • key event
    • keyboard subsystem

  • Effect that results when a key is actuated.

    Full description

    "Effect that results when a key is actuated, depending on the active level, and possibly by the concurrent operation of a qualifier key or keys." (ISO/IEC 9995-1:2009, section 4) Example: the letter "a" appearing on a screen is a key effect, caused by an actuation of the key with the keycap "a" on the keyboard.


    Related links
    • key
    • keycap
    • keyboard

  • An API that provides discrete key events.

    Full description

    E.g. fuchsia.ui.input3. API that gives access to discrete key events, possibly annotated with information about the currently applicable keyboard layout. At this stage, events corresponding to button presses have not yet been interpreted as language. May be used for limited use-cases such as controlling a game, but most clients should prefer the text edit API.


    Related links
    • Text Edit API

  • An encoding corresponding to the meaning a key event has to the key consumer, with all layout and other mappings that apply.

    Full description

    An encoding corresponding to the meaning a key event has to the key consumer, with all layout and other mappings that apply.


  • A sequence of key chords.

    Full description

    A sequence of key chords. Example: in Emacs, pressing C-x followed by C-s saves the current buffer. Since a single key actuation is a key chord (see definition above), every sequence of single key presses such as "hello world" is also a key sequence.


  • A means for input of information by a human being.

    Full description

    An "[...] intermediate element between a user and an information processing system. The keyboard is specifically intended as a means for input of information by a human being." (ISO/IEC 9995-1:2009, section 5). This link has some examples of computer keyboards.


    Related links
    • physical keyboard
    • virtual keyboard

  • The set of Fuchsia system services that process keyboard and text related input.

    Full description

    The set of Fuchsia system services that process keyboard and text related input.


    Related links
    • Keyboard
    • key event

  • A map that transforms a sequence of physical keys into a key meaning.

    Full description

    A map that transforms a sequence of physical keys into a key meaning. Also known as keymap, or keyboard layout.


  • A special kind of key binding.

    Full description

    A key chord that appears in some key binding. All keyboard shortcuts are chords, but only chords that have a key effect associated with them are shortcuts. On Fuchsia, a distinctive feature of shortcuts is that they can be routed to Views that are not in focus. This allows top-level Views such as the graphical shell, or Accessibility, to install system-wide shortcuts and intercept them instead of yielding them over to child views. Contrast to the behavior of key events, which are only ever delivered to focused views.


  • The symbol displayed on top of a key.

    Full description

    The symbol that is displayed on a key of the physical keyboard, or on the UI item representing a virtual keyboard button that acts as a key. The user's expectation is that actuating a key with a specific symbol on the keycap would, by default, cause that symbol to be communicated to the computer.


    Related links
    • Physical key
    • Keyboard
    • Key meaning

  • A Kernel Object Identifier.


    Related links
  • The "Legacy AIB" is an AIB that includes both platform and product artifacts that are specified via the GN build arguments such as base_product_labels and bootfs_labels.

    Full description

    The Legacy Assembly Input Bundle (LAIB) is an AIB that includes both platform and product artifacts that are specified via the GN build arguments such as base_product_labels and bootfs_labels. Eventually, all the contents of the Legacy AIB will be migrated to platform AIBs or the Assembly Config, and it will be deleted entirely. As of November 2022 (last time this definition was updated), Software Assembly is not feature-complete, and products have not been fully migrated over to using Software Assembly. Many of the current platform features and product code lack the support in Assembly to define them inside the Assembly Config, therefore we invented a temporary solution.


    Related links
  • View's device independent pixels.

    Full description

    View's device independent pixels. This affects the content layout. Each pixel is displayed on-screen by one or more physical pixels, as determined by device pixel ratio.


    Related links
  • Caps lock, num lock, fn lock, scroll lock

    Full description

    A "state set by actuating a lock key, singly or in combination with a [modifier] key". (ISO/IEC 9995-1:2009, section 4.5) Example lock state keys on PC keyboards are: CapsLock, NumLock, FnLock, ScrollLock.


  • Little Kernel (LK) is the embedded kernel that formed the core of the Zircon Kernel.

    Full description

    LK is more microcontroller-centric and lacks support for MMUs, userspace, system calls -- features that Zircon added.


    Related links
  • Underlined character in a menu option.

    Full description

    The underlined character in a menu (Wikipedia). For example, the "F" in "File" which is accessed by pressing "Alt+F". Mnemonics are localized. For example, the "File" menu in an English version of a program has "F" as the mnemonic, so "Alt+F" would be used to access. The Dutch version of the same program would have "Bestanden" as the title of that very same menu, so "Alt+B" would be used for access. Mnemonics differ from shortcuts: in an application an "Open" command could have "O" as mnemonic, but Ctrl+F12 as a shortcut.


  • A key that modifies the effect of other keys.

    Full description

    A "key whose operation has no immediate effect, but which, for as long as it is actuated, modifies the effects of other keys. A modifier key can be, for example, [...] a control key." (ISO/IEC 9995-1:2009, section 4.17)


  • Identifies a specific component instance in the component tree using a topological path.

    Full description

    A component's moniker is defined as a path to the component instance in the component instance tree.


    Related links
  • Fuchsia's standard C library (libc) is based on Musl Libc.


    Related links
  • A namespace is the composite hierarchy of files, directories, sockets, services, and other named objects offered to components by their environment.


    Related links
  • An implementation of TCP, UDP, IP, and related networking protocols for Fuchsia.


  • The build system executing Fuchsia builds.

    Full description

    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.


    Related links
  • An entity in the Driver Framework that contains a set of resources that a driver can interact with and a set of properties. A node can be thought of as a hardware or virtual device, or a node can be a part of a hardware device.


    Related links
  • Node properties are key-value pairs contained in nodes. They are used by bind rules to evaluate whether a driver is matched to the node.

    Full description

    Node properties are key-value pairs contained in nodes. They are used by bind rules to evaluate whether a driver is matched to the node.The keys can be of integer or string type. The values can be of integer, string, boolean, or enum type.


    Related links
  • The node topology describes the parent-child relationships between nodes in a Fuchsia system. These nodes form a single node topology, expressed in a directed acyclic graph.


    Related links
  • A keyword for a component instance to route a capability that was exposed to it.

    Full description

    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).


    Related links
  • Relating to or describing an action that can be done outside of a Fuchsia checkout.

    Full description

    For instance, the IDK allows developing for Fuchsia outside the Fuchsia tree. The SDK tools are available as prebuilts so developers don't need to check out Fuchsia code and build the same tools from source code using Fuchsia's in-tree build system.


    Related links

  • A file system directory where a component serves protocol handles to capabilities it has exposed.

    Full description

    A file system directory where a component serves protocol handles to capabilities it has exposed. Other components connect to these exposed capabilities using the handles in this directory.


    Related links
  • Over-the-air update.

    Full description

    Over-the-air updates are changes made to device software (generally the full system, but possibly smaller modules as well) without re-initializing the device's disk via a pave or flash.


    Related links
  • A unit of software distribution in Fuchsia.

    Full description

    A unit of software distribution in Fuchsia. 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 URL. Packages can contain other packages (known as Subpackages).


    Related links
  • Also known as the Fully-Qualified Package URL, a url with the "fuchsia-pkg" scheme (fuchsia-pkg:///) representing a fully qualified location for a fuchsia package. For example: fuchsia-pkg://fuchsia.com/package_name
    Related links
  • A package URL with a URL parameter "hash" with value that is the merkle hash of the package's meta.far (fuchsia-pkg:///?hash=). Pinning a package is the act of uniquely identifying a version of a package, through the hash URL parameter. For example: fuchsia-pkg://fuchsia.com/package_name?hash=716178364a3a0fc8be2850f88a7414f95ed895489bc0f74bc2d60d78d3682c65
    Related links
  • A parent component instance is a component instance that owns other instances called child component instances


    Related links
  • A driver that provides resources from its node to its child nodes.


    Related links
  • A tool in Zircon that installs partition images to internal storage of a device.


    Related links
  • A physical device for text entry.

    Full description

    A physical device for text entry, which relies on an arrangement of keys.


    Related links
    • physical key
    • keycap
    • key effect

  • A positioning of keycaps on a physical keyboard.

    Full description

    A positioning of keycaps on a physical keyboard.


    Related links
    • keycap
    • physical keyboard

  • The numeric code associated with a key, as assigned by Fuchsia.

    Full description

    The numeric code associated with a key, as assigned by the operating system. In Fuchsia, the physical key codes are unsigned 32-bit integers, derived from the USB HID usage tables. The USB HID usage page number is encoded in the upper 16 bits, and the usage ID within a page is encoded in the lower 16 bits. An encoding of a physical key code used in Fuchsia: see input.Key.


    Related links
    • Physical key
    • Scan code

  • Display's physical pixel count.

    Full description

    Display's physical pixel count. i.e. if there are 4K and FHD variants of the same size display, 4K has 3840x2160 physical pixels and FHD has 1920x1080 physical pixels. However, they may have the same amount of logical pixels so the layout of the content looks the same.


    Related links
  • A process KOID. A KOID that uniquely identifies a process object.


    Related links
  • The platform is the common foundation for products built using Fuchsia.

    Full description

    Products built using Fuchsia share a common foundation, which is the underlying Fuchsia platform. The platform consists of (a) the core system, including the Zircon kernel, component framework, driver framework, and software delivery subsystem, (b) services that let components share hardware resources, including the connectivity, graphics, media, and local storage subsystems, and (c) widely used components, including the web runtime, POSIX compatibility layers, and diagnostics. Not every product uses every aspect of the platform. For example, products without displays do not use the graphics subsystem. The platform has a versioned, stable binary interface, which developers can target using the Fuchsia SDK.


    Related links
  • A node added by the board driver to the platform bus.


    Related links
  • The first driver loaded in Fuchsia. The platform bus is the root driver and contains all the resources and privileges necessary to interact with hardware.


    Related links
  • The open source code hosted on fuchsia.googlesource.com, which comprises the source code for Fuchsia.

    Full description

    A given Fuchsia system can include additional software from outside the platform source tree by adding the appropriate Fuchsia package.


  • A specification for an assembled system.

    Full description

    For instance, the Fuchsia platform defines products such as `bringup` and `core` in terms of build-time configuration values and a set of packages to assemble into a system image.


    Related links
  • The set of artifacts representing a Fuchsia product which are needed to emulate, flash, boot, or update the product on a Fuchsia target.

    Full description

    A Product Bundle contains all the images required for an A/B/R Fuchsia target. Artifacts include, but are not limited to, the product image and packages associated with it.


    Related links
  • Whoever defines a product, and is responsible for its provenance and releases.


    Related links
  • 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.

    Full description

    Every process is contained in a job.


    Related links
  • In FIDL, a protocol groups methods and events to describe how one process interacts with another.

    Full description

    In the component runtime, protocols are routed to and used by other components as protocol capabilities.


    Related links
  • A capability that permits communicating with a protocol over a channel using a specified FIDL protocol.

    Full description

    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.


    Related links
  • A subtree of component instances in the component instance tree. Acts as a container for component instances and capabilities in the subtree.


    Related links
  • Resources are contained in nodes and are used by drivers for communication. There are multiple types of resources, including but not limited to: IPC, kernel, memory map, and I/O.


  • A roller is an infrastructure job that watches for updates to a repository's pinned dependencies and automatically creates and submits a commit that updates the pinned version (a "roll") when it detects that a new version of a dependency is available.

    Full description

    The Fuchsia project uses rollers to update pinned versions of repositories and CIPD packages. Rollers can be configured to trigger automatically on new commits to a repository, run as a cron job that periodically polls for changes, or only be triggered manually.


  • The root of the job tree and the first job in the system.

    Full description

    The root job is created by the kernel to allow [userboot](/docs/glossary#userboot) to begin execution.


    Related links
  • A component that provides a runtime environment for other components, e.g. the ELF runner, the GTest runner.

    Full description

    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 thecomponent when requested by the component framework.


    Related links
  • A sequence of numeric values associated with a key.

    Full description

    A sequence of numeric values associated with a key, as assigned by the hardware controller of the physical keyboard. While standardized scan codes exist, keyboards are varied enough that operating systems usually have to map all scan code sequences into a single space of physical key codes.


    Related links
    • key
    • physical keyboard

  • Scenic is Fuchsia's system compositor, which composes graphical objects from multiple components into a shared scene graph.

    Full description

    Scenic includes views, input, compositor, and GPU services.


    Related links
  • A subset of files in the SDK.

    Full description

    An *SDK Atom* is a collection of files that can be included in an SDK. Fuchsia represents SDK Atoms using the sdk_atom template in GN.


  • A hardware driver that will only service a single request at a time. The core driver synchronizes and serializes all requests.


  • In FIDL, a service groups protocols to describe how one process interacts with another.

    Full description

    A service is used and routed to other components as a service capability.


    Related links
  • A capability that permits communicating with a service over a channel using a specified FIDL service.

    Full description

    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.


    Related links
  • A session component is a component that encapsulates a product's user experience and runs as a child of the platform `session_manager` component.

    Full description

    A "session component" is a component. Each Fuchsia product encapsulates its user experience within a session component (and its descendent components). The term "user experience" is used broadly: it encompasses traditional graphical experiences with touch/mouse/keyboard interaction, as well as simpler experiences with a single RGB LED and several hardware buttons, or those with only network I/O. Simple products may specify a session component with no children, while complex products have many children of the session component.


    Related links
  • A FIDL protocol, exposed by the session manager, used to start or restart sessions.

    Full description

    It is available to developer tools such as session_control to control session components at runtime.


    Related links
  • The platform component that manages the lifecycle of the session component.

    Full description

    The session manager defines the set of system capabilities provided to sessions at runtime.


    Related links

  • The process of gathering compiled artifacts, configuration metadata, and other information required to create a complete Product Bundle.

    Full description

    The Software Assembly process is carried out by an ffx plugin which gathers various targets declared in the Assembly Config, Legacy AIB, and Platform AIBs. The result of Software Assembly is a Product Bundle.


    Related links
  • A runner that allows for running unmodified Linux binaries on Fuchsia.

    Full description

    A runner that allows for running unmodified Linux binaries on Fuchsia. Linux binaries are not run inside a virtual machine. Instead, starnix creates a compatible runtime environment by implementing the Linux UAPI.


    Related links
  • A storage capability is a capability that allocates per-component isolated storage for a designated purpose within a filesystem directory.

    Full description

    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:


    Related links
  • A sub-realm is the realm corresponding to a child component instance.


    Related links
  • A Fuchsia package contained (by reference) in another package.

    Full description

    A Fuchsia package can declare dependencies on one or more packages, by containment. The containing package is sometimes referred to as the superpackage and the contained packages are its subpackages. Subpackages are declared by reference, but the existence of the superpackage implies the existence of its subpackages, regardless of the medium (including a Fuchsia runtime, in a package repository, or in a package archive format, for example). Packages and Components can reference contained packages and subpackaged components, respectively, by relative subpackage URLs.


    Related links
  • A partial Fuchsia Package URL, starting from the URI path.

    Full description

    A relative subpackage URL requires a "resolution context", which simply means a known starting package (or "superpackage"). The path (a single path segment with no slashes: `/`) refers to a subpackage, declared and named by its superpackage; for example: my-package#meta/comp.cm, representing a component within a subpackage, with the locally-scoped name "my-package".


    Related links
  • An async dispatcher where posted tasks are run in order, and each task will observe the side-effects from previous tasks.


    Related links
  • An API that allows editing a UI text field.

    Full description

    E.g. fuchsia.ui.text. This API allows the platform to access and edit the contents of a text field implemented by a UI Framework. This type of editing is a requirement for most text manipulation, in particular when the text is interpreted as human language rather than discrete button events. This API is required for accented characters (anything using a dead key) and most CJK languages.


    Related links
    • Key Event API

  • A kernel object that represents a time-shared CPU execution context. Each thread is contained in process.


    Related links
  • A hierarchical piece of a Flatland graph.

    Full description

    A hierarchical piece of a Flatland graph. Transform is the fundamental object used to organize a Flatland graph. Transforms can have children Transforms and can attach a Content.


  • Tools used by developers to compile sources into binaries. Fuchsia supports Clang for C/C++.


  • Top-Of-Tree: The source tree (or build artifact thereof) based on the most recent commit to the main development branch of the source code.

    Full description

    Top-Of-Tree (or Tip-of-Tree, both are used interchangeably) refers to various artifacts, depending on context. The common denominator is that the artifact of interest is not relating to a stabilizing branch like releases/f18. Frequent examples:

    • A Fuchsia git checkout sync'ed to JIRI_HEAD.
    • The resulting artifacts from a build from a Fuchsia git checkout sync'ed to JIRI_HEAD.
    • The resulting artifacts from a component built from the development HEAD of a component, against an unspecified version of the Fuchsia SDK.


  • An ephemeral driver from a specific Fuchsia package set that is registered manually after the system's initial boot.


  • A keyword for a component instance to consume a capability that was offered to it.

    Full description

    A component instance may use the use manifest keyword to to consume a capability that was offered to it by its parent.


    Related links
  • The first process started by the Zircon kernel.

    Full description

    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.


    Related links
  • A region of the Scenic scene graph and the reference frame of a Scenic client.

    Full description

    The region a Scenic client can draw in, and the coordinate system input events are delivered in. Views can be referred to cross-process by their associated ViewRef.


    Related links
  • The parent endpoint of two connected Flatland instances.

    Full description

    The parent endpoint of two connected Flatland instances. View is the child endpoint. Viewport is type of a Content.


  • Uniquely identifies the parent connection point of a connection between two Flatland instances.

    Full description

    Uniquely identifies the parent connection point of a connection between two Flatland instances. There is only one ViewCreationToken associated with a ViewportCreationToken.


  • Represents a handle to a remote View that was launched by calling PresentView() on a GraphicalPresenter.

    Full description

    A FIDL protocol. With this handle, the caller (often, the session) can control the View's lifecycle. Closing the ViewController should close the presented view, and allow the system to reclaim its resources.


    Related links
  • Uniquely identifies the child connection point of a connection between two Flatland instances.

    Full description

    Uniquely identifies the child connection point of a connection between two Flatland instances. There is only one ViewportCreationToken associated with a ViewCreationToken.


  • Uniquely identifies an attachment point for a view in the global scene graph.

    Full description

    A FIDL struct. Each ViewHolderToken has exactly one corresponding ViewToken.


    Related links
  • A handle to a kernel object that identifies a unique View across the system.

    Full description

    A FIDL struct. Two ViewRef`s to the same view have the same KOID. During cross-process communications Scenic clients are referred to by ViewRef. This is common for Input, Accessibility and Focus.


    Related links
  • A description of a view to be presented by a GraphicalPresenter.

    Full description

    A FIDL table.


    Related links
  • Uniquely identifies a View, which is the root point for a subgraph in the global scene graph.

    Full description

    A FIDL struct. Each ViewToken has exactly one corresponding ViewHolderToken.


    Related links
  • The Virtual Dynamic Shared Object (vDSO) is a Virtual Shared Library.

    Full description

    It is provided by the Zircon kernel and does not appear in the filesystem or a package. It provides the Zircon System Call API and 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.


  • A keyboard represented with software.

    Full description

    While traditionally a keyboard is a mechanical or electromechanical device, modern keyboards can be visual elements on a screen, or can use voice dictation for example. Also called on-screen keyboard (OSK). [wikipedia]


    Related links
    • keyboard
    • physical keyboard

  • 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.


    Related links
  • 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.


    Related links
  • Zircon is the kernel and lowest level userspace components (driver runtime environment, core drivers, libc, etc) at the core of Fuchsia.

    Full description

    In a traditional monolithic kernel, many of the userspace components of Zircon would be part of the kernel itself.


    Related links
  • A Zircon Boot Image (ZBI) contains everything needed during the boot process before any drivers are working.

    Full description

    This includes the kernel image and a RAM disk for the boot filesystem.


    Related links
  • A recovery image that is used to install and boot a full Fuchsia system.

    Full description

    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.


  • An abbreviation of Zircon used in Zircon C APIs and ABIs zx_channel_create(), zx_handle_t, ZX_EVENT_SIGNALED, etc) and libraries (libzx in particular).


  • The native low-level system debugger.


    Related links