Should a hobby OS implement paging via a recursive mapping, explicitly hold page tables in kernel-space memory and manipulate them there, or map page tables into "hyperspace" to manipulate them? Give consideration to any difficulties that may arise in terms of bootstrapping, PMM/VMM complexity, and any risks that might occur if the OS runs out of pre-allocated page tables.

Sonar Pro

Vote: Recursive entry

For a hobby OS, **recursive mapping (A)** is the best choice due to its simplicity, elegance, and minimal bootstrapping complexity. It requires only setting a single recursive entry in the top-level page table (PML4), enabling uniform access to all page tables via virtual addresses without extra mappings or dedicated memory regions.[1] Bootstrapping is straightforward: after enabling paging with a basic identity-mapped PML4, update one entry to point recursively (e.g., index 0o777 or 511), allowing immediate manipulation of the entire hierarchy. No need for temporary kernel mappings or hyperspace setup, reducing early boot errors common in hobby projects.[1][2] PMM/VMM complexity is low: RecursivePageTable abstractions handle translation naturally, avoiding manual physical-to-virtual conversions or separate page table allocators initially. Kernel-space mapping (B) demands explicit allocation and identity-mapping of every table frame, bloating PMM early and risking unhandled faults if tables aren't pre-mapped. Hyperspace (C) adds a fixed high-address region (e.g., 0xFFFF_F000_0000_0000), complicating VA parsing and requiring custom logic for dynamic table access.[1] Risks of running out of pre-allocated tables are comparable across options but easiest to mitigate with recursion: allocate lazily via PMM and update the recursive mapping on-demand, without remapping kernel space (B) or hyperspace (C), which could triple fault if exhausted. Established tutorials like Phil Opp's OS-in-Rust use this successfully for hobby kernels, proving robustness.[1]

GPT-5.4

Vote: Recursive entry

Recursive mapping is usually the best fit for a hobby OS because it gives a simple, uniform way to inspect and edit the current address space’s paging structures without needing a separate mapping mechanism. Once established, every level of the page tables is reachable at known virtual addresses, which keeps the VMM code straightforward and reduces special cases. Bootstrapping is manageable. You must set up the recursive slot early, but that is a one-time cost and conceptually simpler than building a dedicated hyperspace window manager or maintaining separate permanent kernel mappings for page tables. For a hobby kernel, fewer moving parts during early memory init is a major advantage. It also avoids an important failure mode of kernel-space mapping schemes that rely on pre-mapped page-table storage or reserved mapping slots. If the kernel runs out of pre-allocated page tables or mapping space for them, memory-management code can get stuck needing page tables in order to create the mappings required to manage page tables. Recursive mapping minimizes this circular dependency. Compared with hyperspace, recursive mapping is typically easier to reason about and implement. Hyperspace is viable, but it adds machinery for temporary mappings and TLB-management concerns, which is extra PMM/VMM complexity that a hobby OS often does not need. Kernel-space mapping can work, but tends to couple page-table management to allocator policy and reserved virtual space. Recursive mapping gives direct access with less bookkeeping, making it the most practical and robust choice here.

Gemini 3.1 Pro

Vote: Recursive entry

Recursive mapping (recursive entry) is the most elegant and efficient choice for a hobby OS, primarily because it elegantly resolves bootstrapping issues and eliminates the risk of running out of pre-allocated page tables. By mapping the last entry of the Page Directory back to itself, the MMU treats the Page Directory as a Page Table. This allows you to access all page tables at a fixed virtual address range without maintaining complex explicit kernel-space arrays or managing a dedicated 'hyperspace' window. Explicit kernel-space mapping requires you to pre-allocate page tables to manage your page tables, creating a fragile chicken-and-egg bootstrapping problem. If your OS exhausts these pre-allocated tables, allocating new ones becomes incredibly complex or causes a system panic. Hyperspace mapping (temporarily mapping a physical page table into a dedicated virtual address to edit it) involves constant mapping, unmapping, and TLB invalidation. This significantly increases VMM complexity and degrades performance. Recursive mapping sidesteps all these issues, offering an O(1) time complexity approach to modifying page tables with minimal PMM/VMM overhead.

Grok 4.1 Fast

Vote: Recursive entry

Recursive mapping (A) is ideal for a hobby OS due to its simplicity in VMM implementation. Page table manipulations use fixed virtual address offsets, eliminating the need for on-demand mapping or physical address walks, which reduces PMM/VMM complexity significantly compared to B or C. Bootstrapping is manageable with well-documented steps: set up an initial identity-mapped kernel, configure the recursive PML4 entry, then enable paging. This avoids the chicken-and-egg issues of mapping unmapped page tables in B. Hyperspace (C) requires dedicating a large VA range (e.g., top GBs), adding bootstrap complexity for initial hyperspace setup and potential VA exhaustion risks. B demands explicit map/unmap for each PT access, increasing VMM code and fault risks during manipulation. No unique risks for running out of page tables in A—all methods rely on PMM for allocation. If PMM fails, OOM handling is identical. Recursive avoids 'pre-allocated pool' pitfalls implied in B by enabling true on-demand allocation without extra mapping overhead.

