GNU Hurd

From Wikipedia, the free encyclopedia

“Hurd” redirects here. For other uses, see Hurd (disambiguation).

GNU Hurd

Developer:	Michael (now Thomas) Bushnell (original project lead) with various contributors, including Roland McGrath and Marcus Brinkmann
Latest release:	0.2
OS:	GNU
Use:	Kernel
License:	GPL
Website:	http://www.gnu.org/software/hurd/

The GNU Hurd (usually referred to as "the Hurd") is a computer operating system kernel. It has been under development since 1990 by the GNU Project of the Free Software Foundation. The Hurd is distributed as Free Software under the GNU GPL. It consists of a set of servers (or daemons, in Unix terminology) that work on top of a microkernel; together they form the kernel of GNU. The Hurd aims to surpass Unix kernels in functionality, security, and stability, while remaining largely compatible with them.^{[citation needed]} This is done by having the Hurd track the POSIX specification, while avoiding arbitrary restrictions on the user.^{[citation needed]}

"HURD" is a co-recursive acronym, standing for "HIRD of Unix-Replacing Daemons", where "HIRD" stands for "HURD of Interfaces Representing Depth". It is also a play on words to give "herd of gnus", reflecting how it works.^{[citation needed]}

1 Development history
2 Architecture
3 GNU/Hurd-based distributions
4 References
5 See also
6 External links

[edit] Development history

Development on the GNU operating system began in 1984 and progressed rapidly. By the early 1990s, the only major component missing was the kernel.^{[citation needed]}

Development on the Hurd began in 1990, after an abandoned kernel attempt started from the finished research Trix operating system developed by Professor Steve Ward and his group at MIT's Laboratory for Computer Science (LCS).^{[citation needed]} According to Michael (now Thomas) Bushnell, the initial Hurd architect, their early plan was to adapt the BSD 4.4-Lite kernel and, in hindsight, "It is now perfectly obvious to me that this would have succeeded splendidly and the world would be a very different place today".^[1] However, due to a lack of cooperation from the Berkeley programmers, Richard Stallman decided instead to use the Mach microkernel, which subsequently proved unexpectedly difficult, and the Hurd's development proceeded slowly.^{[citation needed]}

Because of this slow pace, the GNU userland components came to be used with the Linux kernel and are now commonly associated with "Linux" systems (see also GNU/Linux naming controversy).

Despite an optimistic announcement by Stallman in 2002^[2] predicting a release of GNU/Hurd, further development and design are still required. The latest release of the Hurd is version 0.2. It is fairly stable, suitable for use in non-critical applications. It is not yet suitable for a production environment. There are still bugs and missing features;^[3] development in general has gone far worse and resulted in a poorer product than many, including Stallman, had anticipated^[4]

The Debian project, among others, has contributed funding to speed up development.^{[citation needed]}

[edit] Architecture

Unlike Unix-like kernels, the Hurd builds on top of a microkernel which is responsible for providing the most basic kernel services — coordinating access to the hardware: the CPU (through multiprocessing), RAM (via memory management), and other various devices for sound, graphics, mass storage, etc. In theory the microkernel design would allow for the device drivers for sound, graphics etc. to be built as servers working in user space, but today most drivers of this kind are still contained inside GNU Mach, the currently used microkernel. That is because user space hardware drivers would have suffered of bad performance due to the slow Mach interprocess communication. With the performance of today's machines, it is possible that this overhead is no more a hard performance problem.^[5]

[edit] Choice of microkernel

Currently, the Hurd uses GNU Mach as the microkernel, but efforts are under way to port the Hurd to a more modern microkernel. The L4 microkernel was the original choice in 2004, but progress slowed to a halt. In 2005, there was a discussion of whether to change to L4.sec (a different L4 microkernel) or to Coyotos (EROS successor).^[6] Although no formal decision was made, most of the Hurd developers' time has gone into thinking about Coyotos.^[7] especially since 2006.

Other Unix-like systems working on top of the Mach microkernel include OSF/1, Lites, and MkLinux. These are implemented as a single Unix server which, together with the microkernel, replaces the monolithic kernel of a traditional Unix system. Mac OS X and NEXTSTEP use monolithic kernels based on Mach, often incorrectly believed to be microkernels. They have a single large code base which handles everything from the clock to networking.

Instead, in the Hurd, each of these is handled by a separate server process. The Hurd consists of these servers working together. This makes developing the Hurd much easier (at least in theory), as changes to one are less likely to have side-effects in others.

Such a "set of servers" was one of the main design goals of Mach, but Hurd appears to be the first Mach-based system to be implemented in this way. (QNX and Minix-3 are similar but based on their own microkernels.) It is not entirely clear why this happened, but it appears that groups working on Mach were too busy to work on the operating system as a whole.^{[citation needed]} Hurd also aims to be microkernel-independent.^{[citation needed]}

OSKit-Mach began as a branch of the GNU Mach 1.2 kernel, but since the release of GNU Mach 1.3 was merged as the new GNU Mach 2.x mainline.

In 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.

In 2006, Marcus Brinkmann and associates 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. These discussions continued into 2007, but progress is slow.^{[citation needed]}

[edit] Unix extensions

This article or section does not adequately cite its references or sources.
Please help improve this article by adding citations to reliable sources. (help, get involved!)
This article has been tagged since March 2007.

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

Under Unix every program running has an associated user id, which normally corresponds to the user that started the 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, not unlike a Unix symbolic link. The effect of Unix 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, and 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 (a feature that is missing in many Unices, although available in modern BSDs).

Perhaps the most empowering aspect of the Hurd is that any user can start their own system services. Any user can attach any translator to the filesystem for their own personal use. A user could even replace system servers, such as the auth server, with other servers of their own choosing. All this can be done without affecting other users, due to well defined scopes. It is even possible for a user to run the Hurd within itself, which is known as a sub-Hurd.

The Hurd requires a multiboot-compliant boot loader, such as GRUB.

[edit] Architecture of the servers

According to the Debian documentation there are 24 servers (18 core servers and 6 file system servers) named as follows: [1]

[edit] Core servers

auth, (authentication server) : It receives requests and passwords from programs and gives them an ID, which changes the privileges of the program.
crash (crash server):
exec (execution server): Translates an executable image (currently ELF and a.out are supported) to a runnable image in memory.
fifo (FIFO translator):
new-fifo (new FIFO server)
firmlink (the firmlink translator):
fwd (forward server)
hostmux (host multiplexer server);
ifsock (server for sockets interface):
init (init server)
magic (magic server)
null (null server): implements /dev/null and /dev/zero
pfinet (pfinet server)
pflocal (pflocal server)
proc (process server)
symlink (symbolic link translator)
term (terminal server)
usermux (user multiplexer server)

This section is a stub. You can help by expanding it.

[edit] Filesystem servers

The ext2fs server "ext2fs": The ext2 filesystem translator. It receives disk blocks from the microkernel and gives files and directories to the applications.
The iso filesystem server "isofs": The translator for the iso9660 filesystem. Translates blocks of a CD or DVD to files and directories for the applications.
The nfs server "nfs": See Network File System.
The ufs server "ufs": Translator for the BSD filesystem of the same name, UFS.
The ftp filesystem translator "ftpfs": See File transfer protocol
"storeio": The storage translator

The servers collectively implement the POSIX 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 VFS of Linux.