DragonFly BSD

"DragonFly" redirects here. For other uses, see Dragonfly (disambiguation).

DragonFly

File:DragonFly BSD Logo.png
Developer	Matthew Dillon
OS family	Unix-like
Working state	Current
Source model	Open source
Latest release	2.10.1 / April 26, 2011 (2011-04-26)
Repository	gitweb.dragonflybsd.org/dragonfly.git
Platforms	IA-32, x86-64
Kernel type	Hybrid
Userland	BSD
Default user interface	tcsh (root) / sh (users)
License	BSD
Official website	http://www.dragonflybsd.org

DragonFly BSD is a free Unix-like operating system created as a fork of FreeBSD 4.8. Matthew Dillon, an Amiga developer in the late 1980s and early 1990s and a FreeBSD developer between 1994 and 2003, began work on DragonFly BSD in June 2003 and announced it on the FreeBSD mailing lists on July 16, 2003.

Dillon started DragonFly in the belief that the methods and techniques being adopted for threading and symmetric multiprocessing in FreeBSD 5 would lead to poor system performance and would cause maintenance difficulties. He sought to correct these suspected problems within the FreeBSD project. Due to ongoing conflicts with other FreeBSD developers over the implementation of his ideas, and other reasons, his ability to directly change the FreeBSD code was eventually revoked. Despite this, the DragonFly BSD and FreeBSD projects still work together contributing bug fixes, driver updates and other system improvements to each other.

Intended to be "the logical continuation of the FreeBSD 4.x series", DragonFly's development has diverged significantly from FreeBSD's, including a new Light Weight Kernel Threads (LWKT) implementation and a light weight ports/messaging system. Many concepts planned for DragonFly were inspired by AmigaOS.

Kernel design

Like most modern kernels, DragonFly is a hybrid, containing features of both monolithic and microkernels, such as the message passing capability of microkernels enabling larger portions of the OS to benefit from protected memory, as well as retaining the speed of monolithic kernels for certain critical tasks. The messaging subsystem being developed is similar to those found in microkernels such as Mach, though it is less complex by design. DragonFly's messaging subsystem has the ability to act in either a synchronous or asynchronous fashion, and attempts to use this capability to achieve the best performance possible in any given situation.

There is progress being made to provide both device input/output (I/O) and virtual file system (VFS) messaging capabilities that will allow the remainder of the project goals to be met. The new infrastructure will allow many parts of the kernel to be migrated out into userland, whereby they will be more easily debugged as they will be smaller, isolated programs, instead of being small parts entwined in a larger chunk of code. The migration of select kernel code into userspace has the additional benefit of making the system more robust; if a userspace driver crashes, it will not crash the kernel.

System calls are being split into userland and kernel versions, as well as being encapsulated into messages. This will help reduce the size and complexity of the kernel by moving variants of standard system calls into a userland compatibility layer, as well as help maintain forwards and backwards compatibility between DragonFly versions. Linux and other Unix-like OS compatibility code is being migrated out similarly. Multiple instances of the 'native' userland compatibility layer created in jails could give DragonFly functionality similar to that found in User Mode Linux (UML). Unlike UML (which is essentially a port of Linux to itself as if the host kernel was a different hardware platform), DragonFly's virtualization will not require special drivers to communicate with the real hardware on the computer.

CPU localization

In DragonFly, threads are locked to CPUs by design, and each processor has its own LWKT scheduler. Threads are never preemptively switched from one processor to another; they are only migrated by the passing of an "inter-processor interrupt" (IPI) message between the CPUs involved. Inter-processor thread scheduling is also accomplished by sending asynchronous IPI messages. One advantage to this clean compartmentalization of the threading subsystem is that the processors' on-board caches in SMP systems do not contain duplicated data, allowing for higher performance by giving each processor in the system the ability to use its own cache to store different things to work on.

The LWKT subsystem is being employed to partition work among multiple kernel threads (for example in the networking code; one thread per protocol per processor), reducing contention by removing the need to share certain resources among various kernel tasks. This thread partitioning implementation of CPU localization algorithms is arguably the key differentiating feature of DragonFly's design.

Protecting shared resources

