Software is more flexible and reusable if it can be “configured”; that is, if aspects of its behavior can be controlled externally rather than being fixed by its source code.
Fuchsia is intended for use in large scale production environments across a wide range of products so there are many reasons configuration might be necessary. For example:
Note that these examples have very different properties. Some are “static”, applying the configuration when a package is built or a system is assembled, others are “dynamic”, applying the configuration without any change in the system image. Some imply a change that should persist across power cycles while in others change should be only temporary. Some should be possible across all products while others are only meaningful in the context of a single product.
Other platforms offer one or more flexible configuration mechanisms to meet this wide range of needs. For example, Chrome has Prefs, Settings, Features, Switches & Flags
On Fuchsia today, configuration of platform components is performed primarily through two mechanisms:
config_data
. Build creates a single config_data
package containing a directory for each package containing a configurable component. These components can read their own configuration files from this package at runtime.#defines
. Some software is conditionally compiled based on build system arguments (e.g. auto_update_packages
). These arguments can be varied across products.Some platform services also expose FIDL interfaces to control their configuration and may persist this data across power cycles using isolated persistent storage or stash.
These mechanisms have been adequate for handling simple configuration cases across a small number of products but are not amenable to dynamic or multi-layered configuration and are already causing a number of pain points. For example:
_eng_arrested
products)config_data
system was created for CFv1 and a model of one component per package. Support in CFv2 is possible using the “directory subdir” feature but this is labor intensive and error prone.This project is still in its early stages and further work is required to finalize the requirements and the solution.
Files delivered to components through the config_data
package are opaque to the platform - different components use different file formats and the data can be arbitrarily complex. The Fuchsia platform has no way of knowing what data a component expects or accepts so the platform cannot validate the data or combine elements from different sources. Accepting opaque configuration data from untrusted sources would raise a number of security concerns.
We believe a new type of “structured configuration data” is necessary to complement the existing “opaque configuration data”. This structured configuration data should have the following properties:
We expect work over the next quarter will involve the following phases.
Clearly define the potential sources of configuration, the relationships between these, and the key attributes used to describe configuration changes. Agree which combinations are supported in the short and long term and which are the recommended mechanisms for implementing each. This includes describing the boundaries between the different forms of configuration, for example when should a configuration be handled by the system settings service.
The exercise will better define the gap that structured configuration must fill. The end result should feel similar to the Chrome reference page for configuration and should be published on fuchsia.dev.
Define and prioritize the requirements that structured configuration must fulfil both in the short term and the eventual future. Work with 1-2 launch customers to agree schedules and needs for 2021. Likely candidates are supporting the migration of existing customers away from modular (and hence away from modular config) or expanding the types of configuration possible in scalable product assembly.
Open questions for this phase are largely related to scope. For example:
Propose and agree on a technical solution meeting these requirements through the RFC process.
At this stage the structured configuration project does not depend on any other ongoing projects.
It is likely that the other projects will choose to depend on structured configuration to enable some new capability or migration. For example, migrating an existing product to session framework might depend on structured configuration to replace modular configuration.
Depending on scope and schedule, structured configuration might only be supported for component framework v2 components. Potentially this would create a transitive dependency from projects wishing to use structured configuration to component v2 migration or drivers as components.
The solution is not yet fully defined and additional risks may emerge during this process.
Currently the primary risk appears to be around schedule; will structured configuration be ready in time to meet the needs of the first customers? This risk could be partially mitigated by adding more people to the project once a technical solution has been agreed.