diff options
Diffstat (limited to 'hurd/bootstrap.mdwn')
| -rw-r--r-- | hurd/bootstrap.mdwn | 155 |
1 files changed, 125 insertions, 30 deletions
diff --git a/hurd/bootstrap.mdwn b/hurd/bootstrap.mdwn index 83ad3218..fbce3bc1 100644 --- a/hurd/bootstrap.mdwn +++ b/hurd/bootstrap.mdwn @@ -58,6 +58,55 @@ it to load `/hurd/exec`) GNU Mach will eventually make the `$(task-resume)` function calls, and thus resume the ext2fs task only. +This starts a dance between the bootstrap processes: `ext2fs`, `exec`, `startup`, +`proc`, and `auth`. Indeed, there are a few dependencies between them: `exec` needs +`ext2fs` working to be able to start `startup`, `proc` and `auth`, and `ext2fs` needs to +register itself to `startup`, `proc` and `auth` so as to appear as a normal process, +running under uid 0. + +The base principle is that `ext2fs` has a nul bootstrap port set to while other +translators will have a non-nul bootstrap port, with which they will discuss. We +thus have a hierarchy between the bootstrap processes. `ext2fs` is at the root, +`exec` and `startup` are its direct children, and `auth` and `port` are direct +children of `startup`. + +Usually the bootstrap port is used when starting a translator, see +`fshelp_start_translator_long`: the parent translator starts the child and sets +its bootstrap port. The parent then waits for the child to call `fsys_startup` +on the bootstrap port, for the child to provide its control port, and for the +parent to provide the FS node that the child is translator for. + +For the bootstrap translators, the story is extended: + +* Between `ext2fs` and `startup`: `startup` additionally calls `fsys_init`, to +provide `ext2fs` with `proc` and `auth` ports. +* Between `startup` and `proc`: `proc` just calls `startup_procinit` to hand +over a `proc` port and get `auth` and `priv` ports. +* Between `startup` and `auth`: `auth` calls `startup_authinit` to hand over an +`auth` port and get a `proc` port, then calls `startup_essential_task` to notify +`startup` that the boot can proceed. +* For translators before `ext2fs`, the child calls `fsys_startup` to pass over +the control port of `ext2fs` (instead of its own control port, which is useless +for its parent). This is typically done in the `S_fsys_startup` stub, simply +forwarding it. The child also calls `fsys_init` to pass over the `proc` and +`auth` ports. Again, this is typically done in the `S_fsys_init` stub, simply +forwarding them. + +With that in mind, the dance between the bootstrap translators is happening as +described in the next sections. + +# Initialization of translators before ext2fs + +We plan to start pci-arbiter and rumpdisk translators before ext2fs. + +pci-arbiter's `main` function parses the arguments, and since it is given a disk +task port, it knows it is a bootstrap translator and thus initializes the +machdev library. `machdev_trivfs_init` resumes the disk task. + +rumpdisk's `main` function parses the arguments, and since it is given a FS task +port, it knows it is a bootstrap translator, and thus `machdev_trivfs_init` +resumes the FS task. + # ext2fs initialization ext2fs's `main` function starts by calling `diskfs_init_main`. @@ -68,7 +117,7 @@ opening the Mach console. Since the multiboot command line is available, `diskfs_init_main` sets the ext2fs bootstrap port to `MACH_PORT_NULL`: it is the bootstrap filesystem which -will be in charge of dancing with the exec translator. +will be in charge of dancing with the exec and startup translator. `diskfs_init_main` then initializes the libdiskfs library and spawns a thread to manage libdiskfs RPCs. @@ -76,19 +125,14 @@ manage libdiskfs RPCs. ext2fs continues its initialization: creating a pager, opening the hypermetadata, opening the root inode to be set as root by libdiskfs. -ext2fs then calls `diskfs_startup_diskfs` to really run the startup. +ext2fs then calls `diskfs_startup_diskfs` to really run the startup, implemented +by the libdiskfs library. -# diskfs bootstrap +# libdiskfs bootstrap Since the bootstrap port is `MACH_PORT_NULL`, `diskfs_startup_diskfs` calls `diskfs_start_bootstrap`. -TODO: we want `diskfs_startup_diskfs` to also call `task_get_bootstrap_port` to -call `fsys_startup` on its real bootstrap port once `diskfs_start_bootstrap` is -finished, for bootstrap translators before the root filesystem to know when the -root filesystem is ready, and register themselves as translators in the root -filesystem, register for shutdown notification, etc. - `diskfs_start_bootstrap` starts by creating a open port on itself for the current and root directory, all other processes will inherit it. @@ -108,14 +152,14 @@ its bootstrap port. `trivfs_startup` creates a control port for the exec translator, and calls `fsys_startup` on the bootstrap port to notify ext2fs that it is ready, give it -the control port, and get back a port on the underlying node for the exec +its exec control port, and get back a port on the underlying node for the exec translator (we want to make it show up on `/servers/exec`). -# diskfs taking back control +# libdiskfs taking back control `diskfs_execboot_fsys_startup` is thus called. It calls `dir_lookup` on `/servers/exec` to return the underlying node for the exec translator, and -stores the control port in `diskfs_exec_ctl`. It can then signal `execstarted`. +stores the `exec` control port in `diskfs_exec_ctl`. It can then signal `execstarted`. `diskfs_start_bootstrap` thus takes back control, It calls `fsys_getroot` on the control port of exec, and uses `dir_lookup` and `file_set_translator` to attach @@ -125,16 +169,27 @@ it to `/servers/exec`. be specified on the multiboot command line, but otherwise it will default to `/hurd/startup`. -Now that exec is up and running, the startup process can be created with +Now that exec is up and running, the `startup` process can be created with `exec_exec`. `diskfs_start_bootstrap` takes a lot of care in this: this is the first unix-looking process, it notably inherits the root directory and current working directory initialized above, it gets stdin/out/err on the mach console. It is passed as bootstrap port a port from the `diskfs_control_class`. +`diskfs_start_bootstrap` is complete, we are back to `diskfs_startup_diskfs`, +which checks whether ext2fs was given a bootstrap port, i.e. whether +the rumpdisk translator was started before ext2fs. If so, it +calls `diskfs_call_fsys_startup` which creates a new control port and passes +it do a call to `fsys_startup` on the bootstrap port, so rumpdisk gets access +to the ext2fs filesystem. Rumpdisk however does not return any `realnode` port, +since we are not exposing the ext2fs filesystem in rumpdisk, but rather the +converse. TODO: Rumpdisk forwards this `fsys_startup` call to pci-arbiter, so +the latter also gets access to the ext2fs filesystem. + # startup startup's `main` function starts and calls `task_get_bootstrap_port` to get its -bootstrap port, and `fsys_getpriv` to get a port on the ext2fs translator. It +bootstrap port, i.e. the control port of ext2fs, and `fsys_getpriv` on it to get +the host privileged port and device master port. It clears the bootstrap port so children do not inherit it. It sets itself up with output on the Mach console, and wires itself against swapping. It requests notification for ext2fs translator dying to detect it and print a warning in @@ -148,7 +203,7 @@ startup can then complete the unixish initialization, and run `/hurd/proc` and proc's `main` function starts. It initializes itself, and calls `task_get_bootstrap_port` to get a port on startup. It can then call -`startup_procinit` to pass it the proc port that will represent the startup +`startup_procinit` on it to pass it the proc port that will represent the startup task, and get ports on the auth server, the host privileged port, and device master port. @@ -159,7 +214,7 @@ ready. auth's `main` function starts. It creates the initial root auth handle (all permissions allowed). It calls `task_get_bootstrap_port` to get a port on -startup. It can then call `startup_authinit` to pass the initial root auth +startup. It can then call `startup_authinit` on it to pass the initial root auth handle, and get a port on the proc server. It can then register itself to proc. Eventually, auth calls `startup_essential_task` to tell startup that it is ready. @@ -181,29 +236,68 @@ filesystem on `/servers/startup`. `launch_core_servers` calls `startup_authinit_reply` to actually reply to the `startup_authinit` RPC with a port on proc. -`launch_core_servers` eventually calls `fsys_init` on its bootstrap port +`launch_core_servers` eventually calls `fsys_init` on its bootstrap port, to +give ext2fs the proc and auth ports. -# diskfs taking back control +diskfs' `diskfs_S_fsys_init` thus gets called. It first replies to startup, so +startup is not stuck in its `fsys_init` call and not able to reply to RPCs. From +then on, startup will be watching for `startup_essential_task` calls from the +various bootstrap processes. -diskfs' `diskfs_S_fsys_init` gets called, it thus knows that proc and auth are -ready, and can call `exec_init`. It initializes the default proc and auth ports -to be given to processes. +# libdiskfs taking back control -diskfs calls `startup_essential_task` to tell startup that it is -ready. +In diskfs' `diskfs_S_fsys_init`, diskfs now knows that proc and auth are ready, +and can call `exec_init` on the exec port. + +# exec getting initialized + +exec's `S_exec_init` gets called from the `exec_init` call from ext2fs. Exec can +register itself with proc, and eventually call `startup_essential_task` to tell +startup that it is ready. + +# back to libdiskfs initialization + +It also calls `fsys_init` +on its bootstrap port, i.e. rumpdisk. + +# rumpdisk getting initialized + +rumpdisk's `trivfs_S_fsys_init` gets called from the `fsys_init` call from +ext2fs. It calls `fsys_init` on its bootstrap port. + +# pci-arbiter getting initialized + +pci-arbiter's `trivfs_S_fsys_init` gets called from the `fsys_init` call from +rumpdisk. + +It gets the root node of ext2fs, sets all common ports, and install +pci-arbiter in the ext2fs FS as translator for `/servers/bus/pci`. + +It eventually calls `startup_essential_task` to tell startup that it is ready, +and requests shutdown notifications. + +# back to rumpdisk initialization + +It gets the root node of ext2fs, sets all common ports, and install +rumpdisk in the ext2fs FS as translator for `/dev/disk`. + +It eventually calls `startup_essential_task` to tell startup that it is ready, +and requests shutdown notifications. + +# back to libdiskfs initialization + +It initializes the default proc and auth ports to be given to processes. + +It calls `startup_essential_task` on the startup port to tell startup that +it is ready. Eventually, it calls `_diskfs_init_completed` to finish its initialization, and notably call `startup_request_notification` to get notified by startup when the system is shutting down. -# exec taking back control - -exec's `S_exec_init` gets called, it can register itself with proc, and -eventually call `startup_essential_task` to tell startup that it is ready. - # startup monitoring bootstrap progress -As mentioned above, the different essential tasks (ext2fs, proc, auth, exec) +As mentioned above, the different essential tasks (pci-arbiter, rumpdisk, ext2fs, proc, auth, exec) call `startup_essential_task` when they are ready. startup's `S_startup_essential_task` function thus gets called each time, and startup records each of them as essential, monitoring their death to crash the whole @@ -211,6 +305,7 @@ system. Once all of proc, auth, exec have called `startup_essential_task`, startup replies to their respective RPCs, so they actually start working altogether. It -also calls `launch_system`, which calls `launch_something`, which "launches +also calls `init_stdarrays` which sets the initial values of the standard exec data, and `frob_kernel_process` to plug the kernel task into the picture. +It eventually calls `launch_something`, which "launches something", which by default is `/libexec/runsystem`, but if that can not be found, launches a shell instead, so the user can fix it. |