DragonFly BSD Forks From FreeBSD 4.8 Over SMP Design Disagreements
DragonFly BSD began from FreeBSD 4.8 in June 2003 and was announced July 16, pursuing Matthew Dillon's LWKT, message-passing, clustering, and SMP design.
DragonFly BSD was forked from FreeBSD 4.8 in June 2003 by Matthew Dillon. Dillon announced it publicly to the freebsd-current mailing list on July 16, describing work from the preceding months that had grown into a separate operating-system project. His message named a new path toward SMP, a rewritten packaging and distribution system, and eventual backports of selected FreeBSD 5 features.
The fork is often summarized as a quarrel over kernel locks. The primary sources show a broader technical program: Dillon rejected FreeBSD 5’s increasingly mutex-heavy direction, wanted a lightweight kernel-thread and message-passing foundation, and initially connected those choices to native clustering goals. FreeBSD 4.8 was the starting point, not because it lacked SMP, but because its older architecture was the base Dillon believed would be faster to transform.
The context was FreeBSD 5’s SMPng transition
FreeBSD’s earlier SMP support relied heavily on Giant, a kernel-wide lock that serialized large amounts of kernel work. SMPng was the multi-release effort to replace that bottleneck with finer-grained locking and make more subsystems safe to execute concurrently. FreeBSD 5.0, released in January 2003, exposed users to a branch still in the middle of that transition.
Fine-grained locking can increase parallelism, but it also introduces lock ordering, contention, and maintenance complexity. FreeBSD developers accepted that engineering direction and progressively removed Giant from subsystems. Dillon believed a different organization could avoid much of that shared-state locking and provide a better foundation for both multiprocessor and distributed operation.
That disagreement should not be rewritten as “FreeBSD 5 added SMP while FreeBSD 4 had none.” FreeBSD 4 already ran on multiple processors; the dispute concerned how the kernel should scale beyond its coarse locking model and how its internal work should be organized.
Dillon’s announcement states the design choice directly
The July 16 message said the proving code implemented an earlier uniprocessor-to-SMP conversion under a “mutex-free light weight kernel threading infrastructure.” Dillon listed LWKT, interrupt threads, and pure threads for system processes. He reported working uniprocessor and SMP builds and said early development would concentrate on low-level kernel work.
Most importantly, he explained why the project started from 4.x rather than FreeBSD 5: in his assessment, 5.x was already too heavily mutexed, so moving 4.x forward was faster than moving 5.x backward. That is direct evidence for the architectural origin story; later claims about personalities or commit access are not needed to explain the published technical rationale.
The announcement also makes clear that DragonFly was not intended as a frozen FreeBSD 4 maintenance branch. It proposed a new kernel path, a package-system rewrite, and selective import of useful FreeBSD 5 work after the new foundation was established.
Clustering was part of the original ambition
DragonFly’s current history page says the project’s ultimate initial goal was native kernel clustering with cache-coherent filesystem namespaces, file spaces, and virtual-memory spaces. That ambition influenced resource partitioning, messaging, and cache-management decisions.
The same page is careful about historical evolution: full cache coherency across machines is no longer the project’s top-level goal, while filesystem coherency remains influential. That correction matters. Describing DragonFly today as if it were still solely a single-system-image clustering experiment would freeze its identity at the 2003 proposal rather than the system it became.
Message passing and per-CPU work gave the project an architectural vocabulary distinct from FreeBSD’s lock-by-lock SMPng path. The two systems could solve similar operating-system problems while making different tradeoffs about shared state and execution locality.
From source fork to an independent release
The project did not announce a finished alternative on day one. Dillon’s initial note limited the code to i386 and anticipated a slow start while machine-dependent infrastructure and I/O paths changed. DragonFly’s first formal 1.0 release arrived on July 12, 2004, nearly a year after the public announcement.
Over subsequent releases, DragonFly developed its own kernel facilities, userland changes, package practices, and storage work. HAMMER and later HAMMER2 became its most visible independent filesystem projects. Those developments demonstrate that “forked from FreeBSD 4.8” describes ancestry, not permanent compatibility or a minor downstream patch set.
Likewise, FreeBSD continued SMPng, improved performance across the 5.x and later branches, and built the architecture used by current releases. The continued existence of both projects does not provide a simple experimental verdict that one 2003 design was universally right. Their workloads, code, hardware eras, and goals diverged too much for that conclusion.
What the fork actually demonstrates
DragonFly is a case where an architectural alternative required control over the whole kernel rather than one optional subsystem. LWKT, interrupt handling, messaging, scheduling, virtual memory, and filesystem coherency intersected too deeply to remain a small experimental branch inside a project committed to another concurrency strategy.
The precise timeline helps separate history from myth: work and the fork began in June 2003; Dillon’s public FreeBSD mailing-list announcement is dated July 16; FreeBSD 4.8 was the source base; DragonFly 1.0 shipped July 12, 2004. The disagreement centered on technical direction, but the new project’s published goals extended beyond “SMP without locks.”
That is why DragonFly BSD matters in FreeBSD history. It preserved a snapshot of the 4.x lineage only long enough to replace its foundations with a distinct design—and turned a kernel-architecture disagreement into a separately evolving BSD operating system.
Related:
- FreeBSD 5.0 Ships with SMPng, the Start of Fine-Grained Kernel Locking
- The History of FreeBSD: From 386BSD to a Modern Unix
Sources: