diff options
author | phk <phk@FreeBSD.org> | 2000-08-20 21:34:39 +0000 |
---|---|---|
committer | phk <phk@FreeBSD.org> | 2000-08-20 21:34:39 +0000 |
commit | b648921accec69a7e5c83e915ded3037cbca7f3d (patch) | |
tree | fa2e43c05e3c1d31732408f806d72db091c03d14 /sys/miscfs/devfs/README | |
parent | 1c624ac57c791b6df4b51eb86e04dc404052c700 (diff) | |
download | FreeBSD-src-b648921accec69a7e5c83e915ded3037cbca7f3d.zip FreeBSD-src-b648921accec69a7e5c83e915ded3037cbca7f3d.tar.gz |
Remove all traces of Julians DEVFS (incl from kern/subr_diskslice.c)
Remove old DEVFS support fields from dev_t.
Make uid, gid & mode members of dev_t and set them in make_dev().
Use correct uid, gid & mode in make_dev in disk minilayer.
Add support for registering alias names for a dev_t using the
new function make_dev_alias(). These will show up as symlinks
in DEVFS.
Use makedev() rather than make_dev() for MFSs magic devices to prevent
DEVFS from noticing this abuse.
Add a field for DEVFS inode number in dev_t.
Add new DEVFS in fs/devfs.
Add devfs cloning to:
disk minilayer (ie: ad(4), sd(4), cd(4) etc etc)
md(4), tun(4), bpf(4), fd(4)
If DEVFS add -d flag to /sbin/inits args to make it mount devfs.
Add commented out DEVFS to GENERIC
Diffstat (limited to 'sys/miscfs/devfs/README')
-rw-r--r-- | sys/miscfs/devfs/README | 118 |
1 files changed, 0 insertions, 118 deletions
diff --git a/sys/miscfs/devfs/README b/sys/miscfs/devfs/README deleted file mode 100644 index fba4214..0000000 --- a/sys/miscfs/devfs/README +++ /dev/null @@ -1,118 +0,0 @@ -$FreeBSD$ - -this file is: /sys/miscfs/devfs/README - -to enable: add -options DEVFS - -to your config file.. -expect it to be highly useless for a while, -as the only devices that register themselves are the floppy, -the pcaudio stuff, speaker, null,mem,zero,io,kmem. - -it works like this: - -There is a tree of nodes that describe the layout of the DEVFS as seen by -the drivers.. they add nodes to this tree. This is called the 'back' layer -for reasons that will become obvious in a second. Think of it as a -BLUEPRINT of the DEVFS tree. Each back node has associated with it -a "devnode" struct, that holds information about the device -(or directory) and a pointer to the vnode if one has been associated -with that node. The back node itself can be considered to be -a directory entry, and contains the default name of the device, -and a link to the directory that holds it. It is sometimes refered -to in the code as the dev_name. The devnode can be considered the inode. - -When you mount the devfs somewhere (you can mount it multiple times in -multiple places), a front layer is created that contains a tree of 'front' -nodes. - -Think of this as a Transparency, layed over the top of the blueprint. -(or possibly a photocopy). - -The front and back nodes are identical in type, but the back nodes -are reserved for kernel use only, and are protected from the user. -The back plane has a mount structure and all that stuff, but it is in -fact not really mounted. (and is thus not reachable via namei). -Internal kernel routines can open devices in this plane -even if the external devfs has not been mounted yet :) -(e.g. to find the root device) - -To start with there is a 1:1 relationship between the front nodes -and the backing nodes, however once the front plane has been created -the nodes can be moved around within that plane (or deleted). -Think of this as the ability to revise a transparency... -the blueprint is untouched. - -There is a "devnode" struct associated with each front note also. -Front nodes that refer to devices, use the same "devnode" struct that is used -by their associated backing node, so that multiple front nodes that -point to the same device will use the same "devnode" struct, and through -that, the same vnode, ops, modification times, flags, owner and group. -Front nodes representing directories and symlinks have their own -"devnode" structs, and may therefore differ. (have different vnodes) -i.e. if you have two devfs trees mounted, you can change the -directories in one without changing the other. -e.g. remove or rename nodes - -Multiple mountings are like multiple transparencies, -each showing through to the original blueprint. - -Information that is to be shared between these mounts is stored -in the 'backing' node for that object. Once you have erased 'front' -object, there is no memory of where the backing object was, and -except for the possibility of searching the entire backing tree -for the node with the correct major/minor/type, I don't see that -it is easily recovered.. Particularly as there will eventually be -(I hope) devices that go direct from the backing node to the driver -without going via the cdevsw table.. they may not even have -major/minor numbers. - -I see 'mount -u' as a possible solution to recovering a broken dev tree. -(though umount+mount would do the same) - -Because non device nodes (directories and symlinks) have their own -"devnode" structs on each layer, these may have different -flags, owners, and contents on each layer. -e.g. if you have a chroot tree like erf.tfs.com has, you -may want different permissions or owners on the chroot mount of the DEVFS -than you want in the real one. You might also want to delete some sensitive -devices from the chroot tree. - -Directories also have backing nodes but there is nothing to stop -the user from removing a front node from the directory front node. -(except permissions of course). This is because the front directory -nodes keep their own records as to which front nodes are members -of that directory and do not refer to their original backing node -for this information. - -The front nodes may be moved to other directories (including -directories) however this does not break the linkage between the -backing nodes and the front nodes. The backing node never moves. If -a driver decides to remove a device from the backing tree, the FS -code follows the links to all the front nodes linked to that backing -node, and deletes them, no matter where they've been moved to. -(active vnodes are redirected to point to the deadfs). - -If a directory has been moved, and a new backing node is inserted -into its own back node, the new front node will appear in that front -directory, even though it's been moved, because the directory that -gets the front node is found via the links and not by name. - -a mount -u might be considered to be a request to 'refresh' the -plane that controls to the mount being updated.. that would have the -effect of 're-propogating' through any backing nodes that find they -have no front nodes in that plane. - - -NOTES FOR RELEASE 1.2 -1/ this is very preliminary -2/ the routines have greatly simplified since release 1.1 -(I guess the break did me good :) -3/ many features are not present yet.. -e.g. symlinks, a comprehensive registration interface (only a crude one) -ability to unlink and mv nodes. -4/ I'm pretty sure my use of vnodes is bad and it may be 'losing' -them, or alternatively, corrupting things.. I need a vnode specialist -to look at this. - |