The Hurd and Linux

anoncvs

+The Hurd is a POSIX compatible multi-server
+system operating on top of the GNU Mach microkernel.
+
+Topics:
+GNU Mach
+The Hurd
+Development
+Debian GNU/Hurd
+
+1983: Richard Stallman founds the GNU project.
+1988: Decision is made to use Mach 3.0 as the kernel.
+1991: Mach 3.0 is released under compatible license.
+1991: Thomas Bushnell, BSG, founds the Hurd project.
+1994: The Hurd boots the first time.
+1997: Version 0.2 of the Hurd is released.
+
+1998: Debian hurd-i386 archive is created.
+2001: Debian GNU/Hurd snapshot fills three CD images.
+
+Microkernel:
+Enforces resource managament (paging, scheduling)
+Manages tasks
+Implements message passing for IPC
+Provides basic hardware support
+
+Monolithic kernel:
+No message passing necessary.
+Rich set of features (filesystems, authentication, network sockets, POSIX interface, ...)
+
+Microkernel
+Clear cut responsibilities
+Flexibility in operating system design, easier debugging
+More stability (less code to break)
+New features are not added to the kernel
+
+Monolithic kernel
+Intolerance or creeping featuritis
+Danger of spaghetti code
+Small changes can have far reaching side effects
+
+Single Server
+A single task implements the functionality of the operating system.
+Multi Server
+Many tasks cooperate to provide the system's functionality.
+One server provides only a small but well-defined part of the whole system.
+The responsibilities are distributed logically among the servers.
+
+A single-server system is comparable to a monolithic kernel system. It has similar
+advantages and disadvantages.
+
+Any multi-server has advantages over single-server:
+
+Clear cut responsibilities
+More stability: If one server dies, all others remain
+Easier development cycle: Testing without reboot (or replacing running servers), debugging with gdb
+Easier to make changes and add new features
+
+The Hurd goes beyond all this, and allows users to write and run their servers, too!
+
+Users can replace system servers dynamically with their own implementations.
+Users can decide what parts of the remainder of the system they want to use.
+Users can extend the functionality of the system.
+No mutual trust necessary to make use of other users services.
+Security of the system is not harmed by trusting users services.
+
+Ports are message queues which can be used as one-way communication channels.
+
+Port rights are receive, send or send-once
+Exactly one receiver
+Potentially many senders
+
+MiG provides remote procedure calls on top of Mach IPC. RPCs look like function calls to the
+user.
+
+Traditional Mach:
+
+Nameserver provides ports to all registered servers.
+The nameserver port itself is provided by Mach.
+Like a phone book: One list.
+
+The Hurd:
+
+The filesystem is used as the server namespace.
+Root directory port is inserted into each task.
+The C library finds other ports with hurd_file_name_lookup, performing a pathname resolution.
+Like a tree of phone books.
+
+mach_port_t identity;
+mach_port_t pwserver;
+kern_return_t err;
+
+pwserver = hurd_file_name_lookup
+                ("/servers/password");
+
+err = password_check_user (pwserver,
+                           0 /* root */, "supass",
+                           &identity);
+
+Task: Lookup /mnt/readme.txt where /mnt has a mounted filesystem.
+
+The C library asks the root filesystem server about /mnt/readme.txt.
+The root filesystem returns a port to the mnt filesystem server (matching /mnt) and the retry name
+/readme.txt.
+The C library asks the mnt filesystem server about /readme.txt.
+The mnt filesystem server returns a port to itself and records that this port refers to the regular
+ file /readme.txt.
+
+Filedescriptor          Port to server
+                        providing the file
+
+fd = open(name,...)     dir_lookup(..,name,..,&port)
+                        [pathname resolution]
+
+read(fd, ...)           io_read(port, ...)
+
+write(fd, ...)          io_write(port, ...)
+
+fstat(fd, ...)          io_stat(port, ...)
+
+...
+
+Provide file and directory services for ports (and more).
+These ports are returned by a directory lookup.
+Translate filesystem accesses through their root path (hence the name translator).
+The C library maps the POSIX file and directory interface (and more) to RPCs to
+the filesystem servers ports, but also does work on its own.
+Any user can install file system servers on inodes they own.
+
+Active Translators:
+
+"settrans -a /cdrom /hurd/isofs /dev/hd2"
+Are running filesystem servers.
+Are attached to the root node they translate.
+Run as a normal process.
+Go away with every reboot, or even time out.
+
+Passive Translators:
+
+"settrans /mnt /hurd/ext2fs /dev/hd1s1"
+Are stored as command strings into an inode.
+Are used to start a new active translator if there isn't one.
+Startup is transparent to the user.
+Startup happens the first time the server is needed.
+Are permanent across reboots (like file data).
+
+A user identity is just a port to an authserver. The auth server stores four set of ids for it:
+effective user ids
+effective group ids
+available user ids
+available group ids
+Basic properties:
+Any of these can be empty.
+A 0 among the user ids identifies the superuser.
+Effective ids are used to check if the user has the permission.
+Available ids can be turned into effective ids on user request.
+
+The auth server provides the following operations on ports:
+
+Merge the ids of two ports into a new one.
+
+Return a new port containing a subset of the ids in a port.
+
+Create a new port with arbitrary ids (superuser only).
+
+Establish a trusted connection between users and servers.
+
+User provides a rendevous port to the server (with io_reauthenticate).
+User calls auth_user_authenticate on the authentication port (his identity), passing the rendevous
+port.
+Server calls auth_server_authenticate on its authentication port (to a trusted auth server), passin
+g the rendevous port and the server port.
+If both authentication servers are the same, it can match the rendevous ports and return the server
+ port to the user and the user ids to the server.
+
+The password server `/servers/password' runs as
+root and returns a new authentication port in
+exchange for a unix password.
+
+The ids corresponding to the authentication
+port match the unix user and group ids.
+
+Support for shadow passwords is implemented here.
+
+The superuser must remain control over user tasks, so:
+All mach tasks are associated with a PID in the system default proc server.
+Optionally, user tasks can store:
+Their environment variables.
+Their argument vector.
+A port, which others can request based on the PID (like a nameserver).
+Also implemented in the proc server:
+Sessions and process groups.
+Global configuration not in Mach, like hostname, hostid, system version.
+
+User tasks not registering themselve with proc only have a PID assigned.
+
+Users can run their own proc server in addition
+to the system default, at least for those parts
+of the interface that don't require superuser privileges.
+
+Store based filesystems
+ext2fs
+ufs
+isofs (iso9660, RockRidge, GNU extensions)
+fatfs (under development)
+Network file systems
+nfs
+ftpfs
+Miscellaneous
+hostmux
+usermux
+tmpfs (under development)
+
+Over a dozen libraries support the development of new servers.
+
+For special server types highly specialized
+libraries require only the implementation of a
+number of callback functions.
+
+Use libdiskfs for store based filesystems.
+Use libnetfs for network filesystems, also for virtual filesystems.
+Use libtrivfs for simple filesystems providing only a single file or directory.
+
+Another very useful library is libstore, which is used by all store based filesystems.
+It provides a store media abstraction.
+A store consists of a store class and a name
+(which itself can sometimes contain stores).
+
+Primitive store classes:
+device store like device:hd2, device:hd0s1, device:fd0
+file store like file:/tmp/disk_image
+task store like task:PID
+zero store like zero:4m (like /dev/zero, of size 4 MB)
+
+Composed store classes:
+copy store like copy:zero:4m
+gunzip/bunzip2 store like gunzip:device:fd0
+concat store like concat:device:hd0s2:device:hd1s5
+ileave store (RAID-0(2))
+remap store like remap:10+20,50+:file:/tmp/blocks
+...
+
+Wanted: A similar abstraction for streams (based on channels), which can be used by
+network and character device servers.
+
+Goal:
+Provide a binary distribution of the Hurd that is easy to install.
+Constraints:
+Use the same source packages as Debian GNU/Linux.
+Use the same infrastructure:
+Policy
+Archive
+Bug tracking system
+Release process
+Side Goal:
+Prepare Debian for the future:
+More flexibility in the base system
+Identify dependencies on the Linux kernel
+
+Plus:
+Source packages can identify build and host OS using dpkg-architecure.
+
+Minus:
+The binary architecture field is insufficient.
+The BTS has no architecture tag.
+The policy/FHS need (small) Hurd specific extensions.
+
+Most packages just work.
+Maintainers are usually responsive and cooperative.
+Turtle, the autobuilder, crunches through the whole list right now.
+Common pitfalls are POSIX incompatibilities:
+Upstream:
+Unconditional use of PATH_MAX (MAXPATHLEN), MAXHOSTNAMELEN.
+Unguarded use of Linux kernel features.
+Use of legacy interfaces (sys_errlist, termio).
+Debian:
+Unguarded activation of extensions available with Linux.
+Low quality patches.
+Assuming GNU/Linux in package scripts.
+
+Upstream benefits:
+Software packages become more portable.
+Debian benefits:
+Debian becomes more portable.
+Maintainers learn about portability and other systems.
+Debian gets a lot of public recognition.
+
+GNU/Hurd benefits:
+Large software base.
+Great infrastructure.
+Nice community to partner with.
+
+Join us at
+http://hurd.gnu.org/
+http://www.debian.org/ports/hurd
+http://www.hurd-fr.org
+
+
+
+
 The Hurd is a POSIX compatible multi-server
 system operating on top of the GNU Mach microkernel.
 
+

 Topics:
-GNU Mach
-The Hurd
-Development
-Debian GNU/Hurd
-
+
+  GNU Mach
+  The Hurd
+  Development
+  Debian GNU/Hurd
+
+
-1983: Richard Stallman founds the GNU project.
-1988: Decision is made to use Mach 3.0 as the kernel.
-1991: Mach 3.0 is released under compatible license.
-1991: Thomas Bushnell, BSG, founds the Hurd project.
-1994: The Hurd boots the first time.
-1997: Version 0.2 of the Hurd is released.
-
-1998: Debian hurd-i386 archive is created.
-2001: Debian GNU/Hurd snapshot fills three CD images.
-
+
+
 Microkernel:
-Enforces resource managament (paging, scheduling)
-Manages tasks
-Implements message passing for IPC
-Provides basic hardware support
-
+

+  Enforces resource management (paging, scheduling)
+  Manages tasks
+  Implements message passing for IPC
+  Provides basic hardware support
+
+
 Monolithic kernel:
-No message passing necessary.
-Rich set of features (filesystems, authentication, network sockets, POSIX interface, ...)
-
+
+  No message passing necessary
+  Rich set of features (filesystems, authentication, network
+  sockets, POSIX interface, ...)
+
+
+
+
 Microkernel
-Clear cut responsibilities
-Flexibility in operating system design, easier debugging
-More stability (less code to break)
-New features are not added to the kernel
-
+

+  Clear cut responsibilities
+  
Flexibility in operating system design, easier debugging
+  More stability (less code to break)
+  New features are not added to the kernel
+
+
 Monolithic kernel
-Intolerance or creeping featuritis
-Danger of spaghetti code
-Small changes can have far reaching side effects
-
+
+  Intolerance or creeping featuritis
+  Danger of spaghetti code
+  Small changes can have far reaching side effects
+
+
+
+
 Single Server
-A single task implements the functionality of the operating system.
+

+  A single task implements the functionality of the operating system.
+
+
 Multi Server
-Many tasks cooperate to provide the system's functionality.
-One server provides only a small but well-defined part of the whole system.
-The responsibilities are distributed logically among the servers.
-
-A single-server system is comparable to a monolithic kernel system. It has similar
+

+  Many tasks cooperate to provide the system's functionality.
+  One server provides only a small but well-defined part of the
+  whole system.
+  The responsibilities are distributed logically among the servers.
+
+
+A single-server system is comparable to a monolithic kernel system. It
+has similar
 advantages and disadvantages.
-
+
+
+
 Any multi-server has advantages over single-server:
-
-Clear cut responsibilities
-More stability: If one server dies, all others remain
-Easier development cycle: Testing without reboot (or replacing running servers), debugging with gdb
-Easier to make changes and add new features
-
+
+  Clear cut responsibilities
+  More stability: If one server dies, all others remain
+  Easier development cycle: Testing without reboot (or replacing
+  running servers), debugging with gdb
+  Easier to make changes and add new features
+
+
-The Hurd goes beyond all this, and allows users to write and run their servers, too!
-
-Users can replace system servers dynamically with their own implementations.
-Users can decide what parts of the remainder of the system they want to use.
-Users can extend the functionality of the system.
-No mutual trust necessary to make use of other users services.
-Security of the system is not harmed by trusting users services.
-
-Ports are message queues which can be used as one-way communication channels.
-
-Port rights are receive, send or send-once
-Exactly one receiver
-Potentially many senders
-
-MiG provides remote procedure calls on top of Mach IPC. RPCs look like function calls to the
-user.
-
+
+
 Traditional Mach:
-
-Nameserver provides ports to all registered servers.
-The nameserver port itself is provided by Mach.
-Like a phone book: One list.
-
+

+  Nameserver provides ports to all registered servers.
+  The nameserver port itself is provided by Mach.
+  Like a phone book: One list.
+
+
 The Hurd:
-
-The filesystem is used as the server namespace.
-Root directory port is inserted into each task.
-The C library finds other ports with hurd_file_name_lookup, performing a pathname resolution.
-Like a tree of phone books.
-
+
+  The filesystem is used as the server namespace.
+  Root directory port is inserted into each task.
+  The C library finds other ports with hurd_file_name_lookup,
+  performing a pathname resolution.
+  Like a tree of phone books.
+
+
+ mach_port_t identity;
 mach_port_t pwserver;
 kern_return_t err;
@@ -411,16 +456,22 @@ passwords.
 (explanation of the example)
 
 Pathname resolution example
-+
+
 Task: Lookup /mnt/readme.txt where /mnt has a mounted filesystem.
-
-The C library asks the root filesystem server about /mnt/readme.txt.
-The root filesystem returns a port to the mnt filesystem server (matching /mnt) and the retry name
-/readme.txt.
-The C library asks the mnt filesystem server about /readme.txt.
-The mnt filesystem server returns a port to itself and records that this port refers to the regular
- file /readme.txt.
-
+
+  The C library asks the root filesystem server about
+  /mnt/readme.txt.
+  The root filesystem returns a port to the mnt filesystem server
+  (matching /mnt) and the retry name
+  /readme.txt.
+  The C library asks the mnt filesystem server about
+  /readme.txt.
+  The mnt filesystem server returns a port to itself and records
+  that this port refers to the regular file
+  /readme.txt.
+
+
 
 The C library itself does not have a full list of all available
 servers.  Instead pathname resolution is used to traverse through a
@@ -441,21 +492,30 @@ either know that the remaining path can't be resolved by the last
 server in the list, or get a valid port to the server in question.
 
 
Mapping the POSIX Interface
--Filedescriptor          Port to server
-                        providing the file
-
-fd = open(name,...)     dir_lookup(..,name,..,&port)
-                        [pathname resolution]
-
-read(fd, ...)           io_read(port, ...)
-
-write(fd, ...)          io_write(port, ...)
-
-fstat(fd, ...)          io_stat(port, ...)
-
-...
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Filedescriptor Port to server providing the file
fd = open(name,...) dir_lookup(..,name,..,&port)

+[pathname resolution]
read(fd, ...) io_read(port, ...)
write(fd, ...) io_write(port, ...)
fstat(fd, ...) io_stat(port, ...)
... 
+
 
 It should by now be obvious that the port returned by the server can
 be used to query the files status, content and other information from
@@ -470,14 +530,18 @@ this file.  Many other C library calls like read() and
 associated with the file descriptor.
 
 
File System Servers
--Provide file and directory services for ports (and more).
-These ports are returned by a directory lookup.
-Translate filesystem accesses through their root path (hence the name translator).
-The C library maps the POSIX file and directory interface (and more) to RPCs to
-the filesystem servers ports, but also does work on its own.
-Any user can install file system servers on inodes they own.
-
+
+
+  Provide file and directory services for ports (and more).
+  These ports are returned by a directory lookup.
+  Translate filesystem accesses through their root path (hence the
+  name translator).
+  The C library maps the POSIX file and directory interface (and
+  more) to RPCs to the filesystem servers ports, but also does work on
+  its own.
+  Any user can install file system servers on inodes they own.
+
+
 
 So we don't have a single phone book listing all servers, but rather a
 tree of servers keeping track of each other.  That's really like
@@ -497,9 +561,10 @@ directly refers to a file, it refers to a port of a server.  That
 means that providing a regular file with static data is just one of
 the many options the server has to service requests on the file port.
 A server can also create the data dynamically.  For example, a server
-associated with /dev/random can provide new random data on every
-io_read() on the port to it.  A server associated with /dev/fortune
-can provide a new fortune cookie on every open().
+associated with /dev/random can provide new random data
+on every io_read() on the port to it.  A server
+associated with /dev/fortune can provide a new fortune
+cookie on every open().
 

 While a regular filesystem server will just serve the data as stored
 in a filesystem on disk, there are servers providing purely virtual
@@ -517,18 +582,20 @@ alike....
 Because a server installed in the filesystem namespace translates all
 filesystem operations that go through its root path, such a server is
 also called "active translator".  You can install translators using
-the settrans command with the -a option.
+the settrans command with the -a option.
 
 
Active vs Passive
-+
+
 Active Translators:
-
-"settrans -a /cdrom /hurd/isofs /dev/hd2"
-Are running filesystem servers.
-Are attached to the root node they translate.
-Run as a normal process.
-Go away with every reboot, or even time out.
-
+
+  "settrans -a /cdrom /hurd/isofs /dev/hd2"
+  Are running filesystem servers.
+  Are attached to the root node they translate.
+  Run as a normal process.
+  Go away with every reboot, or even time out.
+
+
 
 Many translator settings remain constant for a long time.  It would be
 very lame to always repeat the same couple of dozens settrans calls
@@ -542,18 +609,22 @@ such a passive translator, and no active translator does exist already
 (for this node), it will use this string to start up a new translator
 for this inode, and then let the C library continue with the path
 resolution as described above.  Passive translators are installed with
-settrans using the -p option (which is alrady the default).
+settrans using the -p option (which is already the
+default).
 
-+
+
 Passive Translators:
-
-"settrans /mnt /hurd/ext2fs /dev/hd1s1"
-Are stored as command strings into an inode.
-Are used to start a new active translator if there isn't one.
-Startup is transparent to the user.
-Startup happens the first time the server is needed.
-Are permanent across reboots (like file data).
-
+
+  "settrans /mnt /hurd/ext2fs /dev/hd1s1"
+  Are stored as command strings into an inode.
+  Are used to start a new active translator if there isn't
+  one.
+  Startup is transparent to the user.
+  Startup happens the first time the server is needed.
+  Are permanent across reboots (like file data).
+
+
 

 So passive translators also serve as a sort of automounting feature,
 because no manual interaction is required.  The server start up is
@@ -574,20 +645,21 @@ the system servers instead the system default.  For example, they can
 use their own exec server to start processes.  The user specific exec
 server could for example start java programs transparently (without
 invoking the interpreter manually).  This is done by setting the
-environment variable EXECSERVERS.  The systems default exec server
-will evaluate this environment variable and forward the RPC to each of
-the servers listed in turn, until some server accepts it and takes
-over.  The system default exec server will only do this if there are
-no security implications.  (XXX There are other ways to start new
-programs than by using the system exec server.  Those are still
-available.)
+environment variable EXECSERVERS.  The systems default
+exec server will evaluate this environment variable and forward the
+RPC to each of the servers listed in turn, until some server accepts
+it and takes over.  The system default exec server will only do this
+if there are no security implications.  (XXX There are other ways to
+start new programs than by using the system exec server.  Those are
+still available.)
 

 Let's take a closer look at some of the Hurd servers.  It was already
 mentioned that only few system servers are mandatory for users.  To
 establish your identity within the Hurd system, you have to
-communicate with the trusted systems authentication server auth.  To
-put the system administrator into control over the system components,
-the process server does some global bookkeeping.
+communicate with the trusted systems authentication server
+auth.  To put the system administrator into control over
+the system components, the process server does some global
+bookkeeping.
 

 But even these servers can be ignored.  However, registration with the
 authentication server is the only way to establish your identity
@@ -595,18 +667,27 @@ towards other system servers.  Likewise, only tasks registered as
 processes with the process server can make use of its services.
 
 
Authentication
--A user identity is just a port to an authserver. The auth server stores four set of ids for it:
-effective user ids
-effective group ids
-available user ids
-available group ids
+
+
+A user identity is just a port to an authserver. The auth server
+stores four set of ids for it:
+

+  effective user ids
+  effective group ids
+  available user ids
+  available group ids
+
+
 Basic properties:
-Any of these can be empty.
-A 0 among the user ids identifies the superuser.
-Effective ids are used to check if the user has the permission.
-Available ids can be turned into effective ids on user request.
-
+
+  Any of these can be empty.
+  A 0 among the user ids identifies the superuser.
+  Effective ids are used to check if the user has the
+  permission.
+  Available ids can be turned into effective ids on user
+  request.
+
+
 
 The Hurd auth server is used to establish the identity of a user for a
 server.  Such an identity (which is just a port to the auth server)
@@ -615,17 +696,16 @@ a set of available user ids and a set of available group ids.  Any of
 these sets can be empty.
 
 
Operations on authentication ports
-+
+
 The auth server provides the following operations on ports:
-
-Merge the ids of two ports into a new one.
-
-Return a new port containing a subset of the ids in a port.
-
-Create a new port with arbitrary ids (superuser only).
-
-Establish a trusted connection between users and servers.
-
+
+  Merge the ids of two ports into a new one.
+  Return a new port containing a subset of the ids in a port.
+  Create a new port with arbitrary ids (superuser only).
+  Establish a trusted connection between users and servers.
+
+
 
 If you have two identities, you can merge them and request an identity
 consisting of the unions of the sets from the auth server.  You can
@@ -634,19 +714,24 @@ you already have.  What you can't do is extending your sets, unless
 you are the superuser which is denoted by having the user id 0.
 
 
Establishing trusted connections
--User provides a rendevous port to the server (with io_reauthenticate).
-User calls auth_user_authenticate on the authentication port (his identity), passing the rendevous
-port.
-Server calls auth_server_authenticate on its authentication port (to a trusted auth server), passin
-g the rendevous port and the server port.
-If both authentication servers are the same, it can match the rendevous ports and return the server
- port to the user and the user ids to the server.
-
+
+
+  User provides a rendezvous port to the server (with
+  io_reauthenticate).
+  User calls auth_user_authenticate on the
+  authentication port (his identity), passing the rendezvous port.
+  Server calls auth_server_authenticate on its
+  authentication port (to a trusted auth server), passing the
+  rendezvous port and the server port. 
+  If both authentication servers are the same, it can match the
+  rendezvous ports and return the server port to the user and the user
+  ids to the server.
+
+
 
 Finally, the auth server can establish the identity of a user for a
 server.  This is done by exchanging a server port and a user identity
-if both match the same rendevous port.  The server port will be
+if both match the same rendezvous port.  The server port will be
 returned to the user, while the server is informed about the id sets
 of the user.  The server can then serve or reject subsequent RPCs by
 the user on the server port, based on the identity it received from
@@ -655,41 +740,54 @@ the auth server.
 Anyone can write a server conforming to the auth protocol, but of
 course all system servers use a trusted system auth server to
 establish the identity of a user.  If the user is not using the system
-auth server, matching the rendevous port will fail and no server port
+auth server, matching the rendezvous port will fail and no server port
 will be returned to the user.  Because this practically requires all
 programs to use the same auth server, the system auth server is
 minimal in every respect, and additional functionality is moved
 elsewhere, so user freedom is not unnecessarily restricted.
 
 
Password Server
--The password server `/servers/password' runs as
-root and returns a new authentication port in
-exchange for a unix password.
-
-The ids corresponding to the authentication
-port match the unix user and group ids.
-
+
+
+The password server /servers/password runs as root and
+returns a new authentication port in exchange for a unix password.
+