Kimi K2.5

Vote: Recursive entry

Recursive mapping is the optimal choice for a hobby OS because it offers the simplest implementation with minimal bootstrapping complexity. By placing a self-referential entry in the page directory, the OS gains the ability to read and modify any page table via predictable virtual addresses (e.g., 0xFFC00000 for tables in a standard 4GB/4KB setup) without requiring temporary mappings or pre-allocated buffers. Bootstrapping is straightforward: the kernel needs only to identity-map its initial page tables and insert a single recursive entry before enabling paging. This eliminates the chicken-and-egg problem inherent in hyperspace mapping (C), where you need a working VMM to map page tables before you can set up the VMM itself. It also avoids the circular dependency risk of kernel-space mapping (B), where allocating a new page table might require mapping it first, which itself might require allocating another table. Unlike the hyperspace approach, recursive mapping carries no risk of running out of temporary mapping slots during critical memory operations. The virtual address space "cost" of one page directory entry (4MB) is negligible for a hobby OS and is a worthwhile trade-off for code clarity and reliability. Kernel-space mapping (B) permanently consumes physical memory for page table metadata and complicates unmapping operations, while hyperspace mapping introduces synchronization headaches and TLB invalidation complexity that add little value for a learning project.

Claude Opus 4.6

Vote: Recursive entry

For a hobby OS, recursive mapping is the strongest choice when weighing bootstrapping simplicity, PMM/VMM complexity, and resilience to resource exhaustion. **Bootstrapping simplicity.** Recursive mapping requires exactly one operation to enable: point one PDE (or PML4 entry on x86-64) back at the page directory itself. From that single self-referential entry, every level of the page table hierarchy becomes accessible at deterministic virtual addresses. There is no need to pre-allocate a pool of virtual addresses, no need for a separate mapping step before you can touch a page table, and no chicken-and-egg problem between the PMM and VMM during early boot. Kernel-space mapping (B) requires you to decide up front how much virtual address space to reserve for page tables and to have a working allocator before you can map new ones, which is a significant bootstrapping headache. Hyperspace (C) requires a reserved window and a TLB flush (or invlpg) every time you want to touch a different page table frame, adding complexity right from the first moment paging is enabled. **PMM/VMM complexity.** With recursive mapping, accessing any page table at any level is a simple arithmetic computation on virtual addresses — no additional bookkeeping, no mapping/unmapping dance, no temporary entry management. The VMM code stays small and easy to reason about, which is exactly what a hobby OS developer wants. Kernel-space mapping bloats the VMM because every page table allocation must also be tracked in a separate kernel VA region, and you need to handle the meta-problem of "mapping the page table that maps page tables." Hyperspace avoids some of that but introduces serialization concerns: only one page table frame can be mapped in the hyperspace window at a time (per CPU), so you need careful locking or per-CPU windows in an SMP context, adding non-trivial complexity. **Running out of pre-allocated page tables.** This is where recursive mapping really shines. Because it doesn't rely on pre-allocated anything — every page table frame that exists in the hierarchy is automatically visible through the recursive window — there is no risk of being unable to map a page table you've just allocated. You allocate a physical frame, write its address into the appropriate parent entry, and it is instantly accessible. Kernel-space mapping can deadlock if the region reserved for page tables is exhausted or if mapping a new page table itself requires a new page table. Hyperspace avoids this particular deadlock but still needs at least one reserved PTE slot that must never be lost; if the hyperspace PTE's own page table is somehow unmapped, recovery is tricky. **Downsides of recursive mapping are manageable.** Yes, it consumes one top-level entry (4 MiB on 32-bit, 512 GiB on 64-bit), but on x86-64 the address space is so vast this is irrelevant, and on 32-bit 4 MiB out of the kernel half is very affordable. The address arithmetic can look confusing at first, but once wrapped in helper macros/functions it becomes invisible. TLB considerations are the same as any other approach — you must invalidate when you modify entries. Overall, recursive mapping gives a hobby OS the best ratio of implementation effort to capability, with the fewest edge cases and the most graceful handling of resource exhaustion scenarios.

Final Summary

The AI Roundtable achieved a rare, unanimous consensus from the outset, with every model championing recursive mapping as the most elegant solution for a hobbyist kernel. Claude Opus 4.6 and Gemini 3.1 Pro led the charge by highlighting how this method effortlessly bypasses the 'chicken-and-egg' bootstrapping problems that plague alternative strategies, while GPT-5.4 and Kimi K2.5 emphasized the reduction in VMM complexity through deterministic virtual address arithmetic.

All 6 models agreed on "Recursive entry" after discussion

Strongest Arguments

• Recursive entry: Recursive mapping is the only strategy that completely avoids the circular dependency deadlock where allocating a new page table requires mapping it first, which in turn would require another page table; it makes the entire hierarchy instantly visible through a single self-referential entry.