| # Supply build-time configuration data to components |
| |
| ## Terminology |
| |
| Base: A collection of software that constitutes the core of the system and is |
| updated atomically as part of a system update. |
| |
| Component: A unit of execution started by the component framework that |
| constructs its sandbox environment. |
| |
| Package: A unit of distribution in Fuchsia that is a collection of files. |
| See [the Fuchsia package manager](/src/sys/pkg/bin/pm/README.md#structure-of-a-fuchsia-package){:.external}. |
| |
| ## Scope |
| |
| This document describes how to provide product-specific configuration data to |
| components on a Fuchsia system. The mechanism described here is designed for |
| use with components that are part of Base. This mechanism **is** **not** |
| suitable for things that are not components. |
| |
| ## Overview |
| |
| The goal of the mechanism documented here is to provide a way for configuration |
| for Base components to be decentralized in the source. This means that |
| configuration data for a Base component can come from anywhere in the source tree |
| as Base is being built. This mechanism also makes it easier for component |
| configuration to vary by product. |
| |
| The config-data mechanism could be used to provide configuration for |
| components that are not part of Base, but using it for this is not recommended. |
| Among other things, the configuration itself is updated as part of Base. |
| Configuration implies an API and the different update timings create the |
| potential for mismatches between the implied API of the configuration data and |
| the component consuming the configuration. |
| |
| During the build of Base a package is constructed called `config-data`. This |
| package contains a set of directories whose names are matched against the names |
| of the packages of running components. When the component manager starts a |
| component that has requested the `config-data` feature, component manager will |
| examine the `config-data` package for a directory matching the name of the |
| package whose component is being started. If a match is found, the configuration |
| files appear in the component's namespace at `/config/data/`. |
| |
| The `config-data` package is a package included in Base itself and is therefore |
| updated exactly when Base is updated. This fact reduces the security concerns of |
| access based only on string matching since we should have a fair amount of trust |
| that the software in Base is designed to work properly together. |
| |
| ## Using config-data |
| |
| Files supplied via config-data are made available to all components within a |
| package to which the configuration is targeted if those components request |
| access to configuration data. It is not possible to restrict access of the |
| configuration data to anything finer than a package. |
| |
| ### Supplying Configuration |
| |
| If you want your package to insert configuration data into another package, |
| you need to create a `config_data` rule and use the `for_pkg` attribute to |
| indicate the target package. |
| |
| The following parameters are supported: |
| |
| * **`for_pkg`** (Required): Indicates the name of the package for which this |
| configuration is intended. |
| * **`sources`** (Required): Zero or more files to include in the |
| configuration. |
| * **`outputs`** (Optional): If provided, a list containing exactly one |
| pattern to indicate the output file name(s). |
| If a single source is provided, then the pattern can be a simple file name. |
| If multiple sources are provided, then the pattern should use |
| [GN placeholders][gn-placeholders] syntax. |
| |
| ``` |
| config_data("tennis_sysmgr_config") { |
| for_pkg = "sysmgr" |
| # The file "tennis_sysmgr.config" must be present in the same directory. |
| sources = [ "tennis_sysmgr.config" ] |
| # The file will be available at runtime as "tennis.config". |
| outputs = [ "tennis.config" ] |
| } |
| ``` |
| |
| ### Consuming |
| |
| #### Components v1 |
| |
| Include the following in your component manifest (`.cmx`) file: |
| |
| ```json |
| { |
| "sandbox": { |
| "features": [ |
| "config-data" |
| ] |
| } |
| } |
| ``` |
| |
| At runtime your component will be able to access the config files at the path |
| `/config/data`. The files will be read-only. |
| |
| #### Components v2 |
| |
| Include the following in your component manifest (`.cml`) file: |
| |
| ```json |
| { |
| use: [ |
| { |
| directory: "config-data", |
| rights: [ "r*" ], |
| path: "/config/data", |
| }, |
| ], |
| } |
| ``` |
| |
| At runtime your component will be able to access the config files at the path |
| `/config/data`. The files will be read-only. |
| |
| For the above to work, `"config-data"` must be offered to your component. |
| For instance your parent may have a declaration that looks like this: |
| |
| ```json |
| { |
| children: [ |
| { |
| name: "foo-component", |
| url: "fuchsia-pkg://fuchsia.com/foo-package#meta/foo-component.cm", |
| }, |
| ], |
| offer: [ |
| { |
| directory: "config-data", |
| from: "parent", |
| to: [ "#foo-component" ], |
| subdir: "foo-package", |
| }, |
| ], |
| } |
| ``` |
| |
| Note that by convention a sub-directory of the parent's `"config-data"`, named |
| according to the child's package name, is offered to the child component. |
| |
| ### Updating |
| |
| The `config-data` package is part of the base set. |
| Base packages are part of the system image and can only be updated by a system |
| OTA or by repaving. As such, configs cannot be updated at runtime. |
| |
| For instance, if working with an emulator, rebuild the system image and restart |
| the emulator for your configuration changes to take effect. |
| |
| [gn-placeholders]: https://gn.googlesource.com/gn/+/HEAD/docs/reference.md#placeholders |