In order to run safely on multiprocessor machines, access to shared resources (files, data structures etc.) must be serialized so that threads or processes do not attempt to modify the same resource at the same time. In order to prevent multiple threads from accessing or modifying a shared resource simultaneously, DragonFly employs critical sections, and serializing tokens to prevent concurrent access. Whereas both Linux and FreeBSD 5 employ fine-grained mutex models to achieve higher performance on multiprocessor systems, DragonFly does not. Until recently, DragonFly also employed SPLs, but these were replaced with critical sections.

Much of the system's core, including the LWKT subsystem, the IPI messaging subsystem and the new kernel memory allocator, are lockless, meaning that they work without using mutexes, and operate on a per-CPU basis. Critical sections are used to protect against local interrupts and operate on a per-CPU basis, guaranteeing that a thread currently being executed will not be preempted.

Serializing tokens are used to prevent concurrent accesses from other CPUs and may be held simultaneously by multiple threads, ensuring that only one of those threads is running at any given time. Blocked or sleeping threads therefore do not prevent other threads from accessing the shared resource unlike a thread that is holding a mutex. Among other things, the use of serializing tokens prevents many of the situations that could result in deadlocks and priority inversions when using mutexes, as well as greatly simplifying the design and implementation of a many-step procedure that would require a resource to be shared among multiple threads. The serializing token code is evolving into something quite similar to the "Read-copy-update" feature now available in Linux. Unlike Linux's current RCU implementation, DragonFly's is being implemented such that only processors competing for the same token are affected rather than all processors in the computer.

Additional features

Early on in its development, DragonFly acquired a slab allocator, which replaced the aging FreeBSD 4 kernel memory allocator. The new slab allocator requires neither mutexes nor blocking operations for memory assignment tasks and, unlike the code it replaced, is multiprocessor safe. It was eventually ported to be utilized outside the kernel in a replacement to the old userland malloc implementation.

DragonFly uses SFBUFs (Super-Fast BUFfers) and MSFBUFs (Multi-SFBUFs). A SFBUF is used to manage ephemeral single-page mappings and cache them when appropriate. They are used for retrieving a reference to data that is held by a single VM page. This simple, yet powerful, abstraction gives a broad number of abilities, such as zero-copy achieved in the sendfile(2) system call.

SFBUFs are used in numerous parts of the kernel, such as the Vnode Object Pager and the PIPE subsystems (indirectly via XIOs) for supporting high-bandwidth transfers. An SFBUF can only be used for a single VM page; MSFBUFs are used for managing ephemeral mappings of multiple-pages.

The SFBUF concept was devised by David Greenman of the FreeBSD Project when he wrote the sendfile(2) system call; it was later revised by Dr. Alan L. Cox and Matthew Dillon. MSFBUFs were designed by Hiten Pandya and Matthew Dillon.

Development and distribution

DragonFly forked from FreeBSD 4.8 and imports features and bug fixes from FreeBSD 4 and 5 where appropriate, such as ACPI and a new ATA driver framework from FreeBSD 4. As the number of DragonFly developers is currently small, with most of them focused on implementing basic functionality, device drivers are being kept mostly in sync with FreeBSD 5.x, the branch of FreeBSD where all new drivers are being written. The DragonFly developers are slowly moving toward using the "busdma" APIs, which will help to make the system easier to port to new architectures, but it is not a major focus at this time.

As with FreeBSD and OpenBSD, the developers of DragonFly BSD are slowly replacing "K&R" style C code with more modern, ANSI equivalents. Similar to other operating systems, DragonFly's version of the GNU Compiler Collection has an enhancement called the "Stack-Smashing Protector" (formerly known as "ProPolice") enabled by default, providing some additional protection against buffer overflow based attacks. It should be noted that as of 23 July 2005, the kernel is no longer built with this protection by default.

Being a derivative of FreeBSD, DragonFly has inherited an easy-to-use integrated build system that can rebuild the entire base system from source with only a few commands. The DragonFly developers use the Git version control system to manage changes to the DragonFly source code. Unlike its parent FreeBSD, DragonFly will have both stable and unstable releases in a single source tree, due to a smaller developer base.

