1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
|
# ADR 0005 — Persistent terminal program, per-instance shell/vt, and a disk-write controller
## Status
Accepted.
## Context
The GUI (ADR 0004) left the console as a special "layer 0" rendered
straight into the shared shadow, with a single shell (task 0) reading a
global keyboard buffer and being the only thing that touches the disk. We
want a TempleOS-inspired **persistent terminal program**: a full-screen,
always-present command line, plus the ability to spawn additional terminal
windows.
## Decision
- **Home terminal** — a real window (own pixel buffer, composited by the
WM) that is full-screen, chrome-less (no title bar / minimize / close),
bottom-pinned (never raised), and never closes. It is the persistent
desktop.
- **F1 terminals** — ordinary windows (640×400, title bar, movable,
closable via F4 and the close button) running additional shell instances.
- **Per-instance** — `vt` becomes a per-instance `Terminal` (cell grid,
cursor, ANSI parser, scroll); `tty` and `shell` become per-instance too.
Each terminal owns one of each.
- **Input** — every terminal's shell reads `TaskMsg::Key` from its own task
queue (routed by the WM's input pump to the focused window). No terminal
reads the global keyboard buffer; there is one input path for all.
- **Rendering** — a terminal renders its text grid into its window's pixel
buffer; the WM composites it like any other window. This supersedes the
scroll-hook workaround from ADR 0004.
- **Disk controller** — `fs`/`fat` remain the disk owner, but every
mutating operation is wrapped in a re-entrant preemption-disable lock,
serializing concurrent access from multiple shells. Per-call granularity.
- **Background** — a terminal's running command keeps producing output into
its buffer while unfocused (free from preemptive multitasking plus
per-terminal buffers).
## Consequences
- Positive: the console is a first-class program; multiple terminals share
one coherent input path; concurrent disk access is safe.
- Negative: the preemption-disable disk lock stalls the scheduler during
disk I/O (fine on QEMU's RAM-backed disk; revisit for real hardware).
- Negative: a substantial refactor of `vt`/`tty`/`shell` from globals to
instances.
- The "only the shell touches the disk" assumption is removed.
|