summaryrefslogtreecommitdiff
path: root/hurd/translator
diff options
context:
space:
mode:
authorThomas Schwinge <tschwinge@gnu.org>2009-06-25 15:01:15 +0200
committerThomas Schwinge <tschwinge@gnu.org>2009-06-25 15:01:15 +0200
commitc838f31395bb2243fa0bf336069f9eef0c0ea912 (patch)
tree4890ec895ee7bc4989c6ac897661cfd449295ab3 /hurd/translator
parentc444a6ecdb7d27ad0af25426abf9c683c3dc68d3 (diff)
hurd/translator/short-circuiting: Add some further details and explanations.
Diffstat (limited to 'hurd/translator')
-rw-r--r--hurd/translator/short-circuiting.mdwn73
1 files changed, 45 insertions, 28 deletions
diff --git a/hurd/translator/short-circuiting.mdwn b/hurd/translator/short-circuiting.mdwn
index 01bd6ccb..064e4abb 100644
--- a/hurd/translator/short-circuiting.mdwn
+++ b/hurd/translator/short-circuiting.mdwn
@@ -8,52 +8,69 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled
[[GNU Free Documentation License|/fdl]]."]]"""]]
-# Translator short-circuiting
-
-In traditional Unix filesystems contain special files. These are:
+In traditional [[Unix]], file systems contain special files. These are:
symbolic links, character devices, block devices, named pipes, and
named sockets. Naturally the Hurd also support these.
However, if you take a look at `hurd/io.defs` and `hurd/fs.defs`, you'll
-find that there are no RPCs that deal specifically with these types.
+find that there are no [[RPC]]s that deal specifically with these types.
Sure, you can get the type of the file through `io_stat` (among other
-things), but there are none that e.g. lets you create a symbolic link.
+things), but there are none that e.g. lets you create a symbolic link.
-If you take a look at how glibc implements `symlink`, you'll notice
-that all it does is create a new file and sets its passive translator to
+If you take a look at how [[glibc]] implements `symlink`, you'll notice
+that all it does is create a new file and set its passive translator to
`/hurd/symlink DEST`. You can verify this yourself by creating a symlink
-with `ln -s foo bar` and print its translator with `showtrans bar`.
+with `ln -s foo bar` and print its passive translator setting with `showtrans
+bar`.
This is how the other special files are implemented as well. The header
`hurd/paths.h` contains a list of paths that are used to implement
special files:
-* `/hurd/symlink`
-* `/hurd/chrdev`
-* `/hurd/blkdev`
-* `/hurd/fifo`
-* `/hurd/ifsock`
+ * `/hurd/symlink`
+ * `/hurd/chrdev`
+ * `/hurd/blkdev`
+ * `/hurd/fifo`
+ * `/hurd/ifsock`
-So all special files implemented through special purpose translators,
-right? Well, actually there are no implementations of either `chrdev` or
-`blkdev` in the Hurd. Instead these are implemented purely by /translator
-short-circuiting/.
+So all special files are implemented through special-purpose translators,
+right? Well, actually there aren't even implementations of either `chrdev` or
+`blkdev` in the Hurd. Instead these are implemented purely by *translator
+short-circuiting*, as well as the others from the above list are, if possible.
-Translator short-circuiting is when a translator, instead of starting a
-passive translator, implements the functionality itself. For instance,
-by continuing a file name look up by simply appending the path of a
-symlink without returning to the client.
+Translator short-circuiting is when a file system server, instead of starting a
+passive translator -- say, for resolving a symbolic link -- implements the
+functionality itself. For instance, by continuing a file name look-up by
+simply appending the path of a symlink's target without returning to the caller
+a `FS_RETRY_*` reply, which is what the [[`symlink`|symlink]] translator would
+do. (And that's all the `symlink` translator ever does, by the way.)
-In fact the translators that are implemented are only used as a default
-implementation if the underlying translator does not implement the
-functionality itself.
+In fact this list's translators that actually are implemented (`symlink`,
+`fifo`, `ifsock`) are only used as a default implementation if the underlying
+file system's translator does not implement the functionality itself, i.e., if
+it doesn't short-circuit it.
-To make sure that you use one of these translators, you can start it as
+To make sure that you use one of these translators, that you bypass the
+short-circuiting mechanism, you can either start it as
an active translator, or you can use a different path from the one in
`hurd/path.h`, e.g. `settrans bar /hurd/./symlink foo`.
The best example of how short-circuiting is implemented can be found
-in `libdiskfs`. Notice how it detects if a translator is a special
-file in `diskfs_S_file_set_translator` and marks the node's `stat`
-structure. And how it later checks the node's `stat` structure in
+in [[`libdiskfs`|libdiskfs]]. Notice how it detects if a translator to store
+is a special file in `diskfs_S_file_set_translator` and (if possible) instead
+of storing a real passive translator setting on the disk, simply has (for
+example) [[`ext2fs`|ext2fs]]' `diskfs_create_symlink_hook` handle this case.
+
+When reading (resolving), it checks the node's `stat` structure in
+`diskfs_S_file_get_translator`, or
`diskfs_S_dir_lookup` and handles special file types appropriately.
+
+Doing this translator short-circuiting has disadvantages: code duplication, or
+in general adding code complexity that isn't needed for implementing the same
+functionality, but it also has advantages: using functionality that the file
+system's data structures nevertheless already provide -- storing symbolic links
+in `ext2fs`' inodes instead of storing passive translator settings -- and thus
+staying compatible with other operating systems mounting that file system.
+Also, this short-circuiting does preserve system resources, as it's no longer
+required to start a `symlink` translator for resolving each symbolic link, as
+well as it does reduce the [[RPC]] overhead.