Component-based software

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

/
/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:

1. A unique identifier for the component instance (called a moniker).
2. The package URL where this component was loaded from.
3. The execution state of the component.
4. The current job/process ID where the instance is running.
5. 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.