Glossary

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

Information related to ABR

• OTA

Guides related to ABR

• OTA updates

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

Information related to Assembly Config

• Product Owner

Information related to Assembly Input Bundle (AIB)

• Software Assembly

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.

Information related to Bind language

• Driver binding

Guides related to Bind language

• Driver binding
• Bind rules tutorial

Information related to Bind library

• Driver binding

Guides related to Bind library

• Driver binding
• Bind rules tutorial

Information related to Bind rules

• Driver binding

Guides related to Bind rules

• Driver binding
• Bind rules tutorial

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.

Information related to Board

• Board driver
• Boards
• RFC-0111: Initial Fuchsia hardware platform specifications

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.

Information related to Board driver

• Board
• //src/devices/board/drivers
• Platform Bus

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

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). 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). The Zircon Boot Image (ZBI) has limited space for such drivers, a constraint that does not generally apply to base drivers.

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.

Information related to Bringup

• Board
• Bringup Product Definition
• "Board" definition
• Install Fuchsia on a Khadas VIM3 board

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

Information related to Cache directory

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.

Information related to Capability

• Capability routing

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.

Information related to Capability routing

• Capability

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.

Information related to Channel

• Channel overview
• Update channel usage policy

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.

Information related to Child component instance

• Component
• Components

Information related to Child node

• Drivers and nodes

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.

Information related to CIPD

• CIPD source code
• CIPD web UI

Information related to colocate

• Driver framework (DFv2)

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.

Information related to Component

• Components

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

Information related to Component collection

• Components

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.

Information related to Component configuration

• Component Configuration
• Configuration Mechanisms

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

Information related to Component configuration data

• Component Configuration
• Configuration Mechanisms

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.

Information related to Component declaration

• Components

Information related to Component framework

• Components

Information related to Component instance

• Components

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.

Information related to Component instance tree

• Components

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.

Information related to Component manager

• Components

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.

Information related to Component manifest

• Component manifests

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.

Information related to Component manifest source

• Component manifests

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

Information related to Component manifest facet

• Component manifests

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.

Information related to Component instance identifier

• Components

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.

Information related to Component topology

• Components

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.

Information related to Component URL

• fuchsia-pkg URL

Information related to Composite driver

• Driver and nodes

Guides related to Composite driver

• Driver binding
• Bind rules tutorial

Information related to Composite node

• Driver and nodes

Information related to Composite node specification

• Composite nodes

Information related to Configuration Capability

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

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.

Information related to Device pixel ratio

• physical pixels
• logical pixels
• RFC-0174

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.

Information related to Dictionary

• dictionary

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.

Information related to Directory capability

• Capability

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.

Information related to Dispatcher

• Synchronized dispatcher

Guides related to Dispatcher

• Driver dispatcher and threads

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.

Information related to Driver

• Fuchsia driver development
• Driver source code
• Drivers and nodes

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.

Guides related to Driver binding

• Driver binding
• Bind rules tutorial

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.

Guides related to Driver matching

• Driver binding
• Bind rules tutorial

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.

Information related to Driver runtime

• Driver runtime

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 Fuchsia anticipates most of the content it renders to have non-realistic or stylized qualities suitable for user interfaces.

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.

Information related to expose

• Capability

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

Information related to Exposed directory

• Capability
• Outgoing directory

Information related to FAR

• Fuchsia archive format (FAR)

Information related to FBL

• C++ in Zircon

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.

Information related to FDF

• Fuchsia driver framework
• FDF includes

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

Information related to fdio

• fdio source code
• RFC-0082
• Life of an Open

Information related to ffx

• ffx

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.

Information related to FHO

• FHO

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

Guides related to FIDL

• FIDL

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.

Information related to Fragment

• Composite devices

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.

Information related to FTP

• FIDL
• Deprecated FTP process

Guides related to FTP

• Creating an RFC

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.

Information related to FEMU

• Fuchsia emulator (FEMU)

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.

Information related to fuchsia-pkg URL

• Fuchsia package URLs

Information related to Fuchsia extension for VS Code

• Installing the Fuchsia developer extension

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.

Information related to Fuchsia System Interface

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

Information related to Fuchsia Volume Manager

• Filesystems

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

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.

Information related to GN

• Language and operation
• Reference
• Fuchsia build overview

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.

Information related to GraphicalPresenter

• fuchsia.element.GraphicalPresenter

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

Information related to Handle

• Zircon Handle

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. Image is type of a Content.

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.

Guides related to Images Config

• Product and Image Assembly

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.

Information related to In-tree

Guides related to In-tree

• Get Fuchsia source code
• Build Fuchsia

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

Information related to Input Method Editor

• Input Method Editor API

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

Information related to Input Method Editor API

• Input Method Editor

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.

Information related to Input Pipeline

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

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

• Connects to an InputReport file located at /dev/class/input-report/XXX.
• Generates InputEvent's from the DeviceDescriptor and incoming inputReport.

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

Information related to InputDeviceBinding

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.

Information related to InputDeviceDescriptor

• enum InputDeviceDescriptor
• fuchsia.input.report.DeviceDescriptor

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

A Rust struct in the input pipeline client library.

Information related to InputEvent

A Rust trait in the input pipeline client library.

Information related to InputHandler

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

Information related to InputReport

• fuchsia.ui.InputReport

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

Information related to Jiri

• jiri reference
• jiri subcommands
• jiri behaviour
• jiri tips and tricks

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

Information related to Job

• Job
• Jobs
• Root job

Userspace can only reference kernel objects through handles.

Information related to Kernel object

• Kernel objects

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.