+The ids corresponding to the authentication port match the unix user
+and group ids.
+

 Support for shadow passwords is implemented here.
-
+
 
-The password server sits at /servers/password and runs as root.  It
-can hand out ports to the auth server in exchange for a unix password,
-matching it against the password or shadow file.  Several utilities
-make use of this server, so they don't need to be setuid root.
+The password server sits at /servers/password and runs as
+root.  It can hand out ports to the auth server in exchange for a unix
+password, matching it against the password or shadow file.  Several
+utilities make use of this server, so they don't need to be setuid
+root.
 
 
Process Server
-+
+
 The superuser must remain control over user tasks, so:
-All mach tasks are associated with a PID in the system default proc server.
+

+  All mach tasks are associated with a PID in the system default
+  proc server.
+
+
 Optionally, user tasks can store:
-Their environment variables.
-Their argument vector.
-A port, which others can request based on the PID (like a nameserver).
+

+  Their environment variables.
+  Their argument vector.
+  A port, which others can request based on the PID (like a
+  nameserver).
+
+
 Also implemented in the proc server:
-Sessions and process groups.
-Global configuration not in Mach, like hostname, hostid, system version.
-
+
+  Sessions and process groups.
+  Global configuration not in Mach, like hostname, hostid, system
+  version.
+
+
 
 The process server is responsible for some global bookkeeping.  As
 such it has to be trusted and is not replaceable by the user.
