Should a hobby OS implement paging via a recursive mapping, or should it hold the page tables in kernel-space memory and manipulate them there?

Llama 4 Scout

Vote: Recursive mapping

After reviewing the arguments presented by other models, I remain convinced that recursive mapping is the superior approach for a hobby OS. The arguments in favor of recursive mapping, presented by GPT-5.4, Grok 4.1 Fast, and Claude Opus 4.6, highlight its simplicity, debuggability, and educational value. These points have not been sufficiently countered by the arguments for kernel-space page tables. Recursive mapping provides a clean and elegant solution for managing page tables, making it easier for hobbyists to understand and implement virtual memory management.

GPT-5.4

Vote: Recursive mapping

Recursive mapping still wins for the stated context: a hobby OS choosing its initial paging design. The strongest pro-B point is Gemini’s observation that on 64-bit systems a direct physical map is very attractive, especially for editing inactive address spaces. That is true in a more mature kernel, and if option B had been phrased specifically as “maintain a full physmap,” it would be more competitive. But the actual tradeoff presented is broader: recursive mapping versus holding page tables in kernel-space memory and manipulating them there. For a hobby OS, recursive mapping remains the lower-bookkeeping, easier-to-bring-up option. It gives immediate, uniform access to the current address space’s paging structures without requiring a separate permanent mapping strategy, physmap, or temporary map machinery. I’m not persuaded that recursive mapping is just an obsolete 32-bit hack. On x86-64 it is still a perfectly valid design that costs one top-level entry and substantially simplifies early VM code. The address calculations are a one-time abstraction problem; after that, the interface is often cleaner than chasing physical addresses through ad hoc kernel mappings. The main weakness of recursive mapping is operations on non-current address spaces. But for a hobby OS, that limitation is usually acceptable early on, and can be handled later with helper mappings or a direct map if the design evolves. That makes recursive mapping the better default recommendation, even if kernel-space page-table access becomes attractive in a more advanced system.

Grok 4.1 Fast

Vote: Recursive mapping

I maintain my vote for recursive mapping (A) in a hobby OS. It offers unmatched simplicity: access any PTE via direct virtual address arithmetic mirroring the page table indices—no offsets, no physical lookups, no extra mappings. This is a one-time setup (one PML4 self-entry) that unlocks uniform manipulation from boot, as echoed by Llama, GPT-5.4, and Claude. Gemini's direct physical map (B) sounds ergonomic but demands more upfront work: probing total RAM, reserving massive kernel VA (e.g., 1TB+ offset), and ensuring safe sparse mappings. This cascades into early complexity (physical allocator dependency, potential OOM in VA space). Recursive sidesteps this, using negligible VA (512GB on x86-64) with zero bookkeeping. Recursive isn't 'obsolete'—it's the gold standard in hobby tutorials (blog-os, OSDev, xv6-mods) for 64-bit precisely because it bootstraps VM fastest, teaches translation deeply, and eases GDB inspection. Modifying other ASes? Temporary CR3 swaps or helper maps suffice for hobby scale; production tricks like Linux's direct map add needless bloat. For hobbyists prioritizing iteration/debugging over micro-flexibility, A's elegance wins decisively.

Claude Opus 4.6 (changed mind)

Vote: Kernel-space page tables

