page about DevFS, based on private email from Alex Hornung. Used with permission...
authorreed <reed@web>
Fri, 25 Sep 2009 13:12:01 +0000 (06:12 -0700)
committerCharlie <root@leaf.dragonflybsd.org>
Fri, 25 Sep 2009 13:12:01 +0000 (06:12 -0700)
docs/developer/devfs/index.mdwn [new file with mode: 0644]

diff --git a/docs/developer/devfs/index.mdwn b/docs/developer/devfs/index.mdwn
new file mode 100644 (file)
index 0000000..85994a5
--- /dev/null
@@ -0,0 +1,71 @@
+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.
+