DragonFly BSD

Last updated

DragonFly BSD
DragonFly BSD Logo.svg
DragonFly BSD 6.2.1 boot loader screenshot.png
DragonFly BSD 6.2.1 UEFI boot loader
Developer Matthew Dillon
OS family Unix-like (BSD)
Working stateCurrent
Source model Open source
Initial release1.0 / 12 July 2004;20 years ago (2004-07-12)
Latest release 6.4.0 / 30 December 2022;22 months ago (2022-12-30) [1]
Repository
Available in English
Package manager pkg
Platforms x86-64
Kernel type Hybrid [2]
Userland BSD
Default
user interface 		Unix shell
License BSD [3]
Official website www.dragonflybsd.org

DragonFly BSD is a free and open-source Unix-like operating system forked from FreeBSD 4.8. Matthew Dillon, an Amiga developer in the late 1980s and early 1990s and FreeBSD developer between 1994 and 2003, began working on DragonFly BSD in June 2003 and announced it on the FreeBSD mailing lists on 16 July 2003. [4]

Contents

Dillon started DragonFly in the belief that the techniques adopted for threading and symmetric multiprocessing in FreeBSD 5 [5] would lead to poor performance and maintenance problems. He sought to correct these anticipated problems within the FreeBSD project. [6] Due to conflicts with other FreeBSD developers over the implementation of his ideas, [7] his ability to directly change the codebase was eventually revoked. Despite this, the DragonFly BSD and FreeBSD projects still work together, sharing bug fixes, driver updates, and other improvements. Dillon named the project after photographing a dragonfly in his yard, while he was still working on FreeBSD.[ citation needed ]

Intended as the logical continuation of the FreeBSD 4.x series, DragonFly has diverged significantly from FreeBSD, implementing lightweight kernel threads (LWKT), an in-kernel message passing system, and the HAMMER file system. [8] Many design concepts were influenced by AmigaOS. [9]

System design

Kernel

The kernel 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. [10]

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. [11]

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. [9]

Threading

As support for multiple instruction set architectures complicates symmetric multiprocessing (SMP) support, [7] DragonFly BSD now limits its support to the x86-64 platform. [12] DragonFly originally ran on the x86 architecture, however as of version 4.0 it is no longer supported. Since version 1.10, DragonFly supports 1:1 userland threading (one kernel thread per userland thread), [13] which is regarded as a relatively simple solution that is also easy to maintain. [9] Inherited from FreeBSD, DragonFly also supports multi-threading. [14]

In DragonFly, each CPU has its own thread scheduler. Upon creation, threads are assigned to processors and 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. [9]

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. [7]

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. [7] 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, with each process operating on a single CPU. Critical sections are used to protect against local interrupts, individually for each CPU, guaranteeing that a thread currently being executed will not be preempted. [13]

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. [15]

DragonFly switched to multiprocessor safe slab allocator, which requires neither mutexes nor blocking operations for memory assignment tasks. [16] It was eventually ported into standard C library in the userland, where it replaced FreeBSD's malloc implementation. [17]

Virtual kernel

Since release 1.8 DragonFly has a virtualization mechanism similar to User-mode Linux, [18] allowing a user 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. [9] [11]

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. [19]

The vkernel runs on top of hardware abstractions provided by the real kernel. These 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. [20]

Package management

Third-party software is available on DragonFly as binary packages via pkgng or from a native ports collection – DPorts. [21]

DragonFly originally used the FreeBSD Ports collection as its official package management system, but starting with the 1.4 release switched to NetBSD's pkgsrc system, which was perceived as a way of lessening the amount of work needed for third-party software availability. [6] [22] Eventually, maintaining compatibility with pkgsrc proved to require more effort than was initially anticipated, so the project created DPorts, an overlay on top of the FreeBSD Ports collection. [23] [24]

CARP support

The initial implementation of Common Address Redundancy Protocol (commonly referred to as CARP) was finished in March 2007. [25] As of 2011, CARP support is integrated into DragonFly BSD. [26]

HAMMER file systems

Alongside the Unix File System, which is typically the default file system on BSDs, DragonFly BSD supports the HAMMER and HAMMER2 file systems. HAMMER2 is the default file system as of version 5.2.0.