@@ -703,45 +801,55 @@ server fills in the gap.  It provides a PID for all Mach tasks, and
 also stores the argument line, environment variables and other
 information about a process (if the mach tasks provide them, which is
 usually the case if you start a process with the default
-fork()/exec()).  A process can also register a message port with the
-proc server, which can then be requested by anyone.  So the proc
-server also functions as a nameserver using the process id as the
-name.
+fork()/exec()).  A process can also register
+a message port with the proc server, which can then be requested by
+anyone.  So the proc server also functions as a nameserver using the
+process id as the name.
 

 The proc server also stores some other miscellaneous information not
 provided by Mach, like the hostname, hostid and system version.
 Finally, it provides facilities to group processes and their ports
 together, as well as to convert between pids, process server ports and
 mach task ports.
-+
+
 User tasks not registering themselve with proc only have a PID assigned.
-
-Users can run their own proc server in addition
-to the system default, at least for those parts
-of the interface that don't require superuser privileges.
-
 
-Although the system default proc server can't be avoided (all mach
+Users can run their own proc server in addition to the system default,
+at least for those parts of the interface that don't require superuser
+privileges.
+
+

+Although the system default proc server can't be avoided (all Mach
 tasks spawned by users will get a pid assigned, so the system
 administrator can control them), users can run their own additional
 process servers if they want, implementing the features not requiring
 superuser privileges.
 
 