Like the other BSD kernels (and those of most modern operating systems), DragonFly employs a built-in kernel debugger to help the developers find kernel bugs. Furthermore, as of October 2004, a debug kernel, which makes bug reports more useful for tracking down kernel-related problems, is installed by default, at the expense of a relatively small quantity of disk space. When a new kernel is installed, the backup copy of the previous kernel and its modules are stripped of their debugging symbols to further minimize disk space usage.

The operating system is distributed as a Live CD that boots into a complete DragonFly system. It includes the base system and a complete set of manual pages, and may include source code and useful packages in future versions. The advantage of this is that with a single CD you can install the software onto a computer, use a full set of tools to repair a damaged installation, or demonstrate the capabilities of the system without installing it. Daily snapshots for both i386 and x86-64 architectures are available from the master site via HTTP for those who want to install the most recent versions of DragonFly without building from source.

Like the other free open source BSDs, DragonFly is distributed under the terms of the modern version of the BSD license.

Releases

Version 1.0

DragonFly BSD 1.0, released July 12, 2004, was meant to be a "technology showcase" rather than an integrated production release. It featured the new BSD Installer, the LWKT subsystem and the associated LW ports/messaging system, a mostly MP safe networking stack, lockless memory allocator and the FreeBSD 4.x ports and packages system (which was very briefly broken following the release).

Amiga-style 'resident' application support was added which takes a snapshot of a large, dynamically linked program's virtual memory space after loading, allowing future instances of the program to start much more quickly than it otherwise would have. This replaces the prelinking capability that was being worked on earlier in the project's history, as the resident support is much more efficient. Large programs like those found in KDE with many shared libraries will benefit the most from this support.

Other features introduced in this release include variant symlinks and application checkpointing support.

Due to a serious bug in the installer, an updated 1.0A release of DragonFly was released shortly afterward.

Version 1.2