HAMMER was developed specifically for DragonFly BSD to provide a feature-rich yet better designed analogue of the increasingly popular ZFS. [9] [11] [27] HAMMER supports configurable file system history, snapshots, checksumming, data deduplication and other features typical for file systems of its kind. [18] [28]

HAMMER2, the successor of the HAMMER file system, is now considered stable, used by default, and the focus of further development. Plans for its development were initially shared in 2012. [29] In 2017, Dillon announced that the next DragonFly BSD version (5.0.0) would include a usable, though still experimental, version of HAMMER2, and described features of the design. [30] With the release after 5.0.0, version 5.2.0, HAMMER2 became the new default file system.

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. [31]

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. [32]

Development and distribution

DragonFly BSD 6.2.1 with Lumina desktop environment DragonFly BSD 6.2.1 Lumina desktop screenshot.png
DragonFly BSD 6.2.1 with Lumina desktop environment

As with FreeBSD and OpenBSD, the developers of DragonFly BSD are slowly replacing pre-function prototype-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. As of 23 July 2005, the kernel is no longer built with this protection by default. [32]

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. [7]

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.

Distribution media

The operating system is distributed as a Live CD and Live USB that boots into a complete DragonFly system. [18] [31] 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 users 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 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 and open-source BSDs, DragonFly is distributed under the terms of the modern version of the BSD license.

Release history

DragonFly BSD
VersionDate [33] Changes
6.430 December 2022
6.2.19 January 2022
  • NVMM ported to DragonFly
  • Added support for growfs to changing the size of an existing HAMMER2 volume.
  • Added xdisk. Remote HAMMER2 disks can be mounted (experimental feature)
  • Imported amdgpu driver, matches Linux 4.19 support.
  • Updated DRM
6.010 May 2021
  • Improved work of 'dsynth' - tool that allow to maintain local DPort repository
  • Removed support of MAP_VPAGETABLE mmap(), as result no 'vkernel' in this release able to work
5.83 March 2020
5.617 June 2019
  • Improved virtual memory system
  • Updates to radeon and ttm
  • Performance improvements for HAMMER2
5.43 December 2018
  • Updated drivers for network, virtual machines & display
  • GCC 8.0 with the previous GCC releases
  • Hammer with more issue fixes
5.210 April 2018
5.016 October 2017
  • New HAMMER2 filesystem
  • Can now support over 900,000 processes on a single machine
  • Improved i915 support
  • IPFW better performance
4.827 March 2017
4.62 August 2016
  • Improved i915 and Radeon support
  • NVM Express support
  • Improved SMP performance
  • Improved network performance
  • Preliminary support for UEFI booting
  • autofs imported from FreeBSD, amd removed
4.47 December 2015
  • GCC 5.2
  • gold now the default linker
  • Improved i915 and Radeon support
  • Complete overhaul of the locale system
  • Collation support for named locales
  • Regex library replaced with TRE
  • Symbol versioning support in libc
  • Numerous HAMMER cleanups and fixes
4.229 June 2015
  • GCC 5.1.1
  • Improved i915 and Radeon support
  • Improved sound support
  • Improved support for memory controller and temperature sensors
  • Path MTU Discovery enabled by default
  • SCTP support removed
  • Sendmail replaced by DMA
  • GNU Info pages removed
4.025 November 2014
  • Non-locking, multi-threading PF
  • Related networking better-threaded for improved throughput
  • Procctl security feature in kernel
  • Support for up to 256 CPUs
  • Improved wireless networking support
  • Rust and Free Pascal now supported
  • i915 support greatly improved
  • GCC 4.7.4
3.84 June 2014
  • Dynamic root and PAM support
  • USB4BSD now default
  • Native C-State support for Intel CPUs
  • TCP port token split for better TCP connect(2) performance
  • GCC 4.7.3
  • HAMMER2 in system ( not ready for production use )
  • Final 32-bit release
3.625 November 2013
  • SMP contention reduction
  • Kernel modesetting for Intel and AMD GPUs
  • Hardware acceleration for Intel GPUs up to Ivy Bridge [34]
