docs/developer/devfs/index.mdwn

   1 DragonFly's devfs was developed by Alex Hornung
   2 as a Google Summer of Code 2009 project.
   3 It was proposed here: <http://leaf.dragonflybsd.org/~alexh/devfs.html>.
   4 And is included in the DragonFly 2.4 release (Sept 2009).
   5 It is introduced in the 2.4 release notes at <http://www.dragonflybsd.org/release24/>.
   6
   7 This wikipage discusses some differences of the DragonFly implementation
   8 with FreeBSD's and a little about porting.
   9
  10 The DragonFly devfs implementation is not based at all on FreeBSD's,
  11 and only real similarities will be found in part of the
  12 open/close/read/write/poll/kqueue implementations, as these have
  13 been ripped out in both cases from code pertaining to the common
  14 past (FreeBSD 4).
  15
  16 Some of the major differences are:
  17
  18 ### Major numbers
  19
  20 The DragonFly devfs still uses major numbers (although dynamically
  21 allocated instead of specified by the driver) while FreeBSD has
  22 gotten rid of them altogether.
  23
  24 ### Cloning
  25
  26 The DragonFly implementation only clones on open and provides a
  27 good support infrastructure to make it easy to write clonable device
  28 drivers.  FreeBSD's cloning will already clone on lookup and in
  29 general is a rather poor framework for this.  A disadvantage of
  30 the DragonFly approach is that there's only one base clonable device
  31 (e.g.  /dev/bpf) which, if opened, will clone. In FreeBSD opening
  32 (or actually looking up) a non-existent node like /dev/bpf999 will
  33 create and clone that exact node. This allows for an easier backwards
  34 compatibility when a lot of /dev/bpf* devices existed.
  35
  36 The usual DragonFly approach nowadays for devices that require
  37 knowing which exact device they are allocated is opening the clonable
  38 base device (/dev/bpf) and then calling fdevname() to retrieve the
  39 exact name (e.g. /dev/bpf99).
  40
  41 ### vfs operations
  42
  43 The DragonFly implementation, having been developed for DragonFly,
  44 uses DragonFly-specific vfs operations such as nresolve, nremove,
  45 nsymlink. While these vfs operations make life much easier, they
  46 are not (directly) compatible with the classical lookup, remove
  47 and family, although there is compatibility code available (look
  48 for vop_compat_* in kern/vfs_default.c).
  49
  50 ### Support functions
  51
  52 Overall there are a lot more support functions in the DragonFly
  53 implementation, providing interfaces to easily dispose of devices
  54 with a specific minor, with a specific devops, starting with a
  55 specific string, but these could, if needed, also be added
  56 easily to FreeBSD's code.
  57
  58 ### Rule system
  59
  60 The rule system is vastly different.  Take a look at both manual
  61 pages to get some insight.
  62
  63 ### Porting
  64
  65 Any devfs port in itself will be rather easy. The main difficulty
  66 will lie in fixing all the device drivers to be compatible. Some
  67 major design decisions, such as either removing major numbers or
  68 allocating them dynamically cause a lot of breakage at first. Adding
  69 clone support to drivers which could benefit from it also is a
  70 major effort.
  71