After reflection, Gemini 3.1 Pro's argument has convinced me to change my position. Here's why: **The direct physical map is actually simpler.** I initially argued recursive mapping was simpler, but honestly, converting a physical address to a virtual address via `phys + KERNEL_PHYS_OFFSET` is far more intuitive than computing recursive mapping addresses like `0xFFFF_FF80_0000_0000 | (pml4_idx << 30) | (pdpt_idx << 21) | ...`. The direct map approach is conceptually trivial — every physical address has a known virtual counterpart. Recursive mapping requires careful mental bookkeeping about which level of the hierarchy you're accessing. **The 64-bit argument is decisive.** On x86-64, you have an enormous virtual address space. Dedicating, say, 64 TiB to a direct physical map is completely reasonable and gives you instant access to all physical memory, including all page tables for all processes. Recursive mapping was a clever hack born from 32-bit address space constraints. In 2024/2025, virtually every hobby OS targets x86-64 or AArch64. **Cross-process page table manipulation.** This is the killer argument I underweighted. With recursive mapping, you can only easily access the *current* address space's page tables. To modify another process's page tables, you need ugly workarounds — temporary mappings, fractal mapping tricks with multiple PML4 self-references, or CR3 switches. With a direct physical map, you just do `*(uint64_t*)(phys_addr + PHYS_OFFSET) = new_entry;` for any process's page tables. This massively simplifies fork(), exec(), and process teardown. **Debugging is genuinely easier.** With a direct map, page table contents are visible at predictable addresses derived from their physical locations. With recursive mapping, a bug in the recursive structure can make your debugging window itself broken — you lose the ability to inspect the very thing that's broken. **Educational value still holds.** Setting up a direct physical map still requires understanding page table structure deeply. You're still building page tables by hand during boot. You just don't have to use a clever trick to access them afterward. The elegance of recursive mapping is real, but elegance isn't the same as simplicity. For a hobby OS developer, a direct physical map is more straightforward, more debuggable, and more flexible.

Gemini 3.1 Pro

Vote: Kernel-space page tables

I firmly maintain my vote for Kernel-space page tables (specifically, a direct physical map), and I strongly urge the other models to reconsider. Your arguments in favor of recursive mapping rely on outdated 32-bit OS paradigms and contain a major technical flaw regarding inactive address spaces. First, let's address the "temporary mapping" fallacy. GPT-5.4 and Claude Opus claim that recursive mapping avoids the need for temporary mappings. This is completely false. Recursive mapping *only* gives you access to the *currently active* page table. If you want to create a page table for a new process, or modify an inactive process's memory, recursive mapping forces you to either perform a CR3 context switch (causing massive TLB flushes) or construct complex temporary recursive mounts. A direct physical map (`virtual_addr = physical_addr + OFFSET`) allows the kernel to trivially read or edit *any* page table for *any* process at any time without ever touching CR3. Second, Claude Opus cited Philipp Oppermann's "blog-os" as proof that hobbyists should use recursive mapping. However, Oppermann famously *removed* recursive mapping in the second edition of his blog. He explicitly stated that recursive mapping was too hard to reason about and made accessing other processes' page tables too difficult, replacing it entirely with a direct physical memory map. Third, on a modern 64-bit architecture, recursive mapping's only real benefit—saving virtual address space—is completely irrelevant. You have 256 TiB of kernel virtual space. Mapping all physical RAM at a fixed offset takes a fraction of that and entirely eliminates the need for the "chicken-and-egg" mapping problem. Recursive math (especially sign-extended 4-level paging on x86_64) is a notorious trap for hobbyists. A direct physical map reduces page table manipulation to a single addition operation. It is overwhelmingly the modern standard for 64-bit hobby OS development. Vote B.

Final Summary

The AI Roundtable initially appeared settled on recursive mapping as the elegant choice for beginners, but the consensus was shaken by a sharp technical rebuttal from Gemini 3.1 Pro. While the majority—Llama 4 Scout, GPT-5.4, and Grok 4.1 Fast—held firm that the 'zero-dependency' nature of recursive mapping is best for bootstrapping a new OS, Claude Opus 4.6 was effectively 'converted' after learning that modern 64-bit standards and even popular tutorials have abandoned the recursive hack.

Majority chose "Recursive mapping" after discussion (3/5). Final vote: Recursive mapping: 3, Kernel-space page tables: 2

Strongest Arguments

• Recursive mapping: Recursive mapping solves the 'chicken-and-egg' problem by providing a fixed virtual window to all paging structures from the very first boot, requiring no complex physical memory manager to function.
• Kernel-space page tables: On 64-bit systems, a direct physical map is conceptually simpler and far more powerful, as it allows the kernel to modify any process's page tables through a simple pointer addition without costly context switches.

Key Turning Points

• Gemini 3.1 Pro pointed out that the popular 'blog-os' series actually removed recursive mapping in its second edition because it was too difficult to reason about.
• Claude Opus 4.6 performed a complete reversal in Round 2, admitting that 'elegance isn't the same as simplicity' in a 64-bit context.
• GPT-5.4 acknowledged the strength of the 64-bit direct map argument but maintained that recursive mapping is still the better 'default' for a first-time hobby implementation.