3.429 April 2013
  • New package manager, DPorts, introduced
  • GCC 4.7
  • Improved CPU usage and tmpfs performance under extreme load
3.22 November 2012
  • Multiprocessor-capable kernel became mandatory.
  • Performance improvements in the scheduler.
  • USB4BSD imported from FreeBSD.
  • PUFFS imported from NetBSD.
3.022 February 2012
  • Multiprocessor-capable kernel became the default
  • HAMMER performance improvements
  • TrueCrypt-compatible encryption support
  • dm-crypt replaced with a compatible BSD-licensed library
  • Enhanced POSIX compatibility
  • Device driver for ECC memory
  • Major network protocol stack and SMP improvements
  • ACPI-related improvements
2.1026 April 2011
  • Giant lock removed from every area except the virtual memory subsystem
  • HAMMER deduplication
  • GCC 4.4
  • Bridging system rewritten
  • Major performance improvements
2.830 October 2010
2.66 April 2010
  • Swapcache
  • tmpfs imported from NetBSD
  • HAMMER and general I/O improvements
2.416 September 2009
2.217 February 2009
2.020 July 2008
1.1226 February 2008
1.106 August 2007
1.830 January 2007
1.624 July 2006
  • New random number generator
  • IEEE 802.11 framework refactored
  • Major giant lock, clustering, and userland VFS improvements
  • Major stability improvements [36]
1.47 January 2006
1.28 April 2005
1.012 July 2004

See also

Related Research Articles

<span class="mw-page-title-main">Thread (computing)</span> Smallest sequence of programmed instructions that can be managed independently by a scheduler

In computer science, a thread of execution is the smallest sequence of programmed instructions that can be managed independently by a scheduler, which is typically a part of the operating system. In many cases, a thread is a component of a process.

Processor affinity, or CPU pinning or "cache affinity", enables the binding and unbinding of a process or a thread to a central processing unit (CPU) or a range of CPUs, so that the process or thread will execute only on the designated CPU or CPUs rather than any CPU. This can be viewed as a modification of the native central queue scheduling algorithm in a symmetric multiprocessing operating system. Each item in the queue has a tag indicating its kin processor. At the time of resource allocation, each task is allocated to its kin processor in preference to others.

Light Weight Kernel Threads (LWKT) is a computer science term and from DragonFly BSD in particular. LWKTs differ from normal kernel threads in that they can preempt normal kernel threads. According to Matt Dillon, DragonFlyBSD creator:

The LWKT scheduler is responsible for actually running a thread. It uses a fixed priority scheme, but the fixed priorities are differentiating major subsystems, not user processes. For example, hardware interrupt threads have the highest priority, followed by software interrupts, kernel-only threads, then finally user threads. A user thread either runs at user-kernel priority, or a user thread runs at user priority.

DragonFly does preempt, it just does it very carefully and only under particular circumstances. An LWKT interrupt thread can preempt most other threads, for example. This mimics what FreeBSD-4.x already did with its spl/run-interrupt-in-context-of-current-process mechanism. What DragonFly does *NOT* do is allow a non-interrupt kernel thread to preempt another non-interrupt kernel thread.

The mainframe z/OS Operating system supports a similar mechanism, called SRB.

SRB's represent requests to execute a system service routine. SRB's are typically created when one address space detects an event that affects a different address space; they provide one of several mechanisms for asynchronous inter-address space communication for programs running on z/OS.

An SRB is similar to a Process Control Block (PCB), in that it identifies a unit of work to the system. Unlike a PCB, an SRB cannot "own" storage areas. In a multiprocessor environment, the SRB routine, after being scheduled, can be dispatched on another processor and can run concurrently with the scheduling program. The scheduling program can continue to do other processing in parallel with the SRB routine. Only programs running in kernel mode can create an SRB.

The Windows Operating System knows a similar light weight thread mechanism named "fibers". Fibers are scheduled by an application program. The port of the CICS Transaction Server to the Windows platform uses fibers, somewhat analogous to the use of "enclaves" under z/OS.

In UNIX, "kernel threads" have two threads, one is the core thread, one is the user thread.

