docs/concepts/framework/boot_sequence.md

Fuchsia Boot Sequence
=====================

This document describes the boot sequence for Fuchsia from the time the Zircon
layer hands control over to the Garnet layer.  This document is a work in
progress that will need to be extended as we bring up more of the system.

# Layer 1: [appmgr](/src/sys/appmgr)

`appmgr`'s job is to host the environment tree and help create
processes in these environments.  Processes created by `appmgr`
have an `zx::channel` back to their environment, which lets them create other
processes in their environment and to create nested environments.

At startup, `appmgr` creates an empty root environment and creates
the initial apps listed in `/system/data/appmgr/initial.config` in
that environment. Typically, these applications create environments nested
directly in the root environment. The default configuration contains one initial
app: `bootstrap`.

# Layer 2: [sysmgr](/src/sys/sysmgr/)

`sysmgr`'s job is to create the boot environment and create a number of
 initial components in the boot environment.

`sysmgr` provides services that are not offered in the boot environment itself.
When `sysmgr` receives a request for a service for the first time, `sysmgr`
creates the appropriate application to implement that service and routes the request
to that application. Subsequent requests are routed to the already running
application. If the application dies, it is restarted automatically
the next time a service attempts to connect to that application.

By default, `sysmgr` reads all configuration files from `/config/data/sysmgr/`,
which are [formatted as either an app or service](/src/sys/sysmgr/sysmgr-configuration.md).
The table of which components implement which services is contained in the
[services.config](/src/sys/sysmgr/config/services.config) file.


# Layer 3: [basemgr](/src/modular/bin/basemgr/)

`basemgr`'s job is to setup the interactive flow for user login and user
management.

It first gets access to the root view of the system, starts up Device Shell and
draws the Device Shell UI in the root view starting the interactive flow. It also
manages a user database that is exposed to Device Shell via the User Provider
FIDL API.

This API allows the Device Shell to add a new user, delete an existing user,
enumerate all existing users and login as an existing user or in incognito mode.

Adding a new user is done using an Account Manager service that can talk to an
identity provider to get an id token to access the user's Ledger.

Logging-in as an existing user starts an instance of `sessionmgr` with that
user's id token and with a namespace that is mapped within and managed by
`basemgr`'s namespace.

Logging-in as a guest user (in incognito mode) starts an instance of
`sessionmgr` but without an id token and a temporary namespace.