| pick your distro, get ZFS on root
kldload — your platform, your way, free
Source
Kernels & Architecture

The conversation nobody is having.

Here's a question they used to teach in university and mostly don't anymore: what is a kernel, and why does the architecture matter?

The kernel is the one piece of software that talks directly to your hardware. Every program you run, every file you save, every packet you send — it all goes through the kernel. It's the translator between your code and the metal. How you design that translator changes everything about what your system can do.

Three architectures, three philosophies

Monolithic Kernel (Linux)

Everything runs in one address space. The filesystem, the network stack, the device drivers, the scheduler — they're all inside the kernel. They can call each other directly. No overhead. Blazing fast.

The tradeoff: if any component crashes or gets compromised, it takes down the entire kernel. There is no isolation. A bug in a WiFi driver can corrupt memory used by the filesystem. A kernel exploit owns everything.

A monolithic kernel is an open-plan office. Everyone can talk to everyone instantly. But if someone sets their desk on fire, the whole building burns.

Microkernel (QNX, L4, Mach)

The kernel does almost nothing — just memory management, scheduling, and message passing. Everything else (filesystems, drivers, networking) runs as separate processes in userspace. They communicate through IPC (inter-process communication).

The tradeoff: rock-solid isolation. A crashed driver gets restarted without affecting anything else. But every operation that crosses a boundary costs an IPC call, and IPC is inherently slower than a direct function call.

A microkernel is a building with fireproof walls between every room. If one room catches fire, the others are fine. But passing a document between rooms means sliding it through a slot in the wall instead of handing it over.

Hybrid Kernel (Windows NT, macOS XNU)

A pragmatic middle ground. Critical stuff runs in kernel space for performance. Less critical stuff runs in userspace for safety. The boundary is a design choice, not a dogma.

The reality: most production systems end up here, even if they started somewhere else. macOS's XNU combines Mach (microkernel) with BSD (monolithic) components. Windows NT runs drivers in kernel space despite its microkernel heritage. Purity yields to pragmatism.

A hybrid is an open-plan office where the accounting department has its own locked room. Best of both worlds, if you draw the lines right.

So where do ZFS and WireGuard live? They're kernel modules — code that loads into the monolithic kernel at runtime. Once loaded, they're part of the kernel. They have direct access to memory, hardware, and every other subsystem. That's why they're fast: no IPC overhead, no context switches, no userland translation layer. A zfs send moves blocks directly from the storage subsystem through the network stack — kernel to kernel.

But here's the problem: Linux is monolithic, which means the kernel decides what's included. The Linux kernel ships with thousands of modules — but not ZFS (license conflict) and not always WireGuard (only mainlined in 5.6+, many enterprise kernels are older). These are out-of-tree modules. They exist, they work, they're production-ready — but you have to build them yourself because the kernel maintainers won't ship them.

FreeBSD doesn't have this problem. ZFS is in the FreeBSD kernel — in-tree, maintained, first-class. It's an architectural decision: FreeBSD chose to include ZFS. Linux chose not to, for licensing reasons. Both are valid decisions with different consequences. On FreeBSD, kldload zfs loads a module that ships with the kernel. On Linux, you compile it yourself — or you use a tool that does it for you.

That's what kldload literally means. It's the BSD command to load a kernel module. The tool does the same thing for Linux: loads the modules that should be there but aren't.

Why this matters right now

People deploy thousands of containers on a shared Linux kernel and call it "isolated." It's not. Containers use namespaces and cgroups — they're policy, not isolation. Every container shares the same monolithic kernel. A kernel exploit in one container owns them all. That's not a bug. That's the architecture.

This doesn't mean Linux is bad. It means you should understand what it is and what it isn't. Linux is phenomenal for performance, hardware support, and ecosystem. But if your threat model requires real isolation, you need hardware boundaries (VMs) or a different architecture. Knowing the difference is the whole game.

Containers vs VMs vs jails — the actual tradeoffs:

                   Isolation    Performance    Overhead    Kernel shared?
Linux container    policy       native         ~0          yes — one kernel for all
VM (KVM/bhyve)     hardware     near-native    ~2-5%       no — each VM has its own
FreeBSD jail       kernel       native         ~0          yes — but BSD kernel is different
microVM (Firecracker) hardware  near-native    ~1-3%       no — minimal guest kernel

On kldload with ZFS: VMs get their own zvol (tuned for VM I/O), containers get their own dataset (tuned for overlay storage), and jails on FreeBSD get their own dataset (clone a jail in milliseconds, replicate it with zfs send). The kernel architecture determines the isolation model. ZFS gives each model its own storage domain. The combination is what makes it work.

And here's the beautiful irony: eBPF — the technology that lets you safely inject code into a running Linux kernel — is essentially the monolithic kernel admitting it needs microkernel ideas. eBPF programs are verified, sandboxed, and can't crash the kernel. It's safe, modular code running inside a monolithic system. The architectures are converging. Understanding both helps you see where they're going.

eBPF is the reason kldload includes kernel-level observability out of the box. On a traditional system, you install Datadog, or Prometheus with node_exporter, or New Relic — userland agents that poll the kernel from outside, parsing /proc and /sys like reading the news instead of being in the room. eBPF puts you in the room. You attach a probe to a running kernel function and watch it execute. No agent. No parsing. No sampling. You see every syscall, every packet, every disk I/O — in real time, with nanosecond precision, with zero performance overhead when not tracing. The monolithic kernel that exposes everything to everything also lets you observe everything — if you have the right tool loaded.

The Tanenbaum-Torvalds debate (1992) Andrew Tanenbaum (creator of MINIX, a microkernel) told Linus Torvalds that monolithic kernels were "a giant step back into the 1970s." Torvalds said microkernels were too slow for real work. They were both right — and both wrong. Thirty years later, Linux uses eBPF for safe in-kernel code, and microkernels power every real-time system from medical devices to Mars rovers. The question was never "which is better." It was always "better for what."

The name is the whole project.

On FreeBSD, when you need a kernel module, you type kldload zfs. That's it. The module ships with the kernel. It loads. Done. The name means "kernel load" — load a module into the running kernel.

On Linux, that command doesn't exist — because the modules you want don't ship with the kernel. ZFS can't be included (CDDL vs GPL). WireGuard wasn't mainlined until 2020. NVIDIA drivers are proprietary. So you download source, install a compiler, build against your kernel headers, sign the result, rebuild the initramfs, and pray the next kernel update doesn't break it.

kldload the tool does what kldload the BSD command does — but for Linux, at image build time. It's a re-packer. It takes a stock vendor distribution, downloads all the official packages, builds and signs the out-of-tree kernel modules, and re-packs everything into a single bootable image. The result is indistinguishable from the vendor's own installer. It just has the modules that the vendor chose not to ship.

FreeBSD doesn't need this tool. FreeBSD ships ZFS. Linux does need it — because Linux is just a kernel, and the vendors who assemble everything around it have every incentive not to include the modules that make their userland products unnecessary.

← What nobody teaches you anymore. Kernel vs Userland — why boot order matters. →