summaryrefslogtreecommitdiff
path: root/hurd/translator/short-circuiting.mdwn
blob: 064e4abbe1d29073cfe705c888521cad3640743c (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
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]]."]]"""]]

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 [[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.

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 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`

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 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 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, 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`|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.