Filesystems
-+
+
 Store based filesystems
-ext2fs
-ufs
-isofs (iso9660, RockRidge, GNU extensions)
-fatfs (under development)
+

+  ext2fs
+  ufs
+  isofs (iso9660, RockRidge, GNU extensions)
+  fatfs (under development)
+
+
 Network file systems
-nfs
-ftpfs
+

+  nfs
+  ftpfs
+
+
 Miscellaneous
-hostmux
-usermux
-tmpfs (under development)
-
+
+  hostmux
+  usermux
+  tmpfs (under development)
+
+
 
 We already talked about translators and the file system service they
 provide.  Currently, we have translators for the ext2, ufs and iso9660
@@ -754,17 +862,21 @@ interface.
 
 
 
Developing the Hurd
-+
+
 Over a dozen libraries support the development of new servers.
-
+

 For special server types highly specialized
 libraries require only the implementation of a
 number of callback functions.
-
-Use libdiskfs for store based filesystems.
-Use libnetfs for network filesystems, also for virtual filesystems.
-Use libtrivfs for simple filesystems providing only a single file or directory.
-
+
+  Use libdiskfs for store based filesystems.
+  Use libnetfs for network filesystems, also for
+  virtual filesystems.
+  Use libtrivfs for simple filesystems providing only
+  a single file or directory.
+
+
 
 The Hurd server protocols are complex enough to allow for the
 implementation of a POSIX compatible system with GNU extensions.
