Login
Track C: Crystal’s standard library on Glint
Login

Glint's scope includes running Crystal programs that use the whole of Crystal's standard library, apart from what is specific to another operating system. The evidence is Crystal's own validation: the standard library's spec suite (spec/std), run on Glint. Where Crystal needs operating-system support, Glint provides it through a small system layer of its own. Any patch to Crystal is kept as small as possible, because Crystal's maintainers should not be asked to carry an educational kernel.

Phases 1–12 build the kernel and hypervisor; Glint's own work runs in the kernel. Track C adds what ordinary programs need: processes at EL0 (user mode), a system-call interface, files, threads, time and memory with a garbage collector. This is also where xv6's first four chapters return in their original sense, with user programs and system calls, rather than guests and hypercalls. The track starts after Phase 10, since it needs threads (Phase 8), sleep and wakeup (Phase 9) and files (Phase 10). It closes when spec/std passes, except for specs that are specific to another operating system, each of which is listed with its reason.

Provisional slices.

Slices

C.1 User processes. This slice runs a program at EL0 (ring 3 on x86) in its own address space, built with Phase 3's page-table builder, and returns to Glint on exit. It comes first because every later slice runs inside such a process. Its passages are xv6 §2.5 ("Process overview") and §3.6 ("Process address space"). Isolating programs from the kernel is the threat model (2.8) applied to Glint's own programs, which is Clarity.

C.2 Glint's system calls. This slice defines Glint's system-call interface (write, read, open, exit, memory mapping, clock, sleep and wakeup), entered by svc on Arm and syscall on x86, and checks every argument as 4.5 does for guests. It comes after C.1 because there must be a caller. Its passages are xv6 §4.3–4.4. Keeping the call set to what Crystal's system layer needs, and no more, is Parsimony.

C.3 A Crystal target for Glint. This slice adds Glint's part of Crystal's system layer (Crystal::System for a glint target), mapping console, files, time and random numbers onto C.2's calls. It is kept as an out-of-tree overlay where possible, so the patch to Crystal itself stays minimal. It comes after C.2 because it is written against those calls. A small, separable patch is Loose Coupling to Crystal's own project.

C.4 Memory and the garbage collector. This slice builds the Boehm collector (bdwgc, the collector Crystal uses) freestanding over C.2's memory calls, so Crystal's allocator works unchanged in user processes. It comes after C.3 because the system layer must exist for the collector to call into. Using Crystal's own collector rather than writing one is Parsimony.

C.5 Fibers and the event loop. This slice maps Crystal's fibers and event loop onto Phase 8's threads and Phase 9's sleep and wakeup, so spawn, Channel and blocking IO behave as they do elsewhere. It comes after C.4 because fibers allocate stacks through the collector. Building fibers on Glint's existing threads and sleep, rather than a second scheduler, is Parsimony.

C.6 Running spec/std. This slice runs Crystal's standard-library specs on Glint under QEMU, using Track T's harness, and records the pass count in the check-in. Specs that are specific to another operating system go into a listed exclusion file, each with its reason. Later slices raise the pass count one area at a time. It comes last because it exercises everything before it. The spec suite is Crystal's own definition of correct behaviour, which makes it the track's Demonstrability.

Track demo: Crystal's standard-library spec suite runs on Glint, with every exclusion listed and justified.

References