devfs
DragonFly's devfs was developed by Alex Hornung as a Google Summer of Code 2009 project. It was proposed here: http://leaf.dragonflybsd.org/~alexh/devfs.html. And is included in the DragonFly 2.4 release (Sept 2009). It is introduced in the 2.4 release notes at http://www.dragonflybsd.org/release24/.
This wikipage discusses some differences of the DragonFly implementation with FreeBSD's and a little about porting.
The DragonFly devfs implementation is not based at all on FreeBSD's, and only real similarities will be found in part of the open/close/read/write/poll/kqueue implementations, as these have been ripped out in both cases from code pertaining to the common past (FreeBSD 4).
Some of the major differences are:
Major numbers
The DragonFly devfs still uses major numbers (although dynamically allocated instead of specified by the driver) while FreeBSD has gotten rid of them altogether.
Cloning
The DragonFly implementation only clones on open and provides a good support infrastructure to make it easy to write clonable device drivers. FreeBSD's cloning will already clone on lookup and in general is a rather poor framework for this. A disadvantage of the DragonFly approach is that there's only one base clonable device (e.g. /dev/bpf) which, if opened, will clone. In FreeBSD opening (or actually looking up) a non-existent node like /dev/bpf999 will create and clone that exact node. This allows for an easier backwards compatibility when a lot of /dev/bpf* devices existed.
The usual DragonFly approach nowadays for devices that require knowing which exact device they are allocated is opening the clonable base device (/dev/bpf) and then calling fdevname() to retrieve the exact name (e.g. /dev/bpf99).
vfs operations
The DragonFly implementation, having been developed for DragonFly, uses DragonFly-specific vfs operations such as nresolve, nremove, nsymlink. While these vfs operations make life much easier, they are not (directly) compatible with the classical lookup, remove and family, although there is compatibility code available (look for vop_compat_* in kern/vfs_default.c).
Support functions
Overall there are a lot more support functions in the DragonFly implementation, providing interfaces to easily dispose of devices with a specific minor, with a specific devops, starting with a specific string, but these could, if needed, also be added easily to FreeBSD's code.
Rule system
The rule system is vastly different. Take a look at both manual pages to get some insight.
Porting
Any devfs port in itself will be rather easy. The main difficulty will lie in fixing all the device drivers to be compatible. Some major design decisions, such as either removing major numbers or allocating them dynamically cause a lot of breakage at first. Adding clone support to drivers which could benefit from it also is a major effort.