@@ -775,93 +887,123 @@ with several libraries which make it easy to implement new servers.
 Also, there are already a lot of examples of different server types in
 the Hurd.  This makes writing a new server easier.
 

-libdiskfs is a library that supports writing store based filesystems
-like ext2fs or ufs. It is not very useful for filesystems which are
-purely virtual, like /proc or files in /dev.
+libdiskfs is a library that supports writing store based
+filesystems like ext2fs or ufs. It is not very useful for filesystems
+which are purely virtual, like /proc or files in
+/dev.
 

-libnetfs is intended for filesystems which provide a rich directory
-hierarchy, but don't use a backing store (for example ftpfs, nfs).
+libnetfs is intended for filesystems which provide a rich
+directory hierarchy, but don't use a backing store (for example ftpfs,
+nfs).
 

-libtrivfs is intended for filesystems which just provide a single
-inode or directory. Most servers which are not intended to provide a
-filesystem but other services (like /servers/password) use it to
-provide a dummy file, so that file operations on the servers node will
-not return errors. But it can also be used to provide meaningful data
-in a single file, like a device store or a character device.
+libtrivfs is intended for filesystems which just provide
+a single inode or directory. Most servers which are not intended to
+provide a filesystem but other services (like
+/servers/password) use it to provide a dummy file, so
+that file operations on the servers node will not return errors. But
+it can also be used to provide meaningful data in a single file, like
+a device store or a character device.
 
 
Store Abstraction
--Another very useful library is libstore, which is used by all store based filesystems.
-It provides a store media abstraction.
-A store consists of a store class and a name
-(which itself can sometimes contain stores).
-
+
+
+Another very useful library is libstore, which is used by all store
+based filesystems.  It provides a store media abstraction.  A store
+consists of a store class and a name (which itself can sometimes
+contain stores).
+

 Primitive store classes:
