Return to README CVS log

Up to [Apple XNU] / XNU / bsd / miscfs / devfs

Annotation of XNU/bsd/miscfs/devfs/README, revision 1.1.1.1

1.1       root        1: Note: The following comments are from the original FreeBSD 3.1 README
                      2: 
                      3: this file is: /sys/miscfs/devfs/README
                      4: 
                      5: to enable: add
                      6: options        DEVFS
                      7: 
                      8: to your config file..
                      9: expect it to be highly useless for a while,
                     10: as the only devices that register themselves are the floppy,
                     11: the pcaudio stuff, speaker, null,mem,zero,io,kmem.
                     12: 
                     13: it works like this:
                     14: 
                     15: There is a tree of nodes that describe the layout of the DEVFS as seen by
                     16: the drivers.. they add nodes to this tree. This is called the 'back' layer
                     17: for reasons that will become obvious in a second. Think of it as a
                     18: BLUEPRINT of the DEVFS tree. Each back node has associated with it 
                     19: a "devnode" struct, that holds information about the device
                     20: (or directory) and a pointer to the vnode if one has been associated 
                     21: with that node. The back node itself can be considered to be 
                     22: a directory entry, and contains the default name of the device,
                     23: and a link to the directory that holds it. It is sometimes refered
                     24: to in the code as the dev_name. The devnode can be considered the inode.
                     25: 
                     26: When you mount the devfs somewhere (you can mount it multiple times in
                     27: multiple places), a front layer is created that contains a tree of 'front'
                     28: nodes.
                     29: 
                     30: Think of this as a Transparency, layed over the top of the blueprint.
                     31: (or possibly a photocopy).
                     32: 
                     33: The front and back nodes are identical in type, but the back nodes
                     34: are reserved for kernel use only, and are protected from the user.
                     35: The back plane has a mount structure and all that stuff, but it is in
                     36: fact not really mounted. (and is thus not reachable via namei).
                     37: Internal kernel routines can open devices in this plane
                     38: even if the external devfs has not been mounted yet :)
                     39: (e.g. to find the root device)
                     40: 
                     41: To start with there is a 1:1 relationship between the front nodes
                     42: and the backing nodes, however once the front plane has been created
                     43: the nodes can be moved around within that plane (or deleted).
                     44: Think of this as the ability to revise a transparency...
                     45: the blueprint is untouched.
                     46: 
                     47: There is a "devnode" struct associated with each front note also.
                     48: Front nodes that refer to devices, use the same "devnode" struct that is used 
                     49: by their associated backing node, so that multiple front nodes that
                     50: point to the same device will use the same "devnode" struct, and through
                     51: that, the same vnode, ops, modification times, flags, owner and group.
                     52: Front nodes representing directories and symlinks have their own
                     53: "devnode" structs, and may therefore differ. (have different vnodes)
                     54: i.e. if you have two devfs trees mounted, you can change the 
                     55: directories in one without changing the other. 
                     56: e.g. remove or rename nodes
                     57: 
                     58: Multiple mountings are like multiple transparencies,
                     59: each showing through to the original blueprint.
                     60: 
                     61: Information that is to be shared between these mounts is stored
                     62: in the 'backing' node for that object.  Once you have erased 'front'
                     63: object, there is no memory of where the backing object was, and
                     64: except for the possibility of searching the entire backing tree
                     65: for the node with the correct major/minor/type, I don't see that
                     66: it is easily recovered.. Particularly as there will eventually be
                     67: (I hope) devices that go direct from the backing node to the driver
                     68: without going via the cdevsw table.. they may not even have
                     69: major/minor numbers.
                     70: 
                     71: I see 'mount -u' as a possible solution to recovering a broken dev tree.
                     72: (though umount+mount would do the same)
                     73: 
                     74: Because non device nodes (directories and symlinks) have their own
                     75: "devnode" structs on each layer, these may have different
                     76: flags, owners, and contents on each layer.
                     77: e.g. if you have a chroot tree like erf.tfs.com has, you
                     78: may want different permissions or owners on the chroot mount of the DEVFS
                     79: than you want in the real one. You might also want to delete some sensitive
                     80: devices from the chroot tree.
                     81: 
                     82: Directories also have backing nodes but there is nothing to stop
                     83: the user from removing a front node from the directory front node.
                     84: (except permissions of course).  This is because the front directory
                     85: nodes keep their own records as to which front nodes are members
                     86: of that directory and do not refer to their original backing node
                     87: for this information.
                     88: 
                     89: The front nodes may be moved to other directories (including
                     90: directories) however this does not break the linkage between the
                     91: backing nodes and the front nodes. The backing node never moves. If
                     92: a driver decides to remove a device from the backing tree, the FS
                     93: code follows the links to all the front nodes linked to that backing
                     94: node, and deletes them, no matter where they've been moved to.
                     95: (active vnodes are redirected to point to the deadfs).
                     96: 
                     97: If a directory has been moved, and a new backing node is inserted
                     98: into its own back node, the new front node will appear in that front
                     99: directory, even though it's been moved, because the directory that
                    100: gets the front node is found via the links and not by name.
                    101: 
                    102: a mount -u might be considered to be a request to 'refresh' the
                    103: plane that controls to the mount being updated.. that would have the
                    104: effect of 're-propogating' through any backing nodes that find they
                    105: have no front nodes in that plane.
                    106: 
                    107: 
                    108: NOTES FOR RELEASE 1.2
                    109: 1/ this is very preliminary
                    110: 2/ the routines have greatly simplified since release 1.1
                    111: (I guess the break did me good :)
                    112: 3/ many features are not present yet..
                    113: e.g. symlinks, a comprehensive registration interface (only a crude one)
                    114: ability to unlink and mv nodes.
                    115: 4/ I'm pretty sure my use of vnodes is bad and it may be 'losing'
                    116: them, or alternatively, corrupting things.. I need a vnode specialist
                    117: to look at this.
                    118: 

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.