SchOS/kernel
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Nexoniarz d85274dbd9 gfx: the console's typeface is replaceable, and the loader is what replaces it
Gate 0's last-but-one open item. Drop a TrueType file at \schos\console.ttf on
the ESP and the console is drawn with it; with no file, the face linked into
the kernel image, which is what an early panic needs and is not a degraded
mode.

**The loader reads it, and that is the decision worth writing down.** The
kernel opening the file once the root filesystem is mounted is the obvious
design. It is also wrong: the console has been drawing since the kernel's
first line, so a font arriving later changes the cell size, which changes the
column count, which re-lays out every terminal -- and blanks them. The kernel
log would vanish off the screen at the moment the root filesystem mounted,
which is exactly the log a machine being brought up for the first time is
being read for. Since the next thing on the list is real hardware, losing that
was not a trade worth making.

So the choice happens before anything is drawn. Three details make it cheap:

  - **EfiReservedMemoryType**, not EfiLoaderData. The E820 handoff turns
    loader data into usable memory, on the argument that the loader's own
    pages are the kernel's the moment it runs -- true of the loader, not true
    of a buffer it wants the kernel to keep reading from.
  - **Below 4 GB**, because the kernel reaches this through its direct map and
    that is how far the direct map goes. A font above it would need an ioremap
    the console cannot do before there is a console.
  - **Used in place.** No copy, which matters because the kernel has no
    contiguous allocator to copy 112 KB into -- the only one is the DMA arena,
    and that belongs to devices.

Sized without EFI_FILE_INFO and its GUID: seek past the end and ask where that
landed, which the specification requires to clamp.

Every failure falls back and keeps going -- no file, implausible size, no
memory, short read, unparseable file. The last says so in the log, because a
font that silently did not load looks exactly like a font that did.

Verified by booting with JetBrainsMono-ExtraBold.ttf on the ESP and
screendumping the console: visibly the bold face, against the Regular of a
boot with no file. Three boots each way, no traps and no panics, socktest and
memfdtest green in all six.

Nothing ships a console.ttf: the file would be the file already in the kernel,
and two copies of a font are two things that can disagree.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-23 17:47:45 +02:00
..
arch/x86_64 proc: real CPU time, a tty number, and an exe that is a symlink 2026-09-22 02:45:00 +02:00
core gfx: the second head shows the boot, not just what comes after it 2026-09-22 21:47:35 +02:00
dev gfx: the console's typeface is replaceable, and the loader is what replaces it 2026-09-23 17:47:45 +02:00
drivers gfx: the chosen resolution reaches every head, and the greeting stops racing 2026-09-22 22:19:00 +02:00
fs unix: a bound socket is a file 2026-09-22 10:06:10 +02:00
net unix: a bound socket is a file 2026-09-22 10:06:10 +02:00
proc proc: the controlling terminal crosses fork() 2026-09-22 09:21:06 +02:00
sys unix: a bound socket is a file 2026-09-22 10:06:10 +02:00
kernel.ld debugger: the kernel can be asked a question 2026-09-14 00:58:45 +02:00