-device store like device:hd2, device:hd0s1, device:fd0
-file store like file:/tmp/disk_image
-task store like task:PID
-zero store like zero:4m (like /dev/zero, of size 4 MB)
-
-+
+  device store like device:hd2, device:hd0s1, device:fd0
+  file store like file:/tmp/disk_image
+  task store like task:PID
+  zero store like zero:4m (like /dev/zero, of size 4 MB)
+
+
+
+
 Composed store classes:
-copy store like copy:zero:4m
-gunzip/bunzip2 store like gunzip:device:fd0
-concat store like concat:device:hd0s2:device:hd1s5
-ileave store (RAID-0(2))
-remap store like remap:10+20,50+:file:/tmp/blocks
-...
-
-Wanted: A similar abstraction for streams (based on channels), which can be used by
-network and character device servers.
-
+
+  copy store like copy:zero:4m
+  gunzip/bunzip2 store like gunzip:device:fd0
+  concat store like concat:device:hd0s2:device:hd1s5
+  ileave store (RAID-0(2))
+  remap store like remap:10+20,50+:file:/tmp/blocks
+  ...
+
+
+Wanted: A similar abstraction for streams (based on channels), which
+can be used by network and character device servers.
+
 
-libstore provides a store abstraction, which is used by all store
-based filesystems. The store is determined by a type and a name, but
-some store types modify another store rather than providing a new
-store, and thus stores can be stacked. For example, the device store
-type expects a Mach device, but the remap store expects a list of
-blocks to pick from another store, like remap:1+:device:hd2, which
+libstore provides a store abstraction, which is used by
+all store based filesystems. The store is determined by a type and a
+name, but some store types modify another store rather than providing
+a new store, and thus stores can be stacked. For example, the device
+store type expects a Mach device, but the remap store expects a list
+of blocks to pick from another store, like remap:1+:device:hd2, which
 would pick all blocks from hd2 but the first one, which skipped.
 Because this functionality is provided in a library, all libstore
 using filesystems support many different store kinds, and adding a new
 store type is enough to make all store based filesystems support it.
 
 
