Editing GNU Hurd (section)

== Architecture ==
[[File:OS-structure2.svg|thumb|600px|General structure of monolithic, microkernel and hybrid kernel-based operating systems, respectively.]]

Unlike most [[Unix-like]] kernels, the Hurd uses a [[server–client architecture]], built on a [[microkernel]] that is responsible for providing the most basic [[kernel service]]s – coordinating access to the [[Computer hardware|hardware]]: the [[Central processing unit|CPU]] (through [[process management (computing)|process management]] and [[scheduling (computing)|scheduling]]), [[Random access memory|RAM]] (via [[memory management]]), and other various [[input/output]] devices (via [[I/O scheduling]]) for sound, graphics, mass storage, etc. In theory, the microkernel design would allow for all device drivers to be built as servers working in [[user space]], but today most drivers of this kind are still contained in the [[GNU Mach]] [[kernel space]].<ref name="device-drivers-in-mach" />

According to Hurd developers, the main advantage of microkernel-based design is the ability to extend the system: developing a new module would not require in depth knowledge of the rest of the kernel, and a bug in one module would not crash the entire system. Hurd provides a concept of ''translators'', a framework of modules used to extend a file system functionality.<ref name="Doeppner2010">{{cite book |last=Doeppner |first=Thomas W. |date=20 December 2010 |title=Operating Systems In Depth: Design and Programming |publisher=John Wiley & Sons |isbn=978-0-471-68723-8 |page=160 |url=https://books.google.com/books?id=xX5tfrAQQ8cC |access-date=29 November 2012 }}</ref>

From early on, the Hurd was developed to use [[GNU Mach]] as the microkernel. This was a technical decision made by [[Richard Stallman]], who thought it would speed up the work by saving a large part of it. He has admitted that he was wrong about that.<ref name="lt-defence-rh" /> Other Unix-like systems working on the [[Mach kernel|Mach microkernel]] include [[OSF/1]], [[Lites]], and [[MkLinux]]. [[macOS]] and [[NeXTSTEP]] use [[hybrid kernel]]s based on Mach.

=== Other microkernels ===
From 2004 onward, various efforts were launched to port the Hurd to more modern microkernels. The [[L4 microkernel family|L4 microkernel]] was the original choice in 2004, but progress slowed to a halt. Nevertheless, during 2005, Hurd developer Neal Walfield finished the initial memory management framework for the L4/Hurd port, and Marcus Brinkmann ported essential parts of [[glibc]]; namely, getting the process startup code working, allowing programs to run, thus allowing the first user programs (trivial ones such as the [[hello world program]]) in C to run.

Since 2005, Brinkmann and Walfield started researching [[EROS (microkernel)|Coyotos]] as a new kernel for HURD.<ref name="shapiro-comment" /><ref name="l4-and-coyotos-mess" /> In 2006, Brinkmann met with Jonathan Shapiro (a primary architect of the Coyotos Operating System) to aid in and discuss the use of the Coyotos kernel for GNU/Hurd. In further discussion HURD developers realised that Coyotos (as well as other similar kernels) are not suitable for HURD.<ref>{{cite web | url = https://www.gnu.org/software/hurd/history/port_to_another_microkernel.html | title = Porting the Hurd to another microkernel | access-date = 2017-05-06 | publisher = Free Software Foundation | website = GNU Hurd }}</ref>

In 2007, Hurd developers Neal Walfield and Marcus Brinkmann gave a critique of the Hurd architecture, known as "the critique",<ref name="critique-mach" /> and a proposal for how a future system may be designed, known as "the position paper".<ref name="position-paper" /> In 2008, Neal Walfield began working on the Viengoos microkernel as a modern native kernel for HURD. {{as of|2009}}, development on Viengoos is paused due to Walfield lacking time to work on it.<ref name="viengoos" />

In the meantime, others have continued working on the Mach variant of Hurd.<ref name="what-happend-l4-coyotos" />

=== Unix extensions ===
{{Unreferenced section|date=March 2007}}

A number of traditional Unix concepts are replaced or extended in the Hurd.

Under Unix, every running program has an associated [[user id]], which normally corresponds to the user that started the [[process (computing)|process]]. This id largely dictates the actions permitted to the program. No outside process can change the user id of a running program. A Hurd process, on the other hand, runs under a ''set'' of user ids, which can contain multiple ids, one, or none. A sufficiently privileged process can add and remove ids to another process. For example, there is a password server that will hand out ids in return for a correct login password.

Regarding the [[file system]], a suitable program can be designated as a ''translator'' for a single file or a whole directory hierarchy. Every access to the translated file, or files below a hierarchy in the second case, is in fact handled by the program. For example, a file translator may simply redirect read and write operations to another file, like a Unix [[symbolic link]]. The effect of Unix ''[[mount (computing)|mounting]]'' is achieved by setting up a filesystem translator (using the "settrans" command). Translators can also be used to provide services to the user. For example, the [[ftpfs]] translator allows a user to encapsulate remote FTP sites within a directory. Then, standard tools such as [[ls]], [[cp (Unix)|cp]], and [[rm (Unix)|rm]] can be used to manipulate files on the remote system. Even more powerful translators are ones such as [[UnionFS]], which allows a user to unify multiple directories into one; thus listing the unified directory reveals the contents of all the directories.

The Hurd requires a [[Multiboot Specification|multiboot]]-compliant [[booting|boot loader]], such as [[GNU GRUB|GRUB]].

=== Architecture of the servers ===
According to the Debian documentation, there are 24 servers (18 core servers and 6 file system servers) named as follows:<ref name="debian-hurd-doc" />

==== Core servers ====
* '''auth''' ([[authentication server]]): Receives requests and passwords from programs and gives them an ID, which changes the privileges of the program.
* '''crash''' ([[Crash (computing)|crash]] server): Handles all fatal errors.
* '''[[Enforce In-order Execution of I/O|eieio]]''' (translation server): TODO
* '''exec''' (execution server): Translates an executable image (currently [[Executable and Linkable Format|ELF]] and [[a.out]] are supported) to a runnable image in memory.
* '''fifo''' ([[FIFO (computing and electronics)|FIFO]] translator): Implements named pipes.
* '''new-fifo''' (new FIFO server): An alternate server for named pipes.
* '''firmlink''' (the firmlink translator): Implements firmlinks ‒ "half-way between a [[symbolic link]] and a [[hard link]]".<ref>{{cite web |date=1996-10-10 |title=GNU/Hurd - Documentation |publisher=Debian |url=http://www.debian.org/ports/hurd/hurd-doc-server#firmlink |access-date=2012-07-12}}</ref>
* '''fwd''' (forward server): Forwards requests to other servers, used by fifo and symlink servers.
* '''hostmux''' (host multiplexer server)
* '''ifsock''' (server for sockets interface): Helps with UNIX domain socket addresses.
* '''init''' ([[init]] server): Basic system booting and configuration.
* '''magic''' ([[Magic (programming)|magic]] server): Signals that a name lookup must be resolved internally by a process when the result involves the process's state.
* '''null''' (null server): Implements [[/dev/null]] and /dev/zero.
* '''pfinet''' (pfinet server): Implements the PF_INET protocol family.
* '''pflocal''' (pflocal server): Implements [[UNIX domain sockets]].
* '''proc''' (process server): Assigns [[Process identifier|PIDs]] and manages process-level actions.
* '''symlink''' ([[symbolic link]] translator): Implements symbolic links for filesystems that do not support them.
* '''term''' (terminal server): A [[POSIX]] terminal.
* '''usermux''' (user multiplexer server): Invokes user-specific translators.

==== Filesystem servers ====
;ext2fs
:The [[ext2]] filesystem translator. It receives disk blocks from the microkernel and gives files and directories to the applications.
;isofs
:The translator for the [[ISO 9660]] filesystem. Translates blocks of a CD or DVD to files and directories for the applications.
;nfs
:See [[Network File System (protocol)|Network File System]].
;ftpfs
: [[File transfer protocol]] filesystem translator.
;storeio
:The storage translator.

The servers collectively implement the [[POSIX]] [[Applications programming interface|API]], with each server implementing a part of the interface. For instance, the various filesystem servers each implement the filesystem calls. The storage server will work as a wrapping layer, similar to the block layer of Linux. The equivalent of [[Virtual file system|VFS]] of [[Linux]] is achieved by libdiskfs and libpager libraries.