分层与内核形态
结构上分四层。真正需要解释的不是“有几层”，而是分界线画在哪、以及为什么画在那里。
| 层 | 内容 |
|---|---|
| 应用层 | .run 容器（FUJR）：原生 FujoOS 程序，以及 Windows / Linux / macOS 二进制 |
| 兼容层（用户态） | PE / ELF / Mach-O 加载器；API 垫片（kernel32/ntdll、libc、Foundation）；Mach trap 垫片；IR 解释器与预翻译 |
| 系统服务（Ring3） | srv_fs · srv_net · srv_disp · srv_aud · srv_input · srv_pkg · srv_font |
| 内核（Ring0） | 调度 · 虚拟内存 · IPC · 系统调用闸门 · 驱动框架 |
| 硬件 | x86_64（当前）→ arm64（长期） |
为什么是混合内核
Ring0 只保留 CPU 相关与空间管理；设备驱动、VFS、网络栈全部下沉到用户态服务——服务进程 + 共享内存 + IRQ fd 硬中断注入。这是 NT / WSL2 式的工程折中：绝大多数“与硬件无关”的代码因此处在可崩溃、可重启、可热升级的环境里。
代价是 IPC 与共享内存的复杂度，以及内核态到用户态的一次往返。收益是一条清晰的边界：Ring0 里的代码必须无懈可击，而它的面积被压到了很小。这条边界与 FUAI 的能力域是同一个思路——把“必须绝对可靠”的部分划小。
调度与内存的两个取舍
调度器
参考 Linux EEVDF 的虚拟时间公平性来保证交互延迟，同时保留 NT 式优先级与“游戏模式”动态提频。取的是两家的长处：公平性保证桌面不卡，优先级保证游戏模式能抢到时间片。
内存
4 KiB 页加 2 MiB 大页，物理内存以 2 MiB 伙伴系统管理；用户空间共享内存经 fujo-map 零拷贝成对映射，配合 GPU 栅栏同步。细节见 内存与地址空间。