The DragonFlyBSD source mirror is a build system, not a library to import

A mirror, and that changes what you can expect from it

The repository description is short and precise: DragonFly BSD System Source Repository, read-only mirror. The README opens by calling it the top level of the DragonFly source directory.

That word mirror is doing real work. The tree you are reading is the system's own source layout, with the same Makefiles, the same configuration files and the same directory names that a DragonFly user sees on disk. It is convenient for reading and for building, but the history in the Git repository is not the development history of the project, and the absence of pull requests, issues and release tags in that sense is not an omission so much as a property of what this repository is.

The copyright information is handled in the traditional Unix way, and the README is explicit about where to find it. The COPYRIGHT file in the top directory holds the copyright information, and additional copyright information exists for some sources in the tree, so the specific source directories need to be consulted for their own notices. That is the mechanism a project with decades of imported code uses to keep per-file provenance, and it means the licensing answer for a given file is not necessarily the same as for the tree as a whole.

The repository carries a UPDATING file alongside the Makefile and the COPYRIGHT file. On a Unix system that file records the manual steps a user has to perform when upgrading across releases, which is the kind of detail that only exists because the system is built and installed from source rather than updated in place by a package manager.

buildworld and installworld cover everything but the kernel

The top-level Makefile is the interface to the tree, and the README describes the most commonly used targets. buildworld and installworld rebuild and install everything in the DragonFly system from the source tree, with three deliberate exceptions: the kernel, the kernel modules, and the contents of /etc. The buildkernel and installkernel targets handle the kernel and the modules separately.

The separation is the point. The base system and the kernel are built and installed independently, which is what makes it possible to rebuild a kernel against an already installed world, and it reflects how the system is actually structured.

The Makefile itself documents a wider set of targets, and the comments are the clearest statement of the workflow available. The user-driven targets for the base system start with these:

# buildworld          - Rebuild *everything* but the kernel, including glue to
#                       help do upgrades.
# quickworld          - Skip bootstrap, build and cross-build tool steps.
# realquickworld      - Skip above steps, plus depend.

The gradations are the interesting part. A full buildworld does the bootstrap, the build and the cross-build tool steps. quickworld skips those tool steps, and realquickworld skips the depend pass as well. For the kernel there is an equivalent ladder, with a native variant that uses the tools already on the machine instead of freshly built ones:

# buildkernel         - Rebuild the kernel and the kernel-modules from scratch
#                       using build/bootstrap/cross tools from the last
#                       buildworld.

The README points to the top of the Makefile for the standard build targets and the compile-time flags, and to the build(7) and config(8) man pages for the full description.

Kernel configuration lives in sys/config

Building a kernel is described as a somewhat involved process, and the configuration files are in the sys/config sub-directory. Three of them are named in the README, and each has a distinct role.

X86_64_GENERIC is the default x86_64 kernel configuration used in release builds. That is the file to start from for a machine like a normal workstation or server. VKERNEL64 is the default 64-bit vkernel(7) kernel configuration file, which is the configuration used when DragonFly runs as a guest under a hypervisor rather than as the only operating system on the hardware.

LINT64 is the odd one out, and the README is careful about its status. It contains entries for all possible devices, not just the ones commonly used, and it is meant more as a general reference than as an actual kernel configuration file. The parenthetical is blunt: a kernel built from it would not even run.

That distinction is worth internalising before you spend a day on it. LINT64 answers the question of what the system could support, while X86_64_GENERIC answers the question of what the system normally supports.

The build order also has a dependency, and the README states it directly: if you want to build and install the kernel with the buildkernel and installkernel targets, you might need to build world before. The handbook is the reference for that, along with the build(7) and config(8) man pages, and the handbook is at dragonflybsd.org/docs/handbook.

The source roadmap tells you where to look

The README includes a roadmap of the tree, and for anyone reading the source it is the most useful part of the document.

The top-level directories map onto the classic Unix division. bin holds system and user commands, and sbin holds system commands, with libexec for system daemons and usr.bin and usr.sbin for the user command and system administration trees. lib is the system libraries and include holds the system include files, with gnu containing various commands and libraries under the GNU Public License, where the README points at gnu/COPYING for the details. etc holds the template files for /etc, share the shared resources, doc the DragonFly documentation, and games the amusements.

