feat: docs & ARCH 2.2, 2.3, 2.4
This commit is contained in:
72
kernel/docs/overview/introduction.md
Normal file
72
kernel/docs/overview/introduction.md
Normal file
@@ -0,0 +1,72 @@
|
||||
# Введение в ядро Elyz (LISA)
|
||||
|
||||
## Концептуальная модель
|
||||
|
||||
Elyz (LISA) — это модульное, capability-ориентированное ядро для x86-64,
|
||||
спроектированное вокруг следующих архитектурных принципов:
|
||||
|
||||
### 1. Capability-ориентированная безопасность
|
||||
|
||||
Вместо традиционной модели «всё или ничего» (ring 0 vs ring 3), Elyz
|
||||
использует систему **capabilities** (дескрипторов прав). Каждый дескриптор
|
||||
представляет собой *неподделываемый токен*, дающий доступ к конкретному
|
||||
объекту ядра (фрейму памяти, CNode, PMActor) с определёнными правами.
|
||||
|
||||
- Capability — это не просто число; это структура с полями `object`, `rights`,
|
||||
`relation`, `token_sig`.
|
||||
- Capability можно *создавать* (mint) с урезанными правами от родительского
|
||||
дескриптора.
|
||||
- Capability можно *отозвать* (revoke), что каскадно уничтожает всех потомков.
|
||||
- Система гарантирует, что access — это всегда наличие capability.
|
||||
|
||||
### 2. Многоуровневое управление памятью
|
||||
|
||||
Управление физической памятью разделено на три уровня:
|
||||
|
||||
| Уровень | Компонент | Ответственность |
|
||||
|---------|-----------|-----------------|
|
||||
| 1 (глобальный) | `BitmapPMM` | Владение всей физической памятью, аллокация/освобождение по 4KiB фреймам. Инициализируется из карты памяти bootloader'а. |
|
||||
| 2 (распределённый) | `PMActor` | Актёр физической памяти — владеет *диапазоном* физической памяти, использует `BuddyAllocator` для аллокации внутри этого диапазона. Каждый PMActor — изолированный аллокатор. |
|
||||
| 3 (виртуальный) | `AddressSpace` (VMM) | Управляет виртуальными адресными пространствами (PML4 + VMA-деревья). Использует PMM для аллокации PT-страниц и lazy demand-paging. |
|
||||
|
||||
Эти уровни связывает **PM Router** — lock-free система каналов для асинхронной
|
||||
пересылки запросов и ответов между исполнителями.
|
||||
|
||||
### 3. Асинхронная модель акторов
|
||||
|
||||
PMActor следует модели CSP (Communicating Sequential Processes):
|
||||
|
||||
- Каждый актор имеет lock-free MPSC-очередь входящих сообщений.
|
||||
- Потоки/процессы отправляют запросы (Alloc/Free/Carve) в очередь актора.
|
||||
- Когда актор получает CPU time, он вызывает `process_messages()` и
|
||||
отправляет ответы через PM Router.
|
||||
- PM Router использует 65536 предварительно выделенных каналов для
|
||||
lock-free маршрутизации результатов.
|
||||
|
||||
### 4. Виртуальная память с Copy-on-Write
|
||||
|
||||
`AddressSpace` поддерживает:
|
||||
- **Lazy demand-paging**: физическая страница выделяется только при
|
||||
page fault'е.
|
||||
- **Copy-on-Write (COW)**: при fork'е адресного пространства страницы
|
||||
разделяются между родителем и потомком; копирование происходит
|
||||
при первой записи.
|
||||
- **Zero-copy shared mappings**: физические страницы, принадлежащие
|
||||
capability, могут быть отображены в другое адресное пространство
|
||||
без копирования. Владелец страниц — capability, а не VMA.
|
||||
|
||||
### 5. Отзыв (Revocation) через lock-free очередь
|
||||
|
||||
Система отзыва дескрипторов использует глобальную lock-free кольцевую
|
||||
очередь `MMU_REVOCATION_QUEUE`. При отзыве capability:
|
||||
1. Токен capability помещается в очередь.
|
||||
2. При следующем page fault'е VMM обрабатывает накопленные отзывы.
|
||||
3. Все VMA, связанные с отозванным токеном, аннулируются.
|
||||
|
||||
### 6. Минималистичный дизайн
|
||||
|
||||
- `#![no_std]` — никакой стандартной библиотеки.
|
||||
- `#![no_main]` — точка входа `kmain`.
|
||||
- Все структуры данных, аллокаторы и драйверы написаны с нуля.
|
||||
- Единственные внешние зависимости: `limine` (bootloader протокол),
|
||||
`embedded-graphics` (шрифты), `bitflags`.
|
||||
Reference in New Issue
Block a user