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
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
|
[[!meta copyright="Copyright © 2007, 2008, 2009, 2010 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]]."]]"""]]
A translator is simply a normal program acting as
an object server and participating in the Hurd's
distributed [[virtual_file_system]]. It is so-called
because it typically exports a file system
(although need not: cf. [[auth]], [[proc]]
and [[pfinet]]) and thus translates object invocations
into calls appropriate for the backing store
(e.g., ext2 file system, nfs server, etc.).
Another way of putting it is that it translates from one representation of a
data structure into another representation, for example from the on-disk
[[ext2|ext2fs]] data layout to a traditional file system hierarchy, or from a
XML file to a virtual hierarchical manifestation. This translation can be a
bidirectional process, but it need not be.
A translator is usually registered with a specific file system node by using
the [[`settrans`|settrans]] command.
Translators do not require any special privilege
to run. The privilege they require is simply
that to access the indiviudal resources they use.
This is primarily the [[backing_store]] and the node
they attach to. Typically, a translator can
only be attached to a node by the node's owner.
On [[Unix]] this is not possible because file systems
and the virtual file system are implemented in the
kernel and thus have absolute access to the machine.
As the protocols do not require any special privilege
to implement, this is not an issue on the Hurd.
In Mach parlance, a *translator* is what they name a *server*: a process that
participates in [[RPC]] interactions. In the Hurd, a translator is a server
that is additionally attached to a filesystem node. Thus, it is quite common,
even in the Hurd context, to speak about *server*s if you're stressing the RPC
part, and on the other hand about *translator*s if you're stressing the
filesystem part: a translator implements the [[interface/fs]] and
[[interface/io]] interfaces. For example: *the [[pfinet]] server implements
the socket API calls (which are mapped by [[glibc]] to equivalent RPC calls)*,
compared to *a [[libdiskfs]]-based translator implements a filesystem, based on
a backing store*.
To learn how to write a translator, read the code!
It is well documented, in particular, the header files.
The [[Hurd_Hacking_Guide]] also has a tutorial.
Also there is an [[writing/example]] about how to write a simple translator.
See some [[examples]] about how to use translators.
Marcus Brinkmann has written a document about [[documentation/translators]].
Here are some [[hints_about_debugging_translators|debugging/translator]]
available.
Read about translator [[short-circuiting]].
# Existing Translators
* [[auth]]
* [[exec]]
* [[pfinet]]
* [[pflocal]]
* [[hostmux]]
* [[storeio]]
* [[ext2fs]]
* [[fatfs]]
* [[magic]]
* [[unionfs]]
* ...
# Translators Being Under Development
* [[random]]
* [[emailfs]] -- email as a filesystem
* [[cvsfs]]
* [[tmpfs]]
* [[procfs]]
* [[nsmux]]
* nfs -- easily mount nfs anywhere. See /hurd/nfs
* ...
# Translators (only) in Hurdextras
*These Translators are available in the [hurdextras repository](http://savannah.nongnu.org/cvs/?group=hurdextras) but not yet described on this website. They are in varying stages of Development.*
* [jfs](http://www.nongnu.org/hurdextras/#jfs)
* [httpfs](http://www.nongnu.org/hurdextras/#httpfs)
* [gopherfs](http://www.nongnu.org/hurdextras/#cvsfs)
* [memfs](http://www.nongnu.org/hurdextras/#gopherfs)
* [netio](http://www.nongnu.org/hurdextras/#netio)
* [notice](http://www.nongnu.org/hurdextras/#notice)
* [pith](http://www.nongnu.org/hurdextras/#pith)
* [pptop](http://www.nongnu.org/hurdextras/#pptop)
* [run](http://www.nongnu.org/hurdextras/#run)
* [smbfs](http://www.nongnu.org/hurdextras/#smbfs)
* [tarfs](http://www.nongnu.org/hurdextras/#tarfs)
* [xmlfs](http://www.nongnu.org/hurdextras/#xmlfs)
* [mboxfs](http://www.nongnu.org/hurdextras/#mboxfs)
# Translator Wishlists
* [[wishlist_1]]
* [[wishlist_2]]
# Internally
## `*_demuxer` Functions
* IRC, unknown channel, unknown date
<jim-crow> what is a main idea of _demuxer functions in translators?
<neal> jim-crow: Think of a web server.
<neal> jim-crow: A typical web server must process many different requests.
<neal> jim-crow: There are different types of requests.
<neal> jim-crow: For instance, static pages and dynamically gnereated content.
<neal> the static pages are processed by one function
<neal> and the dynamic pages by another
<neal> the thing that makes the decision which of these functions to pass the request to is the demuxer.
<jim-crow> neal: ok, I see
<jim-crow> but what is actually it doing in trivfs_demuxer?
<neal> it looks at the message id and calls the right server stub
<jim-crow> for example it calls trivfs_io_server function, but I can't find its implementation
<jim-crow> that's my main question :-)
<neal> look at the files mig generates
<jim-crow> neal: ok, thanks
<jim-crow> neal: is this functions where actually stubs are called?
<neal> I think so.
|