Information related to Key

• keyboard
• keycap
• physical key

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.

Information related to Key actuation

• Physical key
• Key effect

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

Information related to Key binding

• Key actuation
• Key chord
• Key effect

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.

Information related to Key event

• Keyboard
• Physical key
• View

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.

Information related to Key chord

• Physical key

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.

Information related to Key consumer

• key event
• keyboard subsystem

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

Information related to Key effect

• key
• keycap
• keyboard

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.

Information related to Key event API

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

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.

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.

Information related to Keyboard

• physical keyboard
• virtual keyboard

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

Information related to Keyboard subsystem

• Keyboard
• key event

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

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

Information related to Keycap symbol

• Physical key
• Keyboard
• Key meaning

Information related to KOID

• Kernel object

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.

Information related to Legacy Assembly Input Bundle

• Assembly Input Bundle (AIB)
• Assembly Config

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.

Information related to Logical pixels

• device pixel ratio
• logical pixels
• RFC-0174

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.

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

Information related to LK

• LK on Github

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

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

Information related to Moniker

• Monikers

Information related to Musl

• Source code
• Musl homepage

Information related to Namespace

• Fuchsia Namespaces

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.

Information related to Ninja

• Ninja rules in GN
• Fuchsia build overview/a>

• Ninja manual

Information related to Node

• Drivers and nodes

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.

Information related to Node properties

• Drivers and nodes
• Driver binding

Information related to Node topology

• Drivers and nodes

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

Information related to offer

• Capability

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.

Information related to Out-of-tree

Guides related to Out-of-tree

• Integrator Development Kit (IDK)
• SDK tools

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.

Information related to Outgoing directory

• Capability
• Exposed directory

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.

Guides related to OTA

• System OTA documentation

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

Information related to Package

• Fuchsia packages

Information related to Package URL (Absolute)

• fuchsia-pkg URL

Information related to Package URL (Pinned Absolute)

• fuchsia-pkg URL

Information related to Parent component instance

• Components

Information related to Parent driver

• Drivers and nodes

Guides related to Paver

• Guide for installing Fuchsia with paver

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

Information related to Physical keyboard

• physical key
• keycap
• key effect

A positioning of keycaps on a physical keyboard.

Information related to Physical keyboard layout

• keycap
• physical keyboard

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.

Information related to Physical keycode

• Physical key
• Scan code

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.

Information related to Physical pixels

• device pixel ratio
• logical pixels
• RFC-0174

Information related to PID

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.

Information related to Platform

• Product

Guides related to Platform device

• Platform Bus

Guides related to Platform bus

• Platform Bus

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

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.

Information related to Product

• Platform
• Package
• Product owner

Guides related to Product

• Bringup Product Definition

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.

Information related to Product Bundle

• Product
• Product Owner
• A/B/R

Guides related to Product Bundle

• Product and Image Assembly

Information related to Product Owner

• Package

Every process is contained in a job.

Information related to Process

• Process overview

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

Information related to Protocol

• Protocol capability

Guides related to Protocol

• FIDL protocols

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.

Information related to Protocol capability

• Capability routing

Guides related to Protocol capability

• Protocol capabilities

Information related to Realm

• Realms

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 job is created by the kernel to allow [userboot](/docs/glossary#userboot) to begin execution.

Information related to Root job

• Job
• Jobs

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.

Information related to Runner

• ELF runner
• Component runner

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.

Information related to Scan code

• key
• physical keyboard

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

Information related to Scenic

• Scenic concepts

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 service is used and routed to other components as a service capability.

Information related to Service

• Service capability

Guides related to Service

• FIDL services

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.

Information related to Service capability

• Capability routing

Guides related to Service capability

• Service capabilities

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.

Information related to Session component

• Component

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

Information related to Session launcher

• fuchsia.session.Launcher

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

Information related to Session manager

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.

Information related to Software Assembly

• Product Bundle
• Assembly Config
• Assembly Input Bundles (AIB)
• Legacy AIB

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.

Information related to Starnix

• starnix

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.

Information related to Storage capability

• Capability routing
• Storage capabilities

Information related to Sub-realm

• Realms

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.

Information related to Subpackage

• Package

Guides related to Subpackage

• Fuchsia Subpackages

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

Information related to Subpackage URL (Relative)

• Subpackage

Information related to Synchronized dispatcher

• Thread safe asynchronous code

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.

Information related to Text Edit API

• Key Event API

Information related to Thread

• Thread overview

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.

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.

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

Information related to use

• Capability

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.

Guides related to userboot

• Zircon kernel to userspace bootstrapping (userboot)

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.

Information related to View

• View System

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. There is only one ViewCreationToken associated with a ViewportCreationToken.

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.

Information related to ViewController

• fuchsia.element.ViewController

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

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

Information related to ViewHolderToken

• fuchsia.ui.views.ViewHolderToken

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.

Information related to ViewRef

• fuchsia.ui.views.ViewRef
• Scenic Views, view tree, and ViewRefs
• View focus

A FIDL table.

Information related to ViewSpec

• fuchsia.element.ViewSpec

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

Information related to ViewToken

• fuchsia.ui.views.ViewToken

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.

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]

Information related to Virtual Keyboard

• keyboard
• physical keyboard

Guides related to Virtual Memory Address Range

• VMAR overview

Information related to Virtual Memory Object

• VMO overview

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

Information related to Zircon

• Zircon documentation
• Zircon concepts
• Source code

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

Information related to Zircon Boot Image

• ZBI header file

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.

Guides related to ZXDB

• zxdb: The Fuchsia debugger