- Mar 14, 2008
Everything Is a File?
Mach used a port as a basic abstraction for communicating, since it wasn’t restricted to UNIX-like behavior. In contrast, HURD aims to be a POSIX-compliant OS. As such, it uses the filesystem as a namespace in which all objects exist. Whenever you open a file in HURD, you get a Mach port to a translator that implements a protocol used for interacting with file-like objects.
This translator mechanism allows some quite neat extensions. Users need no special permissions to mount a filesystem in a directory they own, other than permission to access the underlying storage device. If this device is a physical disk, then the user might need more privileges, but not if it’s a regular file (such as an ISO 9660 image), or a remote server. This setup allows users to mount things like SMB, NFS shares, or even SVN repositories as regular filesystems just by mounting them (in HURD terminology, "setting the translator" with the settrans command). HURD users don’t run a specific FTP program, for example; they just mount the FTP server as they would any other filesystem.
This idea has been taken up in other operating systems. Projects such as FUSE allow filesystem drivers to be run in userspace on monolithic kernels, and many of these systems now include SMB and FTP drivers in kernelspace (a concept considered the height of bloat when HURD was first conceived).
These translators are not limited to filesystem drivers. The IDE driver, which sits under the filesystem drivers, is another example; it exports device nodes in /dev. Other device drivers can have stacked implementations in the same way. For example, a sound card driver might be set as a translator for /dev/dsp. On top of this, a user might set a translator for ~/mp3 that would play any MP3 data written to the file. A more complex translator might be set for ~/playlist, which would send files linked into that directory to ~/mp3 for playing.
Something similar is possible on most *NIX systems with named pipes, but a HURD translator has two key differences. The first is that a translator can represent a directory, while a pipe can’t. The second is that the interface to a translator is a Mach port, and so can be extended trivially to respond to other messages beyond those of the standard filesystem. A similar mechanism is used on other UNIX-like systems with IOCTLs on device nodes; however, these are only available to special files created by the kernel, while HURD translators can be unprivileged processes.
Many of these ideas will be familiar to Plan 9 users.