pub struct StartInfo {
pub resolved_url: String,
pub program: Dictionary,
pub namespace: Vec<ComponentNamespaceEntry>,
pub outgoing_dir: Option<ServerEnd<DirectoryMarker>>,
pub runtime_dir: Option<ServerEnd<DirectoryMarker>>,
pub numbered_handles: Vec<HandleInfo>,
pub encoded_config: Option<Data>,
pub break_on_start: Option<EventPair>,
pub component_instance: Option<Event>,
pub escrowed_dictionary: Option<DictionaryRef>,
}Expand description
StartInfo is convertible from the FIDL fcrunner::ComponentStartInfo type and performs validation that makes sense for all runners in the process.
Fields§
§resolved_url: StringThe resolved URL of the component.
This is the canonical URL obtained by the component resolver after following redirects and resolving relative paths.
program: DictionaryThe component’s program declaration.
This information originates from ComponentDecl.program.
namespace: Vec<ComponentNamespaceEntry>The namespace to provide to the component instance.
A namespace specifies the set of directories that a component instance
receives at start-up. Through the namespace directories, a component
may access capabilities available to it. The contents of the namespace
are mainly determined by the component’s use declarations but may
also contain additional capabilities automatically provided by the
framework.
By convention, a component’s namespace typically contains some or all of the following directories:
- “/svc”: A directory containing services that the component requested to use via its “import” declarations.
- “/pkg”: A directory containing the component’s package, including its binaries, libraries, and other assets.
The mount points specified in each entry must be unique and non-overlapping. For example, [{“/foo”, ..}, {“/foo/bar”, ..}] is invalid.
outgoing_dir: Option<ServerEnd<DirectoryMarker>>The directory this component serves.
runtime_dir: Option<ServerEnd<DirectoryMarker>>The directory served by the runner to present runtime information about the component. The runner must either serve it, or drop it to avoid blocking any consumers indefinitely.
numbered_handles: Vec<HandleInfo>The numbered handles that were passed to the component.
If the component does not support numbered handles, the runner is expected to close the handles.
encoded_config: Option<Data>Binary representation of the component’s configuration.
§Layout
The first 2 bytes of the data should be interpreted as an unsigned 16-bit little-endian integer which denotes the number of bytes following it that contain the configuration checksum. After the checksum, all the remaining bytes are a persistent FIDL message of a top-level struct. The struct’s fields match the configuration fields of the component’s compiled manifest in the same order.
break_on_start: Option<EventPair>An eventpair that debuggers can use to defer the launch of the component.
For example, ELF runners hold off from creating processes in the component until ZX_EVENTPAIR_PEER_CLOSED is signaled on this eventpair. They also ensure that runtime_dir is served before waiting on this eventpair. ELF debuggers can query the runtime_dir to decide whether to attach before they drop the other side of the eventpair, which is sent in the payload of the DebugStarted event in fuchsia.component.events.
component_instance: Option<Event>An opaque token that represents the component instance.
The fuchsia.component/Introspector protocol may be used to get the
string moniker of the instance from this token.
Runners may publish this token as part of diagnostics information, to identify the running component without knowing its moniker.
The token is invalidated when the component instance is destroyed.
escrowed_dictionary: Option<DictionaryRef>A dictionary containing data and handles that the component has escrowed
during its previous execution via
fuchsia.component.runner/ComponentController.OnEscrow.