Debian GNU/Hurd
-+
+
 Goal:
-Provide a binary distribution of the Hurd that is easy to install.
+

+  Provide a binary distribution of the Hurd that is easy to
+  install.
+
+
 Constraints:
-Use the same source packages as Debian GNU/Linux.
-Use the same infrastructure:
-Policy
-Archive
-Bug tracking system
-Release process
+

+  Use the same source packages as Debian GNU/Linux.
+  Use the same infrastructure:
+  
+    Policy
+    Archive
+    Bug tracking system
+    Release process
+  
+
+
 Side Goal:
-Prepare Debian for the future:
-More flexibility in the base system
-Identify dependencies on the Linux kernel
-
+
+  Prepare Debian for the future:
+  
+    More flexibility in the base system
+    Identify dependencies on the Linux kernel
+  
+
+
 
 The Debian distribution of the GNU Hurd that I started in 1998 is
 supposed to become a complete binary distribution of the Hurd that is
 easy to install.
 
 
Status of the Debian GNU/Hurd binary archive
+
 See
 http://buildd.debian.org/stats/graph.png
 for the most current version of the statistic.
 
 
Status of the Debian infrastructure
-+
+
 Plus:
-Source packages can identify build and host OS using dpkg-architecure.
-
+

+  Source packages can identify build and host OS using
+  dpkg-architecture.
+
+
 Minus:
-The binary architecture field is insufficient.
-The BTS has no architecture tag.
-The policy/FHS need (small) Hurd specific extensions.
-
+
+  The binary architecture field is insufficient.
+  The BTS has no architecture tag.
+  The policy/FHS need (small) Hurd specific extensions.
+
+
 
 While good compatibiity can be achieved at the source level,
 the binary packages can not always express their relationship
@@ -873,58 +1015,81 @@ a binary-all-linux relationship would be more appropriate.
 More work has to be done here to fix the tools.
 
 
Status of the Debian Source archive
--Most packages just work.
-Maintainers are usually responsive and cooperative.
-Turtle, the autobuilder, crunches through the whole list right now.
+
+
+  Most packages just work.
+  Maintainers are usually responsive and cooperative.
+  Turtle, the autobuilder, crunches through the whole list right
+  now.
+
+
 Common pitfalls are POSIX incompatibilities:
-Upstream:
-Unconditional use of PATH_MAX (MAXPATHLEN), MAXHOSTNAMELEN.
-Unguarded use of Linux kernel features.
-Use of legacy interfaces (sys_errlist, termio).
-Debian:
-Unguarded activation of extensions available with Linux.
-Low quality patches.
-Assuming GNU/Linux in package scripts.
-
+
+  Upstream:
+  
+    Unconditional use of PATH_MAX
+    (MAXPATHLEN), MAXHOSTNAMELEN.
+    Unguarded use of Linux kernel features.
+    Use of legacy interfaces (sys_errlist,
+    termio).
+  
+  Debian:
+  
+    Unguarded activation of extensions available with Linux.
+    Low quality patches.
+    Assuming GNU/Linux in package scripts.
+  
+
+
 
-Most packages are PSIX compatible and can be compiled without
+Most packages are POSIX compatible and can be compiled without
 changes on the Hurd.  The maintainers of the Debian source packages
 are usually very kind, responsiver and helpful.
 

-The Turtle autobuilder software (http://turtle.sourceforge.net)
+The Turtle autobuilder software (http://turtle.sourceforge.net)
 builds the Debian packages on the Hurd automatically.
 
 
Debian GNU/Hurd: Good idea, bad idea?
-+
+
 Upstream benefits:
-Software packages become more portable.
+

+  Software packages become more portable.
+
+
 Debian benefits:
-Debian becomes more portable.
-Maintainers learn about portability and other systems.
-Debian gets a lot of public recognition.
-
+

+  Debian becomes more portable.
+  Maintainers learn about portability and other systems.
+  Debian gets a lot of public recognition.
+
+
 GNU/Hurd benefits:
-Large software base.
-Great infrastructure.
-Nice community to partner with.
-
+
+  Large software base.
+  Great infrastructure.
+  Nice community to partner with.
+
+
 
 The sheet lists the advantages of all groups involved.
 
 
End
-+
+
 Join us at
-http://hurd.gnu.org/
-http://www.debian.org/ports/hurd
-http://www.hurd-fr.org
-
+
+  http://hurd.gnu.org/
+  http://www.debian.org/ports/hurd
+  http://www.hurd-fr.org
+
+
 
 List of contacts.
 
-
-
-
 

 Some of these links are at other web sites not maintained by the
 FSF. The FSF is not responsible for the content of these other web sites.
-- 
cgit v1.2.3


From 81c253b970e7ebd961bd60a6201f99a520a991f0 Mon Sep 17 00:00:00 2001
From: Marcus Brinkmann 
Date: Fri, 22 Feb 2002 14:20:00 +0000
Subject: Update menu items.

---
 hurd-talk.html | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

(limited to 'hurd-talk.html')

diff --git a/hurd-talk.html b/hurd-talk.html
index 39757777..237e3ca3 100644
--- a/hurd-talk.html
+++ b/hurd-talk.html
@@ -18,12 +18,16 @@
 
 
 
+What's New

+ 

+ChangeLogs

+
 The GNU Hurd

  

 Documentation

 Installation

 Getting Help

-Download

+Source Code

 Development

 History

  

-- 
cgit v1.2.3


From ff334826e4be21e530ffacebdb474baf9515ad81 Mon Sep 17 00:00:00 2001
From: Marcus Brinkmann 
Date: Mon, 20 May 2002 01:49:08 +0000
Subject: fix link

---
 hurd-talk.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'hurd-talk.html')

diff --git a/hurd-talk.html b/hurd-talk.html
index 237e3ca3..ced5c0ab 100644
--- a/hurd-talk.html
+++ b/hurd-talk.html
@@ -1087,7 +1087,7 @@ Join us at
   
http://hurd.gnu.org/
   http://www.debian.org/ports/hurd
-  http://www.hurd-fr.org
 
 
-- 
cgit v1.2.3


From aeca2f325853c9bdc79dfdc1677f7147c867b911 Mon Sep 17 00:00:00 2001
From: Marcus Brinkmann 
Date: Mon, 20 May 2002 08:40:53 +0000
Subject: Fix link text, too.  By Damien Genet 

---
 hurd-talk.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'hurd-talk.html')