<span class="mw-page-title-main">Matthew Dillon</span> American software engineer (born 1966)

Matthew Dillon is an American software engineer known for Amiga software, contributions to FreeBSD and for starting and leading the DragonFly BSD project since 2003.

<span class="mw-page-title-main">XNU</span> Computer operating system kernel

XNU is the computer operating system (OS) kernel developed at Apple Inc. since December 1996 for use in the Mac OS X operating system and released as free and open-source software as part of the Darwin OS, which, in addition to being the basis for macOS, is also the basis for Apple TV Software, iOS, iPadOS, watchOS, visionOS, and tvOS.

In computer science, serializing tokens are a concept in concurrency control arising from the ongoing development of DragonFly BSD. According to Matthew Dillon, they are most akin to SPLs, except a token works across multiple CPUs while SPLs only work within a single CPU's domain.

<span class="mw-page-title-main">Native Command Queuing</span>

In computing, Native Command Queuing (NCQ) is an extension of the Serial ATA protocol allowing hard disk drives to internally optimize the order in which received read and write commands are executed. This can reduce the amount of unnecessary drive head movement, resulting in increased performance for workloads where multiple simultaneous read/write requests are outstanding, most often occurring in server-type applications.

The jail mechanism is an implementation of FreeBSD's OS-level virtualisation that allows system administrators to partition a FreeBSD-derived computer system into several independent mini-systems called jails, all sharing the same kernel, with very little overhead. It is implemented through a system call, jail(2), as well as a userland utility, jail(8), plus, depending on the system, a number of other utilities. The functionality was committed into FreeBSD in 1999 by Poul-Henning Kamp after some period of production use by a hosting provider, and was first released with FreeBSD 4.0, thus being supported on a number of FreeBSD descendants, including DragonFly BSD, to this day.

OS-level virtualization is an operating system (OS) virtualization paradigm in which the kernel allows the existence of multiple isolated user space instances, including containers, zones, virtual private servers (OpenVZ), partitions, virtual environments (VEs), virtual kernels, and jails. Such instances may look like real computers from the point of view of programs running in them. A computer program running on an ordinary operating system can see all resources of that computer. Programs running inside a container can only see the container's contents and devices assigned to the container.

Ports collections are the sets of makefiles and patches provided by the BSD-based operating systems, FreeBSD, NetBSD, and OpenBSD, as a simple method of installing software or creating binary packages. They are usually the base of a package management system, with ports handling package creation and additional tools managing package removal, upgrade, and other tasks. In addition to the BSDs, a few Linux distributions have implemented similar infrastructure, including Gentoo's Portage, Arch's Arch Build System (ABS), CRUX's Ports and Void Linux's Templates.

<span class="mw-page-title-main">FreeBSD</span> Free and open-source Unix-like operating system

FreeBSD is a free and open-source Unix-like operating system descended from the Berkeley Software Distribution (BSD). The first version of FreeBSD was released in 1993 developed from 386BSD and the current version runs on IA-32, x86-64, ARM, PowerPC and RISC-V processors. The project is supported and promoted by the FreeBSD Foundation.

In operating systems, a giant lock, also known as a big-lock or kernel-lock, is a lock that may be used in the kernel to provide concurrency control required by symmetric multiprocessing (SMP) systems.

<span class="mw-page-title-main">Berkeley Software Distribution</span> Unix operating system

The Berkeley Software Distribution or Berkeley Standard Distribution (BSD) is a discontinued operating system based on Research Unix, developed and distributed by the Computer Systems Research Group (CSRG) at the University of California, Berkeley. Since the original has become obsolete, the term "BSD" is commonly used for its open-source descendants, including FreeBSD, OpenBSD, NetBSD, and DragonFly BSD.

HAMMER is a high-availability 64-bit file system developed by Matthew Dillon for DragonFly BSD using B+ trees. Its major features include infinite NFS-exportable snapshots, master–multislave operation, configurable history retention, fsckless-mount, and checksums to deal with data corruption. HAMMER also supports data block deduplication, meaning that identical data blocks will be stored only once on a file system. A successor, HAMMER2, was announced in 2011 and became the default in Dragonfly 5.2.