The kernel side is sys for the kernel sources, with stand holding the boot loader sources. contrib holds packages contributed by third parties, and crypto the cryptography code, with a pointer to crypto/README. test holds the system tests, and tools holds the utilities used for regression testing and other miscellaneous tasks.

Two directories have a more specific job. initrd is the build system for statically linked /rescue utilities and for the initial ramdisk creation, which is what you need to boot a system that has no root filesystem yet. nrelease is the framework for building the live CD image. dports.base sits at the top level for the ports system, and the Makefile's buildportschroot and buildports targets build the chroot environment for it and the dragonfly/base dports, with cleanupports there to unmount the special chroot mounts afterwards.

The copyright note in gnu and the per-source notices in COPYRIGHT are the two places where the licence question changes shape depending on which directory you are in.

Ports, the live image and the full target list

The Makefile's target list covers the whole lifecycle of a build, and reading it tells you what operations the system supports.

For installing what has been built, installworld installs everything built by buildworld, and adds the rescue tools and the initrd image if they do not exist. installworld-force is the same thing for old systems, and world is the combination of buildworld and installworld. There is a separate installports target for installing the ports that were built via buildports, and cleanupports to umount the special chroot mounts and clean up any dsynth mounts that might have been left behind.

For the kernel, the ladder is buildkernel for a full rebuild using the tools from the last buildworld, nativekernel for a rebuild using native tools, quickkernel and realquickkernel for progressively more aggressive skipping, installkernel and reinstallkernel for putting the result in place, and kernel as the combination of buildkernel and installkernel.

Two details in that list are worth noting for anyone who has used another BSD. There is a crossworld target whose comment says it does just the bootstrap, build and cross-build steps, and there is a separate quickworld and realquickworld pair rather than a single quick target, which is the sort of granularity that comes from a tree that has been built on a wide variety of machines.

The other structural point is that the port system has its own chroot-based build environment, with buildportschroot to create it and cleanupports to take it apart again. On a system where the ports tree is built inside a chroot, forgetting the cleanup step leaves mounts behind, and the Makefile provides the target rather than leaving you to remember.

The repository also holds a Makefile.inc1 and a Makefile_upgrade.inc, which are the include files and the upgrade logic that the top-level Makefile pulls in, and the presence of the upgrade include is what ties the source tree to the UPDATING file that tells a user what to do by hand.

Hammer, licence and what the mirror does not tell you

The repository topics name bsd, unix, hammer and hammer2, which tells you the two filesystem generations that DragonFly is known for, though the README itself does not describe them and the tree is where you would read that code.

The licence is the part that needs attention. The repository's own classification is a custom licence that GitHub cannot classify, with a pointer to the LICENSE file, and the README's copyright paragraph points to the COPYRIGHT file at the top of the directory and to the specific source directories for more information. Any statement about what you may do with this code therefore has to start by reading those files rather than the metadata, and this is a reading of where to look rather than legal advice.

The mirror is not archived and the last push was on 2026-10-22, so it tracks the current state of the source tree. It publishes no GitHub releases, which follows from what it is: there is no artefact here to release. The homepage is dragonflybsd.org, and the handbook under that site is the documentation the README itself points to for the build procedure.

What a reader gets from this repository is the ability to see a complete operating system source tree with its own build system, and to compile it. What a reader does not get is the project's own history, its release artefacts, or a place to file issues. For those, the dragonflybsd.org site is the place to go.

Editorial conclusion

DragonFlyBSD's source tree suits an engineer who needs to build the system, the kernel or a single component from source on DragonFly hardware, who wants to read how an operating system is laid out, or who wants a specific hammer or hammer2 behaviour traced back to the code that implements it. It is the wrong place to look for a portable library, since almost nothing in the tree is designed to be consumed from outside the system, and the wrong place to look for the authoritative development history, because this is a mirror. Before using it, check the COPYRIGHT file and the per-directory notices, read the build and config man pages before starting a kernel build, and remember that the last push was on 2026-10-22 and that the repository publishes no releases of its own.

Frequently asked questions

Official sources

1. DragonFlyBSD/DragonFlyBSD on GitHub
2. Issues
3. Project website
4. README