"1.10 has been branched," DragonFlyBSD creator Matt Dillon announced, noting that the official release is expected soon, "no release date has been set yet but this coming weekend is looking real good now." Among the new features of DragonFly 1.10 are improved virtual kernel support, a new disk management infrastructure, improvements to wireless networking, and support for the new syslink protocol.

DragonFlyBSD has a stable release every six months. The current development branch is numbered 1.11, with the next stable release at the end of the year numbered 2.0. The 1.10 release has been delayed about a week while some final bugs were addressed. Matt noted:

"The 1.10 release is looking a lot better now. We are basically just waiting for a new pkgsrc bootstrap kit and a little more testing. All major issues except booting a machine with a USB root with EHCI loaded have been resolved."

DragonFlyBSD founder Matthew Dillon [interview] posted an update on his syslink protocol which he defined as, "a message based protocol that can devolve down into almost direct procedure calls when two localized resources talk to each other." The syslink API will be used to talk to both local resources on the same node as well as to remote resources on a different node. Earlier documentation further explained the networking nature of the protocol, "the Syslink protocol is used to glue the cluster mesh together. It is based on the concept of reliable packets and buffered streams. Adding a new node to the mesh is as simple as obtaining a stream connection to any node already in the mesh, or tying into a packet switch with UDP." In another email Matthew explained how various DragonFlyBSD nodes utilize Syslink to automatically establish the optimal physical route.

In his recent email, Matthew described the latest Syslink issue he has solved, "in order to transport requests across a machine boundary (that is, outside the domain of a direct memory access), it is necessary to assign a unique identifier to the resource." He detailed how he had originally planned to rework dozens of major system structures to use the syslink API, but instead will now "rework JUST the reference counting methodology used in these resource structures." The end result is "a common ref counting API and a little structure that includes a 64 bit unique sysid, red-black tree node, the ref count, and a pointer to a resource type structure (e.g. identifying it as a vnode, vm object, or whatever). When any of the above resources are allocated, they will be indexed in a Red-Black tree. In other words it will be possible to identify every single resource in the system by traversing the red-black tree". He goes on to summarize, "and that, folks, gives us the building blocks we need to represent resources in a cluster. This also means I don't have to rewrite the APIs. Instead I can simply write new RPC APIs for accesses made via syslink ids and, poof, now all of a system's resources will become accessible remotely, with only modest effort."