Kqueue is a scalable event notification interface introduced in FreeBSD 4.1 in July 2000, also supported in NetBSD, OpenBSD, DragonFly BSD, and macOS. Kqueue was originally authored in 2000 by Jonathan Lemon, then involved with the FreeBSD Core Team. Kqueue makes it possible for software like nginx to solve the c10k problem. The term "kqueue" refers to its function as a "kernel event queue"

<span class="mw-page-title-main">NetBSD</span> Free and open-source Unix-like operating system

NetBSD is a free and open-source Unix-like operating system based on the Berkeley Software Distribution (BSD). It was the first open-source BSD descendant officially released after 386BSD was forked. It continues to be actively developed and is available for many platforms, including servers, desktops, handheld devices, and embedded systems.

<span class="mw-page-title-main">NextBSD</span> Operating system

NextBSD was an operating system initially based on the trunk version of FreeBSD as of August 2015. It was a fork of FreeBSD which implemented new features developed on branches, but not yet implemented in FreeBSD. As of 2019, the website is defunct, with the last commits on GitHub dating to October 2019. The Wayback Machine captures of the website after December 15, 2017 are domain squatter pages, and as of March 17, 2021, the site is redirects to a fake "Apple Support" page.

HAMMER2 is a successor to the HAMMER filesystem, redesigned from the ground up to support enhanced clustering. HAMMER2 supports online and batched deduplication, snapshots, directory entry indexing, multiple mountable filesystem roots, mountable snapshots, a low memory footprint, compression, encryption, zero-detection, data and metadata checksumming, and synchronization to other filesystems or nodes. It lacks support for extended file attributes ("xattr").

A virtual kernel architecture (vkernel) is an operating system virtualisation paradigm where kernel code can be compiled to run in the user space, for example, to ease debugging of various kernel-level components, in addition to general-purpose virtualisation and compartmentalisation of system resources. It is used by DragonFly BSD in its vkernel implementation since DragonFly 1.7, having been first revealed in September 2006, and first released in the stable branch with DragonFly 1.8 in January 2007.

