Learn DragonFlyBSD - Core Concepts & Main Architecture

#Introduction

In episode 1 you got to know DragonFlyBSD's history: the FreeBSD 4.8 fork, the three pillars of LWKT, HAMMER2, and newbee, and the release map up to 6.4.2. Now we step up a level: dissecting how this system is put together. Understanding the architecture isn't just theoretical knowledge — it determines how you install packages, build kernels, and troubleshoot in production.

Picture DragonFlyBSD as an office building. There's the foundation (kernel), the working floors (userland), and tenants who arrive with their own equipment (DPorts). This episode is the building's floor plan: where each component sits, what its job is, and how they work together.

#Architecture: Base System & DPorts

#Base System

The base system is the core of DragonFlyBSD, developed together in a single source tree: the kernel, the C library, the compiler, the shell, and hundreds of basic utilities. All of this is maintained by the DragonFlyBSD team, released together, and tested together. The key concept is one coherent unit — not a collection of components assembled by the user.

The base system is divided into several parts:

This system is self-contained: the source tree at /usr/src contains all of the base system code, so you can rebuild everything — a topic we'll cover in episode 20.

#DPorts: The Application Layer

On top of the base system sits DPorts — a collection of hundreds of thousands of third-party application recipes. DPorts is an adaptation of FreeBSD's ports, so most software in the Unix world — from web servers to editors — is available. Users have two paths:

• Binary packages via pkg — fast, ready to use, built from the official pkg.dragonflybsd.org repository.
• Building from source via DPorts — flexible, allows custom options, and is the raw material for dsynth to build your own binary repository.

#Source Tree via Git

Unlike some other BSDs, DragonFlyBSD uses git as its version control — consistent with the modern open-source world. To get the source tree, clone directly from the official repository:

git clone git://git.dragonflybsd.org/dragonfly /usr/src
cd /usr/src
git checkout DragonFly_RELEASE_6_4

This source tree isn't just for building kernels. It also contains the userland, documentation, and kernel configs. Its main directory structure:

#Navigating the Source Tree

The habit of reading source code is a skill that separates ordinary administrators from true engineers. Whenever you ask "how does hammer2 work?", the answer is in the source tree. Some of the most visited locations:

Start small: less a key file in sys/vfs/hammer2/ to see how the PFS and snapshot concepts are actually implemented. Reading source isn't required to operate the system, but it makes every command you run feel more alive.

#Core Components

#Kernel: LWKT & the cpuset Scheduler

The DragonFlyBSD kernel is designed around LWKT (Lightweight Kernel Threading) as its execution foundation. Each CPU has its own run queue, and a per-process scheduler decides which thread runs. This gives fine-grained control: you can pin a process to a specific CPU with cpuset — very useful for latency-sensitive applications. The kernel is built from a customizable configuration, and drivers and the scheduler are configured via sysctl and loader.conf.

#Userland & Tooling

The userland is the set of utilities you use every day. Some that are typical of DragonFlyBSD: mount_hammer2, hammer2, newfs_hammer2 for the filesystem, rcorder for boot ordering, plus standard networking tools like ifconfig, route, and pfctl. They all have complete man pages — man will be your best friend throughout this series.

#HAMMER2

HAMMER2 is the default filesystem and the heart of the storage system. It works at the kernel level with copy-on-write, per-block checksums, and a B-tree structure that holds metadata. Users interact with it through three main commands: newfs_hammer2 (format), mount_hammer2 (mount), and hammer2 (managing PFSes, snapshots, dedup). We'll dissect it starting with episode 8.

#newbee: Custom Network Stack

newbee is the effort to rewrite DragonFlyBSD's network stack. Its goal: a model that's more modern, cleaner, and easier to understand than the legacy stack. It affects how interfaces, tunneling, and virtual networking work. For day-to-day administration, you still interact through ifconfig and route — but underneath, a different engine runs than in other BSDs.

#NVMM: Hypervisor

NVMM is DragonFlyBSD's built-in type-2 hypervisor. It provides CPU and memory virtualization primitives integrated with QEMU via the qemu package. This sets DragonFlyBSD apart from most other BSDs, which depend on third-party hypervisors. In episode 18 we'll create Linux and FreeBSD VMs on top of NVMM.

#pkg & dsynth

pkg is the frontend for binary packages, while dsynth is a tool for building an entire package repository from DPorts in parallel — useful for mirrors or custom binary builds. Both are covered fully in episode 4.

#Kernel Config: kern

DragonFlyBSD's kernel config system lives under sys/. Each kernel is built from a config file that registers devices, drivers, and options:

ls /usr/src/sys/config
cat /usr/src/sys/config/GENERIC | head -40

The default kernel config filename is GENERIC. You can copy it to DRAGONFLY or a custom name and change the options inside — the full topic is in episode 20.

#Closing

In this episode 2 you've understood DragonFlyBSD's architecture as a whole: the coherent base system (kernel + userland), DPorts as the application layer, the source tree cloned via git, and the roles of the LWKT kernel, userland, HAMMER2, newbee, NVMM, pkg, and kernel config as one unified system.

Key takeaways:

• The base system is one unit of kernel + userland; DPorts is the application layer on top of it.
• The source tree at /usr/src is cloned via git clone git://git.dragonflybsd.org/dragonfly.
• The LWKT kernel, HAMMER2, newbee, and NVMM are the components that make DragonFlyBSD different.
• Kernel configs live in /usr/src/sys/config with GENERIC as the default.
• man, sysctl, and the /usr/src structure are your navigation map throughout the series.

In the next episode, episode 3, we'll put all these concepts into practice in the real world: installation & partitioning. You'll walk through the text-based installer, select the sets (kern, base, comp, man), set up networking and swap, create GPT/MBR partitions with disklabel, and place HAMMER2 as the primary filesystem.