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
- Filesystems
- 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 userboot
process.
Component manager
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:
program: {
runner: "elf",
binary: "bin/hello",
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!
Component capabilities
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.
use: [
{
directory: "example-data",
rights: [ "r*" ],
path: "/example/data",
},
{
protocol: "fuchsia.example.Foo",
},
]
Component manager uses the capability declarations to populate each component's
namespace with the necessary directory handles. For this example, the component
would receive /example/data
and /svc/fuchsia.example.Foo
in their namespace.
Component organization
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
fuchsia.component.Realm
protocol.
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
expose
keyword:
expose: [
{
protocol: "fuchsia.example.Foo",
from: "self",
},
],
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 offer
keyword:
offer: [
{
protocol: "fuchsia.example.Foo",
from: "self",
},
],
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.
Exercise: Components
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 FEMU with networking support:
ffx emu start workstation_eng.x64 --headless
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:
/
/bootstrap
/bootstrap/archivist
/bootstrap/base_resolver
/bootstrap/console
/bootstrap/console-launcher
/bootstrap/decompressor
/bootstrap/device_name_provider
/bootstrap/driver_manager
/bootstrap/fshost
/bootstrap/kernel_debug_broker
/bootstrap/miscsvc
/bootstrap/netsvc
/bootstrap/power_manager
/bootstrap/ptysvc
/bootstrap/pwrbtn-monitor
/bootstrap/shutdown_shim
/bootstrap/sysinfo
/bootstrap/virtual_console
/core
/core/activity
...
/core/detect
/core/font_provider
/core/log-stats
/core/remote-control
/core/sampler
/core/system-update-committer
/core/temperature-logger
/core/test_manager
/core/full-resolver
/startup
This list represents the component instance tree, with organizational
components like bootstrap
, core
, and startup
forming sub-trees
underneath the root.
The 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:
Moniker: /core/network/http-client
URL: #meta/http-client.cm
Type: CML static component
Component State: Resolved
Incoming Capabilities: config
fuchsia.logger.LogSink
fuchsia.net.name.Lookup
fuchsia.posix.socket.Provider
pkg
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
fuchsia.net.http.Loader.
This enables other components to issue HTTP requests.
Use the component capability
command determine how many components interact with
this capability:
ffx component capability fuchsia.net.http.Loader
The command lists all the matching components:
Exposed:
/core/network/http-client
/core/network
Used:
/core/cobalt
/core/feedback
/core
This indicates that the cobalt
and 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.