References

  1. ↑ "DragonFly BSD 6.4". Dragonfly BSD. Retrieved 15 January 2023.
  2. ↑ Dillon, Matthew (22 August 2006), "Re: How much of microkernel?", kernel mailing list, retrieved 14 September 2011
  3. ↑ "DragonFly BSD License", DragonFly BSD, retrieved 17 January 2015
  4. ↑ Dillon, Matthew (16 July 2003), "Announcing DragonFly BSD!", freebsd-current mailing list, retrieved 26 July 2007
  5. ↑ Lehey, Greg (2001), Improving the FreeBSD SMP implementation (PDF), USENIX , retrieved 22 February 2012
  6. 1 2 Kerner, Sean Michael (10 January 2006), "New DragonFly Released For BSD Users", InternetNews, archived from the original on 28 June 2011, retrieved 20 November 2011
  7. 1 2 3 4 5 6 Biancuzzi, Federico (8 July 2004), "Behind DragonFly BSD", O'Reilly Media , archived from the original on 9 April 2014, retrieved 20 November 2011
  8. ↑ Loli-Queru, Eugenia (13 March 2004), "Interview with Matthew Dillon of DragonFly BSD", OSNews , retrieved 22 February 2012
  9. 1 2 3 4 5 6 Chisnall, David (15 June 2007), "DragonFly BSD: UNIX for Clusters?", InformIT , retrieved 22 November 2011
  10. ↑ Hsu, Jeffery M. (13 March 2004). The DragonFly BSD Operating System (PDF). AsiaBSDCon 2004. Taipei, Taiwan. Retrieved 20 November 2011.
  11. 1 2 3 Andrews, Jeremy (6 August 2007), "Interview: Matthew Dillon", KernelTrap , archived from the original on 15 May 2011
  12. ↑ "DragonFly BSD MP Performance Significantly Improved", OSNews , 16 November 2011, retrieved 19 November 2011
  13. 1 2 Luciani, Robert (24 May 2009), M:N threading in DragonflyBSD (PDF), BSDCon, archived from the original (PDF) on 23 December 2010
  14. ↑ Sherrill, Justin (11 January 2004), Paying off already, archived from the original on 30 April 2014, retrieved 20 November 2011
  15. ↑ Pistritto, Joe; Dillon, Matthew; Sherrill, Justin C.; et al. (24 April 2004), "Serializing token", kernel mailing list, archived from the original on 15 April 2013, retrieved 20 March 2012
  16. ↑ Bonwick, Jeff; Adams, Jonathan (3 January 2002), Magazines and Vmem: Extending the Slab Allocator to Many CPUs and Arbitrary Resources, USENIX , retrieved 20 November 2011
  17. ↑ Dillon, Matthew (23 April 2009), "New libc malloc committed", kernel mailing list, retrieved 8 August 2011
  18. 1 2 3 4 Vervloesem, Koen (21 April 2010), "DragonFly BSD 2.6: towards a free clustering operating system", LWN.net , retrieved 19 November 2011
  19. ↑ Economopoulos, Aggelos (16 April 2007), "A peek at the DragonFly Virtual Kernel", LWN.net , no. part 1, retrieved 8 December 2011
  20. ↑ Economopoulos, Aggelos (16 April 2007), "A peek at the DragonFly Virtual Kernel", LWN.net , no. part 2, retrieved 8 December 2011
  21. ↑ "HowTo DPorts", DragonFly BSD, retrieved 2 December 2013
  22. ↑ Weinem, Mark (2007). "10 years of pkgsrc". NetBSD . Joerg Sonnenberger about pkgsrc on DragonFly BSD and his pkgsrc development projects. Retrieved 22 November 2011.
  23. ↑ Sherrill, Justin (30 September 2013), "Why dports?", DragonFly BSD Digest, archived from the original on 30 April 2014, retrieved 2 December 2011
  24. ↑ Sherrill, Justin (29 September 2013), "Any new packages?", users mailing list, retrieved 2 December 2013
  25. ↑ Buschmann, Jonathan (14 March 2007), "First Patch to get CARP on Dfly", kernel mailing list, retrieved 20 November 2011
  26. ↑ "CARP(4) manual page", DragonFly On-Line Manual Pages, retrieved 20 November 2011
  27. ↑ Dillon, Matthew (10 October 2007), "Re: HAMMER filesystem update - design document", kernel mailing list, retrieved 20 November 2011
  28. ↑ Larabel, Michael (7 January 2011), "Can DragonFlyBSD's HAMMER Compete With Btrfs, ZFS?", Phoronix, retrieved 20 November 2011, 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.
  29. ↑ Dillon, Matthew (8 February 2012), "DESIGN document for HAMMER2 (08-Feb-2012 update)", users, retrieved 22 February 2012
  30. ↑ Dillon, Matthew (18 August 2017), "Next DFly release will have an initial HAMMER2 implementation", users, retrieved 3 July 2018
  31. 1 2 Mr (7 January 2010), "DragonFlyBSD with Matthew Dillon", bsdtalk, archived from the original (ogg) on 25 April 2012, retrieved 20 November 2011
  32. 1 2 "DragonFly BSD diary", DragonFly BSD, 7 January 2006, retrieved 19 November 2011
  33. ↑ "DragonFly: Releases", DragonFly BSD, retrieved 19 June 2014
  34. ↑ Tigeot, Francois (31 July 2007), "KMS + i915 support now in -master", users mailing list, retrieved 2 December 2013
  35. ↑ Matthew Dillon (4 June 2009). ""Re: DragonFly-2.3.1.165.g25822 master sys/dev/disk/ahci Makefile TODO ahci.c ahci.h ahci_attach.c ahci_cam.c ahci_dragonfly.c ahci_dragonfly.h atascsi.h"".
  36. 1 2 Kerner, Sean Michael (25 July 2006), "DragonFly BSD 1.6 Cuts the Cord", InternetNews, retrieved 20 November 2011
  37. ↑ Townsend, Trent (18 January 2006), "A Quick Review of DragonFly BSD 1.4", OSNews , retrieved 16 November 2011
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.