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
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
|
[[!meta copyright="Copyright © 2009, 2012, 2014 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? Not quite, instead the translators of this list are often
implemented in their underlying filesystem through *translator
short-circuiting*. In fact, `chrdev` and `blkdev` aren't even implemented
as translators at all.
Translator short-circuiting is when a file system server implements the
functionality of a passive translator itself, instead of actually starting
it. For instance, all the [[`symlink`|symlink]] translator does is return
a [[`FS_RETRY_*`|interface/dir_lookup]] reply to the caller.
So instead of starting it, the file
system server can simply continue the file name look-up internally by
appending the target of the symbolic link to the path being looked-up.
This way, we can skip starting the `symlink` translator, skip retrying
the look-up on the newly started translator, and we might also skip a
retry to the same file system server again, if the target of the symbolic
link is in it.
In fact, the 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, there by bypassing the
short-circuiting mechanism, you can either start it as
an active translator, or use a different path from the one in
`hurd/path.h`, e.g. `settrans bar /hurd/./symlink foo`.
There is also a `FS_TRANS_FORCE` flag defined for the `file_set_translator`
RPCs, but it currently isn't set from anywhere.
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 instead
of storing a real passive translator setting on the disk, stores it as a
symlink node (using `diskfs_create_symlink_hook` or a generic implementation).
In later look-ups to the node, 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.
It can also confuse users who expect the passive translator to start.
For instance, if a user notices that [[`symlink`|symlink]]'s code is
lacking some functionality, but that it unexpectedly works when the user
tries to run it.
|
