Components are the foundational building blocks of software running in Fuchsia. Each component is a composable, sandboxed module that interacts with other components through capabilities. This promotes system security and creates clear interfaces between individual components, making them easier to update or replace.
In Fuchsia, everything is a component (almost). Recall from the previous discussion of Zircon that the surface area of the kernel is intentionally small, with most core services being implemented in user space. This means that most software running on Fuchsia is implemented using the component framework, including:
- User-facing applications
- Device drivers
- Media codecs
- Network stacks
Outside the kernel there are only a few low-level exceptions not using the
component framework, such as bootloaders and the
The heart of the component framework is the component manager. It is responsible for coordinating the execution of all component instances, providing them with their capabilities, and intermediating connections between components.
Components can be launched explicitly (from a URL, for example) or implicitly from a request for a particular capability. Component manager performs the necessary resolution to determine whether to launch a new component or route the request to an existing instance. For this routing to take place, every component must declare any capabilities that it provides to the system and any it consumes.
Component manager parses each component's declaration to determine how to run the component and supply the necessary capabilities. Components are typically declared to the system through a component manifest file within the component's package.
Below is a simple example of a component manifest that describes an ELF executable with some additional command arguments:
args: [ "Hello", "World!" ],
Notice the runtime declaration telling the component manager that this component requires the ELF runner. This is an example of a capability!
Components obtain privileges to access various parts of the wider system through capabilities. Each component can declare new capabilities that they offer to the system and capabilities provided by other components (or the framework) that they require to function.
As you just saw,
runner is an example of a capability declaring the runtime
used by the component. Other examples of common capability types are
directory to access filesystem resources and
protocol for communicating
with other components.
Developers declare the capability types required by the component using the
component manifest. Below is an example of a component manifest requesting
two capabilities: read access to an
example-data directory and a service
described by the
fuchsia.example.Foo FIDL protocol.
rights: [ "r*" ],
Component manager uses the capability declarations to populate each component's
namespace with the necessary directory handles. For this example, the component
/svc/fuchsia.example.Foo in their namespace.
All components in the system are composed into a single rooted component instance tree. This tree structure governs several important aspects of component behavior.
Parent components in the tree are responsible for creating instances of other components as their children and providing them with the necessary capabilities. At the same time, child components can expose capabilities back to the parent. Child components can be created one of two ways:
- Statically: The parent declares the existence of the child in its own component declaration.
- Dynamically: The parent adds the child to a component collection at
runtime using the
Any parent component and all its children form a group within the tree called
a realm. Realms enable a parent to control which capabilities flow into
and out of its sub-tree of components, creating a capability boundary.
Components decide whether to export capabilities outside their realm using the
Once a capability is exposed to the realm, the parent can share it with other
components within the same realm. This is done using the
Component manager is responsible for resolving requests to access a capability (such as a directory or protocol) with the component providing that capability. This is known as capability routing. Component Manager can only resolve capabilities that are exposed and offered within the same realm.
In this exercise, you'll explore the component instance tree and look in detail at capability routing in action using some core system components.
Start the emulator
If you do not already have an instance running, start the emulator:
ffx emu start --headless
When startup is complete, the emulator prints the following message and returns:
Logging to "$HOME/.local/share/Fuchsia/ffx/emu/instances/fuchsia-emulator/emulator.log"
Waiting for Fuchsia to start (up to 60 seconds)........
Emulator is ready.
Explore system components
Open another terminal window and use the
component list command to dump the
system's component tree:
ffx component list
You should see output similar to the (truncated) list below:
This list represents the component instance tree, with organizational
startup forming sub-trees
underneath the root.
component show command provides more details about each component.
Use this command to see the details of
http-client — a component that provides
an HTTP request service:
ffx component show http-client.cm
The command outputs the following report:
Type: CML static component
Component State: Resolved
Incoming Capabilities: config
Exposed Capabilities: fuchsia.net.http.Loader
Merkle root: d9e73f5b061f2f227e596e2e0079ff3a095fc69e192cf85e0d7621826c76356c
Execution State: Running
Start reason: '/core/feedback' requested capability 'fuchsia.net.http.Loader'
Running since: ...
Job ID: 41268
Process ID: 41311
Outgoing Capabilities: fuchsia.net.http.Loader
Notice a few of the details reported here:
- A unique identifier for the component instance (called a moniker).
- The package URL where this component was loaded from.
- The execution state of the component.
- The current job/process ID where the instance is running.
- A set of requested and exposed capabilities for the component.
Trace a capability route
In the previous output, there are three capability groups listed:
- Incoming Capabilities: Capabilities that the component declares with
use. These are provided to the component through its namespace.
- Outgoing Capabilities: Capabilities the component has published to its outgoing directory.
- Exposed Capabilities: Capabilities the component declares with
expose. These are the component's exposed services.
One of the capabilities exposed by
http-client to its parent realm is
This enables other components to issue HTTP requests.
component select command determine how many components interact with
ffx component capability fuchsia.net.http.Loader
The command lists all the matching components:
This indicates that the
feedback components use this capability
(i.e., have it listed under Incoming Capabilities). The common ancestor
between these components is
core, which handles the routing of this capability
to the necessary children.