From c838f31395bb2243fa0bf336069f9eef0c0ea912 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 25 Jun 2009 15:01:15 +0200 Subject: hurd/translator/short-circuiting: Add some further details and explanations. --- hurd/translator/short-circuiting.mdwn | 73 +++++++++++++++++++++-------------- 1 file changed, 45 insertions(+), 28 deletions(-) (limited to 'hurd/translator/short-circuiting.mdwn') 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. -- cgit v1.2.3