General Information

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 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 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 servers if you're stressing the RPC part, and on the other hand about translators if you're stressing the filesystem part: a translator implements the fs and ?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.

As a translator is not different from any other user-space application, it can be written in any programming language. The practicable constraint is that an interface suitable for doing RPCs should exist, which currently only exists for C (MIG). For Lisp, Perl, Java there so far are only experimental and incomplete implementations.

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 example about how to write a simple translator.

See some examples about how to use translators.

There is a translator primer.

Marcus Brinkmann has written a document about translators.

Here are some hints about debugging translators available.

Read about translator short-circuiting.

The concept of translators creates its own problems, too: translators set up by untrusted users, and trust the behavior of translators.

Existing Translators

• hello
• auth
• exec
• proc
• pfinet
• eth-filter
• pflocal
• hostmux
• storeio
• ext2fs
• fatfs
• ufs
• magic
• mtab
• unionfs
• nfs
• ?symlink
• firmlink
• fifo
• term
• ...

Translators Being Under Development

• random
• cvsfs
• tmpfs
• procfs
• nsmux
• netio
• socketio
• tarfs
• gopherfs
• smbfs
• ...

Translators (only) in Hurdextras

These Translators are available in the hurdextras repository but not yet described on this website. They are in varying stages of Development.

• jfs
• httpfs
• memfs
• notice
• pith
• pptop
• run
• xmlfs
• mboxfs

Some of the above could be moved from hurdextras to incubator, see the status page.

Translator Wishlists

• network file system by just forwarding RPCs
• libguestfs
• devfs
• emailfs -- email as a filesystem
• general wishlist of stuff not listed above

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.
  

Bounties

There is a FOSS Factory bounty (p280) on some translator improvement tasks.