diff --git a/hurd-talk.html b/hurd-talk.html
index ced5c0ab..0460d60c 100644
--- a/hurd-talk.html
+++ b/hurd-talk.html
@@ -1088,7 +1088,7 @@ Join us at
   http://www.debian.org/ports/hurd
   http://www.hurd-fr.org
+  >http://www.hurdfr.org
 
 
The Unofficial (and no longer maintained) GNU Hurd FAQ, Version 0.13
+The Unofficial (and no longer maintained) GNU Hurd FAQ, Version 0.13
 
 Contributions by:
 
@@ -22,7 +22,7 @@ Original Document by: Derek Upham 
 
 Contents:
 
-Q0.  Where can I get the Unofficial GNU Hurd FAQ?
+Q0.  Where can I get the Unofficial GNU Hurd FAQ?
 Q1.  What is the Hurd?
 Q2.  Where can I get a copy?
 Q3.  Why bother writing a new OS when we have Linux and 386/BSD?
@@ -35,7 +35,7 @@ Q9.  What sort of system would we have if the Hurd was bootable today?
 
 ==============================
 
-Q0.  Where can I get the Unofficial GNU Hurd FAQ?
+Q0.  Where can I get the Unofficial GNU Hurd FAQ?
 
 The Unofficial Hurd FAQ (what you are reading now) is occasionally
 posted to the USENET newsgroup, gnu.misc.discuss.  It is also
@@ -160,7 +160,7 @@ Q5.  Where can I find more information?
 The June 1995 GNU's Bulletin contains the following official
 information:
 
-   The GNU Hurd now runs programs native.  We have implemented both
+   The GNU Hurd now runs programs native.  We have implemented both
    shared libraries using ELF, & the popular `ext2' file system used
    by Linux.  It can run GCC, `make', Emacs, & most other GNU
    utilities.  Progress is being made so rapidly that by the time you
diff --git a/related-projects.html b/related-projects.html
index edd896ad..c9928baf 100644
--- a/related-projects.html
+++ b/related-projects.html
@@ -2,7 +2,7 @@
 	"http://www.w3.org/TR/REC-html40/strict.dtd">
 
 
-The GNU Hurd - GNU Project - Free Software Foundation (FSF)
+The GNU Hurd - GNU Project - Free Software Foundation (FSF)
 
 
 
@@ -26,7 +26,7 @@
  

 ChangeLogs

 
-The GNU Hurd

+GNU Hurd

  

 Documentation

 Installation

@@ -41,7 +41,7 @@
 Installation

 Source Code

  

-MiG

+GNU MIG

  

 Source Code

  

@@ -72,11 +72,11 @@ sites.
 
GNU/Hurd on Alpha
 
 The purpose of this project is to provide a working implementation of
-the GNU Hurd for the Alpha architecture.
+the GNU Hurd for the Alpha architecture.
 

 http://savannah.gnu.org/projects/hurd-alpha/
 
-
The GNU Hurd on top of the L4 microkernel
+The GNU Hurd on top of the L4 microkernel
 
 The purpose of this project is to port the Hurd system to the L4 microkernel.
 

diff --git a/whatsnew.html b/whatsnew.html
index f4320291..14ceea3b 100644
--- a/whatsnew.html
+++ b/whatsnew.html
@@ -2,7 +2,7 @@
 	"http://www.w3.org/TR/REC-html40/strict.dtd">
 
 
-The GNU Hurd - GNU Project - Free Software Foundation (FSF)
+The GNU Hurd - GNU Project - Free Software Foundation (FSF)
 
 
 
@@ -31,7 +31,7 @@
  

 ChangeLogs

 

-The GNU Hurd

+GNU Hurd

  

 Documentation

 Installation

@@ -46,7 +46,7 @@
 Installation

 Source Code

  

-MiG

+GNU MIG

  

 Source Code

  

@@ -54,9 +54,9 @@
 
 

Talk about the Hurd

The Hurd and Linux

Current and Past Announcements

Related Projects

Software

Community

GNU Mach

GNU Mach

MiG

MIG

GNU Hurd folks

GNU Hurd folks

What is the GNU Hurd?

What is the GNU Hurd?