docs: Correct a few details in boot_process.md
All checks were successful
Build and test / build (push) Successful in 1m35s
All checks were successful
Build and test / build (push) Successful in 1m35s
This commit is contained in:
parent
abdaad5ea4
commit
22766a6724
@ -58,7 +58,7 @@ As soon as the scheduler switches to the `[kinit]` thread, it will never return
|
|||||||
|
|
||||||
_(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))_
|
_(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 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 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 resources from each thread. The process object is still alive (in a "zombie" state), but its threads have been cleaned up.
|
||||||
|
|
||||||
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.
|
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.
|
||||||
|
|
||||||
@ -221,11 +221,11 @@ _Relevant files: [system/startui.cpp](../system/startui.cpp), [gui/wind/main.cpp
|
|||||||
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`. If not already started by loginui, `startui` makes sure it's running.
|
- 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 execution server (`/usr/bin/execd`), 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 (`/tmp/wsys.sock`, as opposed to the standard `/tmp/wind.sock`). This grants it the ability to use advanced wind features, such as placing the taskbar window behind all other windows.
|
||||||
- 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).
|
||||||
|
|
||||||
Currently, `init --user` only does one thing: it opens up a terminal window on startup. It can be configured to do whatever the user desires to do on startup, by placing the appropriate configuration files in `/etc/user`.
|
Currently, `init --user` only does one thing: it opens up a text editor with a welcome message on startup. It can be configured to do whatever the user desires to do on startup, by placing the appropriate configuration files in `/etc/user`.
|
||||||
|
|
||||||
### File system and process layout
|
### File system and process layout
|
||||||
|
|
||||||
@ -250,8 +250,7 @@ After the startui stage of the boot process, the system is fully started up and
|
|||||||
[oom] - PID 5
|
[oom] - PID 5
|
||||||
/usr/bin/startui - PID 13
|
/usr/bin/startui - PID 13
|
||||||
/usr/bin/wind - PID 14
|
/usr/bin/wind - PID 14
|
||||||
/usr/bin/launch - PID 15
|
/usr/bin/execd - PID 15
|
||||||
/usr/bin/taskbar - PID 16
|
/usr/bin/taskbar - PID 16
|
||||||
/usr/bin/init --user - PID 17
|
/usr/bin/init --user - PID 17
|
||||||
/usr/bin/terminal - PID 18
|
/usr/bin/editor welcome - PID 18
|
||||||
/bin/sh - PID 19
|
|
||||||
|
Loading…
Reference in New Issue
Block a user