\chapter{Porting HURD}


\section{The Architecture of HURD}
\label{arch-hurd}

In order to port HURD, it is necessary to have some
understanding of the structure of HURD.  As has previously
been stated, HURD consists of multiple servers which
cooperate to provide the functionality traditionally
provided by the Unix kernel.  This is not quite true as
some functions are more appropriately provided by the C
library.  I summarise here the HURD servers and their
purpose.

\section{The HURD filesystem}

As in traditional Unix, the filesystem is very important
under HURD.  Devices are represented by special files in
the /dev directory and it is possible to mount filesystems
by using the \hurd{settrans} command, which sets up a
translator\footnote{HURD sometimes refers to servers as
translators when they are being used in this manner} on
a directory.

A choice of two popular filesystems are available for
disc-based filesystems: The \hurd{ext2} filing system that
was developed for Linux by Remy Card and the \hurd{ufs}
filing system which has a BSD heritage.  The \hurd{nfs}
filesystem \cite{nfs} is provided for accessing remote
filesystem servers.  Both the \hurd{ext2} and \hurd{ufs}
servers use the \hurd{storeio} server.  In its turn, the
\hurd{storeio} server communicates with a device directly,
or with a file on a filesystem.  The \hurd{nfs} server
communicates with either the \hurd{pfinet} or the
\hurd{pflocal} servers and could be run over other
protocol families as servers for them become available.

The \hurd{symlink} and \hurd{firmlink} servers are both called
by and subsequently call the filesystem servers in order to
resolve symbolic and firm\footnote{A firm link is a concept
not found in traditional Unix.  It is conceptually half-way
between a soft link and a hard link.} links.  This completes
the view of a traditional Unix filesystem that a process has.
The communications are summarised in Figure~\ref{hurdfs}.

\begin{figure}
\includegraphics*[0mm,0mm][80mm,40mm]{hurdfs.ps}
\caption{Communication between the HURD filesystem components.}
\label{hurdfs}
\end{figure}

\section{HURD Processes}

HURD processes are Mach tasks.  HURD has various servers
which provide process management.  Servers that fall into
this category include \hurd{auth} which handles the privileges
of processes, \hurd{exec} which starts processes and \hurd{proc}
which reports on the status of processes.  The \hurd{crash}
server handles processes which crash; it allows them to be
attached to with a debugger or have images dumped to disc or
simply killed off.

\section{Other servers}

Most of the remaining translators may fairly be filed under
`miscellaneous'.  For example, there is a \hurd{null} server
which provides /dev/null and /dev/zero.  The \hurd{fifo} and
\hurd{new-fifo} translators provide named pipes and the
\hurd{ifsock} server provides a BSD-style sockets interface.

There are also some `toy' servers: \hurd{devport},
\hurd{fwd} and \hurd{magic}.  One might be tempted to
categorise the NFS server task as a server since many
implementations of NFS place the server inside the kernel
in an effort to improve performance, but conceptually it
lies outside the kernel activities in ordinary Unix so I
would consider this wrong.  Of course one of the effects of
breaking the kernel up in this manner is to blur the
distinction between kernel-provided services and user level
services.

\section{Libraries}

The HURD distribution does not just contain servers. Since
GNU wish the kernel to be easily extensible, they have
provided a large number of libraries for programmers to use
in order to help them write servers faster.

For example, the \hurd{ext2fs} server depends on the HURD
libraries \hurd{diskfs}, \hurd{pager}, \hurd{iohelp},
\hurd{fshelp}, \hurd{store}, \hurd{ports}, \hurd{threads},
\hurd{ihash} and \hurd{shouldbeinlibc}.

Some of these libraries do fairly mundane things, for example,
\hurd{libihash} provides an implementation of hash tables.
Since this is supplied with the OS, there is no need for anyone
to write their own implementation.  \hurd{libshouldbeinlibc},
as its name suggests, contains about 40 different functions that
are currently missing from libc but logically belong there.

Many are to do with implementing filing systems: \hurd{diskfs},
\hurd{fshelp}, \hurd{netfs} and \hurd{trivfs} all help in
different ways.  The general idea is that the author of a new
filing system only needs to implement the parts which are
specific to their filing system.

The \hurd{threads} library offers the interface to Mach
CThreads which used to be provided as part of the Mach 4
distribution but is no longer part of the GNUmach distribution.
\hurd{ports} provides a higher level interface to Mach ports.

\hurd{ftpconn} manages ftp connections, \hurd{pager} exists to
help servers act as memory pagers.  This is less specialist than
it sounds; for example with the \func{mmap} function, any
filesystem server is acting as a pager.  \hurd{store} helps tasks
use other servers as pagers.  \hurd{pipe} provides a high-level
communications pipe between two processes.  \hurd{ps} simplifies
obtaining process information.

\section{Other components}

The only remaining things in the HURD distribution are essential
system programs such as \hurd{getty}, \hurd{init}, \hurd{login},
\hurd{ps}, \hurd{settrans}, \hurd{su}, \hurd{vmstat} and so on.
Most of these programs do the same as their counterparts in
conventional Unix distributions, but they have enhancements to
deal with specific HURD concepts.  For example, \hurd{su} handles
multiple simultaneous user IDs whereas Unix only allows a process
to have one UID.  Other programs have similar purpose to a Unix
utility, but have a different name due to the difference syntax
required.  For example, the command which mounts a partition on
the /home directory under Linux is
\begin{verbatim}
mount -t ext2 /dev/hda2 /home
\end{verbatim}
Whereas Under HURD one would use the command
\begin{verbatim}
settrans /home /hurd/ext2fs /dev/hda2
\end{verbatim}

This illustrates the philosophical difference quite nicely: under
Linux, the mount command tells the kernel to mount a filesystem
on /home, of type ext2, that it will find on the block device
/dev/hda2.  The HURD settrans command modifies the /home inode
so that when /home is accessed, it starts a new \hurd{ext2fs}
server with the given parameters.  In this case, \hurd{ext2fs}
will then start up a new \hurd{storeio} server to access the
hda2 block device on its behalf.