The second release of DragonFly, on April 8, 2005, contained many bug fixes and new features. New to this release were TCP SACK, ALTQ and PF (OpenBSD's firewall), TLS (thread-local storage) support, DCONS support (console over firewire), IPv6 improvements, and the rewritten namecache infrastructure, which is now distinct from the VFS code, and now capable of allowing the DragonFly developers to implement namecache based security mechanisms.

Like the first release, 1.2 used the FreeBSD ports system for third party packages, but added NetBSD's "pkgsrc" as an option, after modifications allowed it to natively support DragonFly.

Dillon has stated that this would be the last release of DragonFly that employs the MP lock in common code paths.

Version 1.4

The third release of DragonFly was made available on January 7, 2006. Many new drivers and bug fixes were integrated into the system. GCC version 3.4 was now required to build the system, because the older compiler suite would no longer work, due to the increasing use of TLS support. NetBSD's pkgsrc was made the default packaging system, although the buildtools were not yet included in DragonFly's CVS repository. An official set of prebuilt packages made specifically for this release was not available, and many packages (KDE and GNOME most notably) in the pkgsrc snapshot did not build cleanly on the system. Citrus from the NetBSD project was also imported.

Version 1.6

The fourth major release of DragonFly, on July 25, 2006. The biggest user-visible changes in this release were a new random number generator, a massive reorganization of the 802.11 (wireless) framework, and extensive bug fixes in the kernel. It also made significant progress in pushing the big giant lock inward and made extensive modifications to the kernel infrastructure with an eye towards DragonFly's main clustering and userland VFS goals. DragonFly's team considered 1.6 to be more stable than 1.4.

Version 1.8

With the 1.8 release, DragonFly improved several kernel features and implemented a virtual kernel (similar to User Mode Linux or Linux KVM). Version 1.8.1 was released on March 27, 2007, primarily to provide security updates and bugfixes, including to the dynamic loader and virtual kernel.

Version 1.10

DragonFly 1.10 was released on August 6, 2007. New to this release was the near completion of the new userland threading system, and native support for the protocol used by SATA controllers (which was imported from FreeBSD). SMP support for virtual kernels was also enabled as a testbed for the various new multiprocessing features. Additionally many cleanups were done in the disk layer, many wireless drivers, and the USB subsystem. An example of what the improvements in the VFS layer in combination with the USB cleanups allow is that the system is much more stable and unlikely to panic if mounted USB media is suddenly removed. The FreeBSD 4 derived ports system for installing third party applications was also retired. A fairly serious mbuf memory leak was discovered soon after the release and corrected, though there was not an immediate release of a new installation disk. The updated version 1.10.1 was released on August 22, 2007, complete with fixes for the issues in 1.10.0.

Version 1.12

Released on February 26, 2008, DragonFly 1.12 was described as a maintenance update focusing mainly on code cleanups and updates; however, some user visible changes became available. The USB and WiFi stacks were extensively reworked, increasing stability and supporting new hardware. The Hardware Sensors Framework originally developed for the OpenBSD Project was imported (via FreeBSD). SATA ATAPI support for AHCI controllers was also added. An experimental Bluetooth stack was included for testing. The version of GCC used in DragonFly was updated to version 4.1, though the older version was also available. A first version of the DragonFly Mail Agent (called dma), intended as a future replacement for sendmail, was added to the base. Older networking technologies such as ARCnet, FDDI and Token Ring support has been removed. Finally support for the 386 CPU was officially dropped.

Also of note, supporting code for the AMD64 Architecture was added, but the system still did not run in 64-bit mode. From the release notes: "Progress has been made on making more of the kernel MP safe. The network path has a good chance of getting there by the end of the year. The I/O path still needs a lot of work." Preliminary work on the new clustering file system, called HAMMER, was added, but it was not enabled.

Version 2.0

Released on July 21, 2008, DragonFly 2.0 included several bug fixes, support for more devices, and updated userland applications. Its main focus was the first official release of the HAMMER filesystem. 2.0.1 was released on September 27, 2008 with driver updates and minor fixes and updates for HAMMER.

Version 2.2

Released on February 17, 2009, HAMMER is now considered "production-ready", and this version includes "major stability improvements across the board". Besides the CD ISO release, this version has a DVD ISO release with "a fully operational X environment," as well as a bootable USB key image.

Version 2.4

Released on September 16, 2009, DragonFly 2.4 included a DevFS implementation replacing the mechanism for /dev maintenance, recognition of drives by serial number, an updated version of HAMMER, new drivers (including AHCI and SILI support), several bug fixes, performance improvements (including major changes to NFS) and its first distribution for the x86-64 architecture.

Version 2.6

Released on April 6, 2010, DragonFly 2.6 included swapcache, NetBSD's tmpfs port, fast-fsync for HAMMER, improved random I/O between other things.

Version 2.8

Released on October 30, 2010. New Wi-Fi stack from FreeBSD. Updated Packet Filter (pf) from OpenBSD. Device Mapper and Full-disk encryption (cryptsetup) and stripe (RAID0) device-mapper targets. Disk scheduler with fair-share policy. Major work to remove the MP lock.

Version 2.10

Released on 26 April 2011 (2.10.1). Significant work has been done to make the kernel fully MPSAFE that is to say, a complete removal of GIANT. Including the scaling up to 48-way systems, removing contention in a number of code paths such as token acquisition. A significantly larger variety of hardware is supported than previous releases due to major updates in APIC and ACPI interrupt routing support.

Hammer Deduplication

Hammer volumes can now deduplicate volumes overnight in a batch process and during live operation. The 'hammer dedup-simulate' command can be used to estimate space savings for existing data.

Packet Filter (pf)

Pf was updated to a version based upon OpenBSD 4.4. The previous version of pf in DragonFly was based on OpenBSD 4.2.

Compiler updates

DragonFly now uses gcc 4.4 as the default system compiler, and is the first BSD to take that step.

New bridging functionality

The bridging system has been rewritten. Multiple interfaces on a single system can be bound together transparently under a single virtual MAC address, and bandwidth aggregated to that new interface.

MP Performance

The MPLOCK (the primary lock, that when held ensures only a single cpu is operating within the kernel) has been removed from every area except the VM system. DragonFly is one of the few non-academic operating systems to use a primary sychronization mechanism that is not a blocking mutex.

Overall Performance

DragonFly now offers significant performance gains over previous releases, especially for machines using AHCI or implementing swapcache(8).

Version 2.12

Released on ?? 2011 Significant work has been done to the kernel's VM system in regards to MP.

• Updated DRM. Supporting newer AMD ATi Radeon 56xx Evergreen chipsets beyond vesa.
• MMC/SD cards now supported out the box.
• TRIM support for SSD HDD's via GSoC 2011.
• Old out dated EISA ripped out from the kernel.
• HAMMER performance greatly increased. A new time domain multiplexing method has been added to balance storage operation types over long time periods.
• SMP kernel installed by default
• VM MP Work. vm_objects now use per-object tokens and a hold/release based-lock protocol, rather than the global VM token.

Future directions

Supported processors

Currently, DragonFly runs on x86 and x86-64 (Intel and AMD) based computers, both single processor and SMP models.

Package management

DragonFly previously used FreeBSD's Ports system for third party software, but since the 1.4 release, NetBSD's "pkgsrc" is the official package management system. With pkgsrc, the DragonFly developers are largely freed of having to maintain a large number of third party programs while still having access to up to date applications. The pkgsrc developers also benefit from this arrangement as it helps to ensure the portability of the code.

Threading

Since version 1.10, DragonFly supports 1:1 userland threading (one kernel thread for every userland thread). Inherited from FreeBSD, DragonFly also supports SMP multi-threading imported.

Userland VFS and journaling

Userland VFS - the ability to migrate filesystem drivers into userspace, will take a lot of work to accomplish. Some of this work is already complete, though there is still much to do. The namecache code has been extracted from and made independent of the VFS code, and converting the VFS code to DragonFly's threaded messaging interface is Matt's next major focus. This will be more difficult than converting the device I/O and system calls was, due to the fact that the VFS system inherited from FreeBSD uses a massively reentrant model.

The userland VFS system is a prerequisite of a number of desired features to be incorporated into DragonFly. Dillon envisions a new package management system based at least in part, on "VFS environments" which give the packages the environment they expect to be in, independent of the larger filesystem environment and its quirks. In addition to system call message filtering, VFS environments are also to play a role in future security mechanisms, by restricting users or processes to their own isolated environments.

A new journaling layer is being developed for DragonFly for the purpose of transparently backing up entire filesystems in real-time, securely over a network. What remains to be done is the ability to restore a filesystem to a previous state, as well as general stability enhancements. This differs from traditional meta-data journaling filesystems in two ways: (1) it will work with all supported filesystems, as it is implemented in the VFS layer instead of in the individual filesystem drivers, and (2) it will back up all of the data contained on a disk or partition, instead of just meta-data, allowing for the recovery of even the most damaged of installations.

While working on the journaling code, Dillon realized that the userland VFS he envisioned may be closer than he initially thought, though it is still some ways off.

SSI clustering

Ultimately, Dillon wants DragonFly to natively enable "secure anonymous system clustering over the Internet", and the light weight ports/messaging system will help to provide this capability. Security settings aside, there is technically no difference between messages created locally or on another computer over a network. Achieving this "single-system image" capability transparently will be a big job, and will take quite some time to properly implement, even with the new foundation fully in place. While some of the short term goals of the project will be completed in months, other features may take years to complete. SSI clustering will have applications in scientific computing.

See also

• Comparison of BSD operating systems

Further reading

• Biancuzzi, Federico. "Behind DragonFly BSD" on O'Reilly Media Sys Admin, July 8, 2004.
• Bonwick, Jeff; Adams, Jonathan (2001). Magazines and Vmem: Extending the Slab Allocator to Many CPUs and Arbitrary Resources. USENIX 2001.
• Hsu, Jeffery M. "The DragonFly BSD Operating System"
• Kerner, Sean Michael (January 10, 2006). "New DragonFly Released For BSD Users". internetnews.com.
• Kerner, Sean Michael (July 25, 2006). "DragonFly BSD 1.6 Cuts the Cord". internetnews.com.
• Lehey, Greg. "Improving the FreeBSD SMP implementation". USENIX 2001.

External links

• The DragonFly BSD Project home page
• The DragonFly BSD handbook

News and interviews

• The DragonFly BSD Digest
• OSNews interview (13 March 2004)