DragonFlyBSD 2.8 Released

DragonflyBSD 2.8 was just released.  You can download it here.

From the Release Notes:

Big-ticket items

Return of the GUI - The 2.8 release includes a larger 4G USB image with a working X environment and full sources in addition to the standard 700M ISO and 1G USB images.

Crypto support - A cryptsetup compatible cryptographic device mapper target was written for DragonFly. This means that it is now possible to encrypt DragonFly partitions (e.g., HAMMER and UFS). While it is possible to only encrypt any partition like /home/, it is also possible to encrypt the whole root file system. The latter is especially useful for mobile devices. It is also possible to encrypt the swap partition while still being able to dump a kernel core. Further, the code is SMP aware, so expect a speedup if using multi-core machines and don't have cryptographic hardware support.

Packet Filter (pf) - Pf was updated to a version based upon OpenBSD 4.2. The previous version of pf in DragonFly was based on OpenBSD 3.5. This, in addition to laying the ground for further following OpenBSD's implementation, introduced several performance gains: Information like route-to, altq, tags, etc are now stored in the mbuf header directly. This was partially already the case up to DragonFly 2.6, but now the implementation corresponds to OpenBSD's. Furthermore an often unnecessary checksumming was removed, which gains another 10% performance. Also state tables and interface bound states were reimplemented and the pf_test_*() functions where fold into pf_test_rule() to make things clearer. DragonFly-specific additions, support for fairq packet queueing and pickups, have remained intact.

WiFi Stack Update - FreeBSD's WiFi (802.11) network stack has been ported. While not all WiFi drivers have been ported the ability to port drivers from FreeBSD much more easily will allow us to ultimately add support for more and newer WiFi devices in the near future.

MP Performance - The multiprocessor work that has been ongoing in DragonFly is really starting to bear fruit. The MPLOCK (The primary lock, that when held ensures only a single cpu is operating within the kernel) has been pushed back significantly with this release. Most of the frontend code now uses soft tokens instead of the MPLOCK, though for safety these particular soft tokens still acquire the MPLOCK. We will be phasing out the safety feature as work progresses. More importantly, HAMMER now runs with a per-mount lock and has specific optimizations to run 100% MPSAFE in the cached read & stat paths. Much of the system backend including the buffer cache, the networking subsystem (protocol stacks and netif drivers), and the AHCI disk driver are now completely MP-safe and do not acquire the MPLOCK at all. For most intents and purposes the system is running MP-safe. I don't want to sell this short because large portions of the core infrastructure have been MP-safe for years. But now those MP-safe paths for the first time can reach all the way from userland to the device drivers on the backend.