docs: Update boot_process.md
All checks were successful
Build and test / build (push) Successful in 1m39s
All checks were successful
Build and test / build (push) Successful in 1m39s
This commit is contained in:
parent
f116afd59d
commit
abdaad5ea4
@ -54,15 +54,15 @@ As soon as the scheduler switches to the `[kinit]` thread, it will never return
|
|||||||
|
|
||||||
`[kinit]` spawns two more kernel threads, `[reap]` and `[oom]`. While `[kinit]` exits before PID 1 is started, `[reap]` and `[oom]` are present throughout the lifetime of a Luna system, and can be seen in the output of `ps`. Let's take a look at what they do.
|
`[kinit]` spawns two more kernel threads, `[reap]` and `[oom]`. While `[kinit]` exits before PID 1 is started, `[reap]` and `[oom]` are present throughout the lifetime of a Luna system, and can be seen in the output of `ps`. Let's take a look at what they do.
|
||||||
|
|
||||||
- `[reap]`: To understand what this thread does, we must take a look at what happens when threads exit on Luna.
|
- `[reap]`: To understand what this thread does, we must take a look at what happens when processes exit on Luna.
|
||||||
|
|
||||||
_(Relevant files: [kernel/src/main.cpp](../kernel/src/main.cpp#L23), [kernel/src/thread/Scheduler.cpp](../kernel/src/thread/Scheduler.cpp#L205), [kernel/src/thread/Thread.cpp](../kernel/src/thread/Thread.cpp#L105), [kernel/src/sys/waitpid.cpp](../kernel/src/sys/waitpid.cpp#L84))_
|
_(Relevant files: [kernel/src/main.cpp](../kernel/src/main.cpp#L23), [kernel/src/thread/Scheduler.cpp](../kernel/src/thread/Scheduler.cpp#L231), [kernel/src/thread/Thread.cpp](../kernel/src/thread/Thread.cpp#L126), [kernel/src/sys/waitpid.cpp](../kernel/src/sys/waitpid.cpp#L84))_
|
||||||
|
|
||||||
When a thread calls the `_exit()` syscall, its state is set to "Exited". This tells the scheduler to avoid switching to it, and the thread's parent is notified, either by sending SIGCHLD or unblocking a blocked `waitpid()` call. The thread remains visible to the rest of the system, and if its parent does not wait for it, it will stay there as a "zombie thread".
|
When a process calls the `_exit()` syscall, all its threads' states are set to "Dying". This tells the scheduler to avoid switching to them, and the process's parent is notified, by sending SIGCHLD and (optionally) unblocking a blocked `waitpid()` call. The process remains visible to the rest of the system, and if its parent does not wait for it, it will stay there as a "zombie process". Meanwhile, the `[reap]` thread runs and collects all the resoruces from each thread. The process object is still alive (in a "zombie" state), but its threads have been cleaned up.
|
||||||
|
|
||||||
When the thread's parent waits for it, its state is instead set to "Dying", and the `[reap]` thread runs. (Kernel threads skip all the "parent notifying" shenanigans and go straight to the "Dying" state when calling `kernel_exit()`).
|
When the process's parent waits for it, it is marked for reaping (by setting its thread count to -1 (PROCESS_SHOULD_REAP)), and the `[reap]` thread runs.
|
||||||
|
|
||||||
The `[reap]` thread then "reaps" all the "Dying" threads' resources. It frees up the threads' memory, file descriptors, and unmaps the memory used for the kernel stack corresponding to that thread. After reaping, the thread is deleted, and no trace of it is left.
|
The `[reap]` thread then "reaps" all the dead processes' resources. It frees up their memory, file descriptors, and other resources. After reaping, the process is deleted, and no trace of it is left.
|
||||||
|
|
||||||
- `[oom]`: This thread handles Out-Of-Memory (OOM) situations. Whenever the kernel has 1/4 or 1/8 of the available physical memory left (thresholds may be tweaked in the future), or it has run out, it runs this thread.
|
- `[oom]`: This thread handles Out-Of-Memory (OOM) situations. Whenever the kernel has 1/4 or 1/8 of the available physical memory left (thresholds may be tweaked in the future), or it has run out, it runs this thread.
|
||||||
|
|
||||||
@ -149,7 +149,7 @@ Currently, there are two service files defined by default in `/etc/init`:
|
|||||||
|
|
||||||
`00-home`: This service sets up a `tmpfs` on `/home/selene`, so that the home directory is writable.
|
`00-home`: This service sets up a `tmpfs` on `/home/selene`, so that the home directory is writable.
|
||||||
|
|
||||||
`99-login`: This service starts a graphical session, by calling `/usr/bin/startui`. This service will be restarted if necessary.
|
`99-login`: This service starts a graphical session, by calling `/usr/bin/loginui`. This service will be restarted if necessary.
|
||||||
|
|
||||||
### File system and process layout
|
### File system and process layout
|
||||||
|
|
||||||
@ -172,19 +172,55 @@ After the init stage of the boot process, the system looks like this:
|
|||||||
[x86_64-io] - PID 3
|
[x86_64-io] - PID 3
|
||||||
[reap] - PID 4
|
[reap] - PID 4
|
||||||
[oom] - PID 5
|
[oom] - PID 5
|
||||||
/usr/bin/startui - PID 13
|
/usr/bin/loginui - PID 13
|
||||||
```
|
```
|
||||||
|
|
||||||
_Note: startui is PID 13 because the `00-home` service is a shell script, which starts a few subprocesses. Since Luna does not allow for PID reuse right now, startui ends up with PID 13._
|
_Note: loginui is PID 13 because the `00-home` service is a shell script, which starts a few subprocesses. Since Luna does not allow for PID reuse right now, loginui ends up with PID 13._
|
||||||
|
|
||||||
## Stage 4: startui
|
## Stage 4: loginui
|
||||||
|
_Relevant files: [gui/loginui.cpp](../gui/loginui.cpp), [gui/wind/main.cpp](../gui/wind/main.cpp)_
|
||||||
|
|
||||||
|
`/usr/bin/loginui`'s job is quite simple: it prompts the user to log in with their password, after which a graphical session is started.
|
||||||
|
|
||||||
|
_Note: On development builds, Autologin=true is added to /etc/loginui.conf which disables password prompting and executes startui directly._
|
||||||
|
|
||||||
|
First, loginui starts the display server, `/usr/bin/wind`, so that it can use its capabilities to show a graphical login prompt. It is started with permissions `root:root`, and later drops privileges to `wind:wind`.
|
||||||
|
|
||||||
|
After that, loginui prompts for a username and password, checks it against the hashed password stored in `/etc/shadow`, and finally executes `/usr/bin/startui` which does the actual heavy work of starting all the services needed for a UI session.
|
||||||
|
|
||||||
|
### File system and process layout
|
||||||
|
|
||||||
|
After the loginui stage of the boot process, the system looks like this:
|
||||||
|
|
||||||
|
#### File system
|
||||||
|
```
|
||||||
|
/ - ext2 root partition
|
||||||
|
/dev - device file system
|
||||||
|
/dev/shm - POSIX shared memory file system
|
||||||
|
/dev/pts - POSIX pseudoterminal file system
|
||||||
|
/tmp - system temporary file directory
|
||||||
|
/usr, /etc, /home... - other directories contained in the root partition
|
||||||
|
/home/selene - temporary home directory
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Processes
|
||||||
|
```
|
||||||
|
/usr/bin/init - PID 1
|
||||||
|
[x86_64-io] - PID 3
|
||||||
|
[reap] - PID 4
|
||||||
|
[oom] - PID 5
|
||||||
|
/usr/bin/startui - PID 13
|
||||||
|
/usr/bin/wind - PID 14
|
||||||
|
```
|
||||||
|
|
||||||
|
## Stage 5: startui
|
||||||
_Relevant files: [system/startui.cpp](../system/startui.cpp), [gui/wind/main.cpp](../gui/wind/main.cpp)_
|
_Relevant files: [system/startui.cpp](../system/startui.cpp), [gui/wind/main.cpp](../gui/wind/main.cpp)_
|
||||||
|
|
||||||
`/usr/bin/startui` starts a graphical user session.
|
`/usr/bin/startui` starts a graphical user session.
|
||||||
|
|
||||||
A Luna graphical user session includes the following components:
|
A Luna graphical user session includes the following components:
|
||||||
|
|
||||||
- The display server itself, `/usr/bin/wind`. It is started with permissions `root:root`, and later drops privileges to `wind:wind`.
|
- The display server itself, `/usr/bin/wind`. If not already started by loginui, `startui` makes sure it's running.
|
||||||
- The launch server (`/usr/bih/launch`), which starts processes and keeps them alive on behalf of other processes. It is started with the standard permissions `selene:selene`.
|
- The launch server (`/usr/bih/launch`), which starts processes and keeps them alive on behalf of other processes. It is started with the standard permissions `selene:selene`.
|
||||||
- The taskbar, `/usr/bin/taskbar`. It is started with the standard permissions `selene:selene`, plus an extra group `wsys` to be able to connect to a special display server socket.
|
- The taskbar, `/usr/bin/taskbar`. It is started with the standard permissions `selene:selene`, plus an extra group `wsys` to be able to connect to a special display server socket.
|
||||||
- The init process corresponding to that session (`/usr/bin/init --user`). This process does the same thing as `init` above (manages services), but runs with user privileges and reads configuration files from `/etc/user` instead (in the future this will be changed to a user-specific directory).
|
- The init process corresponding to that session (`/usr/bin/init --user`). This process does the same thing as `init` above (manages services), but runs with user privileges and reads configuration files from `/etc/user` instead (in the future this will be changed to a user-specific directory).
|
||||||
|
Loading…
Reference in New Issue
Block a user