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