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 16 July 2003.[1]
Dillon started DragonFly in the belief that the methods and techniques being adopted for threading and symmetric multiprocessing in FreeBSD 5[2] would lead to poor system performance and cause maintenance difficulties. He sought to correct these suspected problems within the FreeBSD project.[3] Due to ongoing conflicts with other FreeBSD developers over the implementation of his ideas[4] 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 implementation (LWKT), a light weight ports/messaging system, and feature-rich HAMMER file system.[5] Many concepts planned for DragonFly were inspired by the AmigaOS operating system.[6]
System design
Kernel
DragonFly's kernel 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.[7]
According to developer Matthew Dillon, progress is being made to provide both device input/output (I/O) and virtual file system (VFS) messaging capabilities that will enable the remainder of the project goals to be met. The new infrastructure will allow many parts of the kernel to be migrated out into userspace; here 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. Additionally, the migration of select kernel code into userspace has the benefit of making the system more robust; if a userspace driver crashes, it will not crash the kernel.[8]
System calls are being split into userland and kernel versions and 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, and 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 UML, though DragonFly's virtualization does not require special drivers to communicate with the real hardware on the computer.[6]
Threading
As support for multiple processor architectures complicates symmetric multiprocessing (SMP) support,[4] DragonFly BSD limits its supported platforms to x86 and x86-64, with both single processor and SMP models.[9] Since version 1.10, DragonFly supports 1:1 userland threading (one kernel thread for every userland thread),[10] which is seen as a relatively simple and easy to maintain solution.[6] Inherited from FreeBSD, DragonFly also supports SMP multi-threading imported.[11]
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 Symmetric Multiprocessor 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.[6]
The LWKT subsystem is being employed to partition work among multiple kernel threads (for example in the networking code there is one thread per protocol per processor), reducing competition by removing the need to share certain resources among various kernel tasks.[4]
Shared resources protection
In order to run safely on multiprocessor machines, access to shared resources (like files, data structures) 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. While both Linux and FreeBSD 5 employ fine-grained mutex models to achieve higher performance on multiprocessor systems, DragonFly does not.[4] 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.[10]
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.[12]
DragonFly uses a slab allocator, which requires neither mutexes nor blocking operations for memory assignment tasks and, unlike the code it replaced, is multiprocessor safe.[13] It was eventually ported to be utilized outside the kernel in a replacement to the old userland malloc implementation.[14]
Virtual kernel
Since release 1.8 DragonFly has a new virtualization mechanism similar to UML,[15] allowing to run another kernel in the userland. The virtual kernel (vkernel) is run in completely isolated environment with emulated network and storage interfaces, thus simplifying testing kernel subsystems and clustering features.[6][8]
The vkernel has two important differences from the real kernel: it lacks many routines for dealing with the low-level hardware management and it uses C standard library (libc) functions in place of in-kernel implementations wherever possible. As both real and virtual kernel are compiled from the same code base, this effectively means that platform-dependent routines and re-implementations of libc functions are clearly separated in a source tree.[16]
The virtualized platform vkernel runs on is built on top of high-level abstractions provided by the real kernel. These abstractions include the kqueue-based timer, the console (mapped to the virtual terminal where vkernel is executed), the disk image and virtual kernel ethernet device (VKE), tunneling all packets to the host's tap interface.[17]
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.[18] The pkgsrc developers also benefit from this arrangement as it helps to ensure the portability of the code.[3]
CARP support
The initial implementation of Common Address Redundancy Protocol (commonly referred as CARP) to was finished in March 2007.[19] As of 2011, CARP support is integrated into DragonFly BSD.[20]
HAMMER file system
Alongside the Unix File System, which is typically the default file system on BSDs, DragonFly BSD supports HAMMER file system. It was developed specifically for DragonFly BSD to provide a feature-rich yet better designed analogue of then increasingly popular ZFS.[6][8][21]
HAMMER supports configurable file system history, snapshots, checksumming, data deduplication and other features typical for file systems of its kind.[15] HAMMER is recognised as an interesting perspective and option.[22]
The next generation of HAMMER file system (HAMMER2) is being developed by Dillon, who stated his intent to focus on this project for the whole year 2012. As of 8 February 2012 (2012-02-08)[update], the dedicated branch in DragonFly's source code repository was created. The earliest usable state of the file system is expected by July 2012; the final release is planned for 2013.[23][24]
devfs
In 2007 DragonFly BSD received a new device file system (devfs), which dynamically adds and removes device nodes, allows accessing devices by connection paths, recognises drives by serial numbers and removes the need for pre-populated /dev file system hierarchy. It was implemented as a Google Summer of Code 2009 project.[25]
Application snapshots
DragonFly BSD supports Amiga-style resident applications feature: it 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 Software Compilation with many shared libraries will benefit the most from this support.[26]
Development and distribution
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 (ProPolice) enabled by default, providing some additional protection against buffer overflow based attacks. It should be noted that as of 23 July 2005 (2005-07-23)[update], the kernel is no longer built with this protection by default.[26]
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 has both stable and unstable releases in a single source tree, due to a smaller developer base.[4]
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[update], 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.
Distribution media
The operating system is distributed as a Live CD and Live USB (full X11 flavour available) that boots into a complete DragonFly system.[15][25] 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 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.
Release history
|
| 3.2 | 02012-11-022 November 2012 | - Multiprocessor-capable kernel became mandatory.
- Performance improvements in the scheduler.
- USB4BSD ported from FreeBSD providing USB 3.0 support.
- PUFFS brought in from NetBSD.
|
|---|
| 3.0 | 02012-02-2222 February 2012 | - multiprocessor-capable kernel became the default
- HAMMER performance improvements
- TrueCrypt-compatible encryption support
- dm-crypt replaced with compatible BSD-licensed library
- enhanced POSIX compatibility
- device driver for ECC memory
- major network protocol stack and SMP improvements
- ACPI-related improvements
|
|---|
| 2.10 | 02011-04-2626 April 2011 | - Giant lock removed from every area except the virtual memory subsystem
- HAMMER deduplication
- GCC 4.4
- bridging system rewritten
- significant performance improvements
|
|---|
| 2.8 | 02010-10-3030 October 2010 | |
|---|
| 2.6 | 02010-04-066 April 2010 | - swapcache
- tmpfs ported from NetBSD
- HAMMER and general I/O improvements
|
|---|
| 2.4 | 02009-09-1616 September 2009 | |
|---|
| 2.2 | 02009-02-1717 February 2009 | - HAMMER officially production-ready[15]
- major stability improvements
- new release media: LiveDVD and LiveUSB
|
|---|
| 2.0 | 02008-07-2020 July 2008 | - major HAMMER improvements
|
|---|
| 1.12 | 02008-02-2626 February 2008 | - OpenBSD's hardware sensors framework imported from FreeBSD
- Bluetooth stack
- GCC 4.1
- DragonFly Mail Agent
- support for the 386 CPU dropped
- preliminary x86-64 support (not functional)
- experimental HAMMER support
|
|---|
| 1.10 | 02007-08-066 August 2007 | - userland threading system
- Advanced Host Controller Interface support
- GUID Partition Table support
|
|---|
| 1.8 | 02007-01-3030 January 2007 | - virtual kernel implementation
|
|---|
| 1.6 | 02006-07-2424 July 2006 | - new random number generator
- IEEE 802.11 framework refactored
- major giant lock, clustering and userland VFS improvements
- major stability improvements[28]
|
|---|
| 1.4 | 02006-01-077 January 2006 | - GCC 3.4
pkgsrc used by default[28]- Citrus imported from the NetBSD[29]
|
|---|
| 1.2 | 02005-04-088 April 2005 | - TCP SACK
- TCP Performance tuning
- ALTQ and PF
- thread-local storage
- Console over IEEE 1394
- Namecache infrastructure rewritten
- X11 support
pkgsrc support
|
|---|
| 1.0 | 02004-07-1212 July 2004 | - technology showcase
- new BSD Installer
- LWKT subsystem and lightweight ports/messaging system
- mostly MP safe networking stack
- lockless memory allocator
- variant symlinks
- application checkpointing support.[4]
|
|---|
See also
References
- ^ Dillon, Matthew (16 July 2003), "Announcing DragonFly BSD!", freebsd-current mailing list, http://lists.freebsd.org/pipermail/fr eebsd-current/2003-July/006889.html, retrieved 2007-07-26
- ^ Lehey, Greg (2001) (pdf), Improving the FreeBSD SMP implementation, USENIX, http://www.lemis.com/~grog/SMPng/USEN IX/paper.pdf, retrieved 2012-02-22
- ^ a b Kerner, Sean Michael (10 January 2006), "New DragonFly Released For BSD Users", InternetNews, http://www.internetnews.com/dev-news/ article.php/3576426, retrieved 2011-11-20
- ^ a b c d e f Biancuzzi, Federico (8 July 2004), "Behind DragonFly BSD", O'Reilly Media, http://www.onlamp.com/pub/a/bsd/2004/ 07/08/dragonfly_bsd_interview.html, retrieved 2011-11-20
- ^ Loli-Queru, Eugenia (13 March 2004), "Interview with Matthew Dillon of DragonFly BSD", OSNews, http://www.osnews.com/story.php?news_ id=6338, retrieved 2012-02-22
- ^ a b c d e f Chisnall, David (15 June 2007), "DragonFly BSD: UNIX for Clusters?", InformIT, http://www.informit.com/articles/arti cle.aspx?p=766375, retrieved 2011-11-22
- ^ Hsu, Jeffery M. (pdf), The DragonFly BSD Operating System, http://people.freebsd.org/~hsu/papers /dragonflybsd.asiabsdcon04.pdf, retrieved 2011-11-20
- ^ a b c Andrews, Jeremy (6 August 2007), "Interview: Matthew Dillon", KernelTrap, archived from the original on 15 May 2011, http://www.kerneltrap.org/node/14116
- ^ "DragonFly BSD MP Performance Significantly Improved", OSNews, 16 November 2011, http://www.osnews.com/story/25334/Dra gonFly_BSD_MP_Performance_Significant ly_Improved, retrieved 2011-11-19
- ^ a b Luciani, Robert (24 May 2009) (pdf), M:N threading in DragonflyBSD, BSDCon, archived from the original on 23 December 2010, http://web.archive.org/web/2010122300 4617/http://www.dcbsdcon.org/speakers /slides/luciani_dcbsdcon2009.pdf
- ^ Sherrill, Justin (11 January 2004), Paying off already, http://www.shiningsilence.com/dbsdlog /2004/01/11/194.html, retrieved 2011-11-20
- ^ Pistritto, Joe; Dillon, Matthew; Sherrill, Justin C. et al. (24 April 2004), "Serializing token", kernel mailing list, http://thread.gmane.org/gmane.os.drag onfly-bsd.kernel/4436, retrieved 2012-03-20
- ^ Bonwick, Jeff; Adams, Jonathan (3 January 2002), Magazines and Vmem: Extending the Slab Allocator to Many CPUs and Arbitrary Resources, USENIX, http://www.usenix.org/event/usenix01/ bonwick.html, retrieved 2011-11-20
- ^ Dillon, Matthew (23 April 2009), "New libc malloc committed", kernel mailing list, http://leaf.dragonflybsd.org/mailarch ive/kernel/2009-04/msg00021.html, retrieved 2011-08-08
- ^ a b c d Vervloesem, Koen (21 April 2010), "DragonFly BSD 2.6: towards a free clustering operating system", LWN.net, http://lwn.net/Articles/384200/, retrieved 2011-11-19
- ^ Economopoulos, Aggelos (16 April 2007), "A peek at the DragonFly Virtual Kernel", LWN.net (part 1), http://lwn.net/Articles/228404/, retrieved 2011-12-08
- ^ Economopoulos, Aggelos (16 April 2007), "A peek at the DragonFly Virtual Kernel", LWN.net (part 2), http://lwn.net/Articles/230658/, retrieved 2011-12-08
- ^ Weinem, Mark (2007), Joerg Sonnenberger about pkgsrc on DragonFly BSD and his pkgsrc development projects., "10 years of pkgsrc", NetBSD, http://www.netbsd.org/gallery/10years .html#sonnenberger, retrieved 2011-11-22
- ^ Buschmann, Jonathan (14 March 2007), "First Patch to get CARP on Dfly", kernel mailing list, http://leaf.dragonflybsd.org/mailarch ive/kernel/2007-03/msg00033.html, retrieved 2011-11-20
- ^ "CARP(4) manual page", DragonFly On-Line Manual Pages, http://leaf.dragonflybsd.org/cgi/web- man?command=carp§ion=4, retrieved 2011-11-20
- ^ Dillon, Matthew (10 October 2007), "Re: HAMMER filesystem update - design document", kernel mailing list, http://leaf.dragonflybsd.org/mailarch ive/kernel/2007-10/msg00008.html, retrieved 2011-11-20
- ^ Larabel, Michael (7 January 2011), "Can DragonFlyBSD's HAMMER Compete With Btrfs, ZFS?", Phoronix, http://www.phoronix.com/scan.php?page =article&item=dragonfly_hammer, retrieved 2011-11-20, "HAMMER does appear to be a very interesting BSD file-system. It is though not quite as fast as the ZFS file-system on BSD, but this is also an original file-system to the DragonFlyBSD project rather than being a port from OpenSolaris. Not only is HAMMER generally faster than the common UFS file-system, but it also has a much greater feature-set."
- ^ Dillon, Matthew (8 February 2012), "DESIGN document for HAMMER2 (08-Feb-2012 update)", users, http://leaf.dragonflybsd.org/mailarch ive/users/2012-02/msg00020.html, retrieved 2012-02-22
- ^ Dillon, Matthew (8 February 2012), "hammer2 branch in dragonfly repo created - won't be operational for 6-12 months.", users mailing list, http://leaf.dragonflybsd.org/mailarch ive/users/2012-02/msg00019.html, retrieved 2012-02-22
- ^ a b Mr (7 January 2010), "DragonFlyBSD with Matthew Dillon" (ogg), bsdtalk, http://cisx1.uma.maine.edu/~wbackman/ bsdtalk/bsdtalk184.ogg, retrieved 2011-11-20
- ^ a b "DragonFly BSD diary", DragonFly BSD, 7 January 2006, http://www.dragonflybsd.org/diary/, retrieved 2011-11-19
- ^ "DragonFly: Releases", DragonFly BSD, http://www.dragonflybsd.org/releases/, retrieved 2011-11-22
- ^ a b Kerner, Sean Michael (25 July 2006), "DragonFly BSD 1.6 Cuts the Cord", InternetNews, http://www.internetnews.com/dev-news/ article.php/3622406, retrieved 2011-11-20
- ^ Townsend, Trent (18 January 2006), "A Quick Review of DragonFly BSD 1.4", OSNews, http://www.osnews.com/story/13352/A_Q uick_Review_of_DragonFly_BSD_1_4, retrieved 2011-11-16
|
|---|
| | | Amiga technologies | |
|---|
| | | Amiga GUIs | |
|---|
| | | File systems | |
|---|
| | | OS versions | | 68k-based | - 1.0, 1.1, 1.2, 1.3, 1.4 (beta)
- 2.0, 2.04, 2.05, 2.1
- 3.0, 3.1, 3.5, 3.9
|
|---|
| | | PowerPC-based | |
|---|
|
|---|
| | | Software packs | |
|---|
| | | Other software | |
|---|
| | | Influenced | |
|---|
|
