Add a table of contents for all douments with at least one section

ClementNerma · Aug 14, 2020 · 3209dc2 · 3209dc2
1 parent 6f07625
commit 3209dc2
Show file tree

Hide file tree

Showing 44 changed files with 392 additions and 0 deletions.
diff --git a/docs/FAQ.md b/docs/FAQ.md
@@ -2,6 +2,14 @@
 
 Welcome to NightOS' FAQ. Please note that several questions are already answered in the [project's README](../README.md).
 
+- [This project seems too good to be true](#this-project-seems-too-good-to-be-true)
+- [What's the current state of the project?](#whats-the-current-state-of-the-project)
+- [Will this project replace Windows/MacOS/Linux/... one day?](#will-this-project-replace-windowsmacoslinux-one-day)
+- [How does this project relates to NightOS v1, [v2](https://github.com/ClementNerma/NightOS-v2) and [v3](https://github.com/ClementNerma/NightOS-v3)?](#how-does-this-project-relates-to-nightos-v1-v2-and-v3)
+- [Who are you?](#who-are-you)
+- [Why did you create NightOS?](#why-did-you-create-nightos)
+- [How can I help?](#how-can-i-help)
+
 ## This project seems too good to be true
 
 Well, it is in a way. NightOS can be designed as such a secure and robust O.S. because we chose to not maintain any backward compatibility with existing software - understand that existing applications from Linux, MacOS or Windows will **not be compatible with NightOS**. This is why we can afford to introduce so many new features and requirements current operating systems cannot.

diff --git a/docs/concepts/applications.md b/docs/concepts/applications.md
@@ -4,6 +4,19 @@ _Applications_ are the system's way to handle software.
 
 **NOTE :** This document is only an _introduction_ to how applications work.
 
+- [How applications work](#how-applications-work)
+- [Installation methods](#installation-methods)
+  - [From the store](#from-the-store)
+  - [Sideloading](#sideloading)
+  - [Volatile applications](#volatile-applications)
+- [Permissions](#permissions)
+- [Name and slug](#name-and-slug)
+- [Application Identifier](#application-identifier)
+- [Application Context](#application-context)
+- [Commands](#commands)
+- [System applications](#system-applications)
+- [Services](#services)
+
 ## How applications work
 
 An application is a set of executable files and resources. They are the only way to execute code, as direct binary programs are not supported.

diff --git a/docs/concepts/libraries.md b/docs/concepts/libraries.md
@@ -2,6 +2,10 @@
 
 _Libraries_ allow to share a program between multiple applications.
 
+- [How libraries work](#how-libraries-work)
+- [Dependencies management and resolving](#dependencies-management-and-resolving)
+- [System libraries](#system-libraries)
+
 ## How libraries work
 
 Unlike applications, libraries can be installed in multiple versions. This means you can have three versions of the same library installed at the same time on your computer.

diff --git a/docs/concepts/users.md b/docs/concepts/users.md
@@ -1,5 +1,14 @@
 # Users
 
+- [The concept](#the-concept)
+- [Users type](#users-type)
+- [Dangers of an admin. account](#dangers-of-an-admin-account)
+- [Alternative User Control (AUC)](#alternative-user-control-auc)
+- [Users' data encryption](#users-data-encryption)
+- [Child and supervised users](#child-and-supervised-users)
+- [Groups](#groups)
+- [User privileges](#user-privileges)
+
 ## The concept
 
 Many computers are intended to be shared by multiple persons. In such case, it is useful to separate the data of each user and to prevent other users from accesing another's.

diff --git a/docs/features/balancer.md b/docs/features/balancer.md
@@ -2,6 +2,10 @@
 
 The _balancer_ is a kernel feature that allows to get more performances out of most important applications.
 
+- [How the balancer works](#how-the-balancer-works)
+- [Application processes suspension](#application-processes-suspension)
+- [Performance mode](#performance-mode)
+
 ## How the balancer works
 
 The balancer allows to manage the priority of userland processes - and only them. Here is the list of its features:

diff --git a/docs/features/crash-saves.md b/docs/features/crash-saves.md
@@ -2,6 +2,12 @@
 
 _Crash saves_ prevent most data loss caused by a crash, in all applications supporting it.
 
+- [How crash saves work](#how-crash-saves-work)
+- [Crashes detection](#crashes-detection)
+  - [Invalid shutdown indicator](#invalid-shutdown-indicator)
+  - [Application's crash indicator](#applications-crash-indicator)
+- [Restoration process](#restoration-process)
+
 ## How crash saves work
 
 Every minute (this delay can be changed in the registry), a `SYS_CRASHSAVE_COLLECT` answerable signal is sent to all running applications.

diff --git a/docs/features/domains.md b/docs/features/domains.md
@@ -4,6 +4,9 @@ _Domains_ are a set of computers running NightOS which are linked to each other.
 
 It behaves like an extension of the [parental control](parental-control.md), though they are two completely distinct features and domains offer a lot more features, while being made not to manage a child's access to a computer but to manage thousands of comupters at once.
 
+- [The concept](#the-concept)
+- [Domain supervisor](#domain-supervisor)
+
 ## The concept
 
 Domains enable all features of [parental control](parental-control.md) (without the dedicated application though), as well as the following ones:

diff --git a/docs/features/encryption.md b/docs/features/encryption.md
@@ -2,6 +2,10 @@
 
 Encryption allows to prevent unauthorized access to a data with a password.
 
+- [Global encryption](#global-encryption)
+- [Per-user encryption](#per-user-encryption)
+- [Combining global and per-user encryptions](#combining-global-and-per-user-encryptions)
+
 ## Global encryption
 
 By default, the whole storage can be encrypted using the computer's master password, which is prompted on startup.

diff --git a/docs/features/freeze-prevention.md b/docs/features/freeze-prevention.md
@@ -3,6 +3,8 @@
 _Freeze prevention_ prevents nearly all computer freezes, by reserving a little amount of resources to the system.
 It is enabled by default, but it can be disabled during installation process or from the control panel.
 
+- [How freeze prevention works](#how-freeze-prevention-works)
+
 ## How freeze prevention works
 
 The system forbids applications to access a fixed amount of RAM, called the _freeze prevention resource_ (FPR), which is by default the smallest between 1% of the total RAM and 8 megabytes.

diff --git a/docs/features/parental-control.md b/docs/features/parental-control.md
@@ -2,6 +2,17 @@
 
 _Parental control_ allows to manage a child's access to a computer running NightOS.
 
+- [How it works](#how-it-works)
+- [Integration](#integration)
+- [Features](#features)
+  - [Restrict usage hours](#restrict-usage-hours)
+  - [Restrict session duration](#restrict-session-duration)
+  - [Restrict access to applications](#restrict-access-to-applications)
+  - [Restrict access to websites](#restrict-access-to-websites)
+  - [Restrict mature contents](#restrict-mature-contents)
+  - [Restrict installation of applications](#restrict-installation-of-applications)
+  - [Controlling session remotely](#controlling-session-remotely)
+
 ## How it works
 
 Parental control works using (at least) two accounts: the parent's account, and the child's user account, which is related to as a _child user_. Note that multiple child users can be managed using parental control.

diff --git a/docs/features/permissions.md b/docs/features/permissions.md
@@ -2,6 +2,10 @@
 
 _Permissions_ allow users to finely control what applications can access, and administrators to finely control what other users can do.
 
+- [How permissions work](#how-permissions-work)
+- [From the control center](#from-the-control-center)
+- [Security level](#security-level)
+
 ## How permissions work
 
 By default, an application has for only right to run code. It cannot interact with any external resource in any way (which means: no window creation, no filesystem/network access, ...).

diff --git a/docs/features/sandboxes.md b/docs/features/sandboxes.md
@@ -2,6 +2,10 @@
 
 _Sandboxes_ allow to test an application without applying modifications to the system.
 
+- [How sandboxes work](#how-sandboxes-work)
+- [Persistent sandboxes](#persistent-sandboxes)
+- [Puppet sandbox](#puppet-sandbox)
+
 ## How sandboxes work
 
 A sandbox is an execution mode where an application's modifications to the disk are not applied directly to it, but instead to a virtual drive stored in its `sandboxes` folder. When the app. exits, a confirmation overlay proposes to apply the modifications to the real storage - it's also possible to see the changes before applying them.

diff --git a/docs/project/development.md b/docs/project/development.md
@@ -2,6 +2,8 @@
 
 **WARNING: This document is only a draft and as such far from being complete. All informations described here are subject to change anytime.**
 
+- [Languages](#languages)
+
 ## Languages
 
 The project will be developped in [Rust](https://rust-lang.org/), with first-class support for this language.

diff --git a/docs/project/roadmap.md b/docs/project/roadmap.md
@@ -4,6 +4,15 @@
 
 The project will be cut in the four phases described below.
 
+- [Conception](#conception)
+- [Validation](#validation)
+- [Implementation](#implementation)
+  - [Phase 1: Unoptimized kernel](#phase-1-unoptimized-kernel)
+  - [Phase 2: Low-level implementation](#phase-2-low-level-implementation)
+  - [Phase 3: Applications & System optimization](#phase-3-applications--system-optimization)
+  - [Phase 4: Completion](#phase-4-completion)
+- [Evolution, Optimization & Maintenance](#evolution-optimization--maintenance)
+
 ## Conception
 
 The first part is to write conception documents about how the system work, both at a high-level (concepts, features, native applications etc.) and low-level (processes management, kernel design...).

diff --git a/docs/specs/applications/commands.md b/docs/specs/applications/commands.md
@@ -8,6 +8,11 @@ The format is the same as the [shell's command typing](../shell-scripting.md#com
 - The `optional` indicator becomes a boolean that must be set to `true`
 - The `void` type is forbidden
 
+- [Example](#example)
+- [Values encoding](#values-encoding)
+- [Returning and failing](#returning-and-failing)
+- [Volatile applications](#volatile-applications)
+
 ## Example
 
 ```yaml

diff --git a/docs/specs/applications/context.md b/docs/specs/applications/context.md
@@ -3,6 +3,10 @@
 An application's _execution context_ is a piece of data that is provided when the application starts.  
 It indicates why the application was started and so what it is supposed to do.
 
+- [Startup Reason](#startup-reason)
+- [Context header](#context-header)
+- [Arguments structure](#arguments-structure)
+
 ## Startup Reason
 
 The most important information is the _startup reason_, which indicates _why_ the application was started.

diff --git a/docs/specs/applications/package.md b/docs/specs/applications/package.md
@@ -2,6 +2,10 @@
 
 Application packages are files that have either the `.nap` (NightOS Application Package) or `.nva` (NightOS Volatile Application).
 
+- [Content](#content)
+- [Manifest](#manifest)
+- [Pre-compiled applications](#pre-compiled-applications)
+
 ## Content
 
 NAP and NVA files are ZStandard archives which only requirement is to contain, at the archive's root, a `manifest.toml` file describing the archive itself, a `hash.md5` ensuring the archive has not been corrupted.

diff --git a/docs/specs/fs-structure.md b/docs/specs/fs-structure.md
@@ -2,6 +2,9 @@
 
 This document presents the filesystem's hierarchy.
 
+- [Hierarchy](#hierarchy)
+- [Notes](#notes)
+
 ## Hierarchy
 
 _NOTE:_ `<F>` indicates the item is a file.

diff --git a/docs/specs/ipc.md b/docs/specs/ipc.md
@@ -2,6 +2,20 @@
 
 This document describes the way [Inter-Process Communication (IPC)](../technical/ipc.md) works.
 
+- [Pipes](#pipes)
+  - [Opening pipes](#opening-pipes)
+  - [Pipes' pending data](#pipes-pending-data)
+  - [Pipes locking](#pipes-locking)
+  - [Closing pipes](#closing-pipes)
+  - [Message pipes](#message-pipes)
+  - [Interactive usage](#interactive-usage)
+- [Service sockets](#service-sockets)
+  - [Opening](#opening)
+  - [Exchanges and messages](#exchanges-and-messages)
+  - [Methods and notifications](#methods-and-notifications)
+  - [Closing](#closing)
+- [Shared Memory](#shared-memory)
+
 ## Pipes
 
 _Inter-process Uni-directional Channels_ (IUC), also called _pipes_, allow two distinct processes to communicate.

diff --git a/docs/specs/kernel/hardware.md b/docs/specs/kernel/hardware.md
@@ -2,6 +2,12 @@
 
 This document describes how the kernel interacts with hardware.
 
+- [Hardware detection](#hardware-detection)
+- [Raw device descriptor](#raw-device-descriptor)
+- [Connection interface identifier](#connection-interface-identifier)
+- [Device identifier](#device-identifier)
+- [Drivers](#drivers)
+
 ## Hardware detection
 
 Devices are detected during the boot process and then periodically after startup. This allows to hotplug some additional components afterwards.

diff --git a/docs/specs/kernel/processes.md b/docs/specs/kernel/processes.md
@@ -2,6 +2,12 @@
 
 Apart from the kernel itself, all programs run in _processes_.
 
+- [Why processes](#why-processes)
+- [Switching and cycles](#switching-and-cycles)
+- [Process attributes](#process-attributes)
+- [Performance balancing](#performance-balancing)
+  - [Automatic priority attribution](#automatic-priority-attribution)
+
 ## Why processes
 
 Separating programs in threads presents several advantages:

diff --git a/docs/specs/libraries.md b/docs/specs/libraries.md
@@ -2,6 +2,8 @@
 
 Libraries are NightOS' way to share code between multiple applications.
 
+- [Manifest](#manifest)
+
 ## Manifest
 
 As libaries are only meant to share code, there manifest is a lot simplier than [applications' manifest](applications/manifest.md).

diff --git a/docs/specs/permissions.md b/docs/specs/permissions.md
@@ -8,6 +8,9 @@ For applications, these are named _permissions_, while for users their are calle
 
 The rule being that applications cannot get permissions that the user running them has not.
 
+- [List of user privileges](#list-of-user-privileges)
+- [List of application permissions](#list-of-application-permissions)
+
 ## List of user privileges
 
 Below is the list of all user privileges, with `Adm?` referring to commands that are only available in administrator mode:

diff --git a/docs/specs/registry.md b/docs/specs/registry.md
@@ -2,6 +2,11 @@
 
 This document describes the format of the [system registy](../technical/registry.md) as well as its content.
 
+- [Format](#format)
+  - [Notes about types](#notes-about-types)
+- [HFFR Format](#hffr-format)
+- [Structure](#structure)
+
 ## Format
 
 The registry is located in the `/etc/sys/registry` file. It's basically a nested B-Tree map.

diff --git a/docs/specs/services.md b/docs/specs/services.md
@@ -2,6 +2,13 @@
 
 This document describes the architecture of [services](../technical/services.md), as well as the list of all system services and their main features.
 
+- [Architecture of a service](#architecture-of-a-service)
+  - [Connections](#connections)
+  - [Communication](#communication)
+  - [Thread types](#thread-types)
+  - [Closing a connection](#closing-a-connection)
+- [System services](#system-services)
+
 ## Architecture of a service
 
 Application services have exactly one running instance per active user, to prevent a user to connect to the service of a user with more privileges than itself. System services, on their side, only have one global instance.

diff --git a/docs/specs/services/hw.md b/docs/specs/services/hw.md
@@ -2,6 +2,19 @@
 
 The `sys::hw` service is in charge of hardware devices. It coordinates and manages communications with the hardware.
 
+- [Hardware detection](#hardware-detection)
+- [Device formats](#device-formats)
+  - [Device type descriptor](#device-type-descriptor)
+  - [Device identifier](#device-identifier)
+  - [Device descriptor](#device-descriptor)
+  - [Patterns](#patterns)
+- [Drivers](#drivers)
+- [Methods](#methods)
+  - [`0x01` ENUM_DEVICES](#0x01-enum_devices)
+  - [`0x02` SUBSCRIBE_DEVICES](#0x02-subscribe_devices)
+- [Notifications](#notifications)
+  - [DEVICE_EVENT](#device_event)
+
 ## Hardware detection
 
 Hardware detection is handled by [the kernel itself](../kernel/hardware.md#hardware-detection), which then exposes a [_raw device descriptor_ (RDD)](../kernel/hardware.md#raw-device-descriptor) as well as a [_connection interface identifier_ (CII)](../kernel/hardware.md#connection-interface-identifier).