From mib@gnu.ai.mit.edu Wed Nov  3 21:51:03 1993
Path: usenet.ee.pdx.edu!cs.uoregon.edu!ogicse!emory!nigel.msen.com!sdd.hp.com!swrinde!cs.utexas.edu!uunet!spool.mu.edu!bloom-beacon.mit.edu!ai-lab!prep.ai.mit.edu!gnulists
From: mib@gnu.ai.mit.edu (Michael I Bushnell)
Newsgroups: gnu.announce,gnu.misc.discuss
Subject: Hurd status and call for volunteers
Message-ID: <9311020719.AA02206@geech.gnu.ai.mit.edu>
Date: 1 Nov 93 21:19:05 GMT
Article-I.D.: geech.9311020719.AA02206
Followup-To: gnu.misc.discuss
Distribution: world
Lines: 124
Approved: info-gnu@prep.ai.mit.edu
To: info-gnu@prep.ai.mit.edu
X-Shopping-List: 
   (1) Chaotic casino griddles (2) Cervical congestion (3) Neoclassical
   consoles
Xref: usenet.ee.pdx.edu gnu.announce:160 gnu.misc.discuss:3985

This message to help sate curiosity, as well as to ask for volunteers.
Until we are ready for alpha test, this is the last such message that
will be posted here.  If you want to receive further such messages,
send mail to hurd-ann-request@gnu.ai.mit.edu and ask to be put on that
(moderated) announcements list.


What is already done with the Hurd:

The filesystem is complete; it runs (read-only), and most of its calls
have been tested and work.  The filesystem is able to download
programs, by a kludge similar to the kludge used to enable the kernel
to download the first task.  In the actual bootstap sequence, it will
download the execserver.

The proc and auth servers are completed; the exec server is nearly
complete (for a.out, not for bfd).  

C library support for Mach and Hurd rpc stubs, and some of the mach
and hurd specific code, is done.  Much untested and probably wrong
code has been written to implement Unix "system calls".  A large piece
of this (the descriptor management code) is believed by Roland to have
some architectural flaw, but he isn't sure.

Some small filesystem servers (shadow directories, for example) have
been written, but have not been compiled, let alone tested.


There are currently three things happening wrt the Hurd:

I am spending nearly all my time getting things to boot and run.  My
work is currently directed toward that goal; in the immediate present
I am working with Roland on getting the library in its near-final
state (which will last a long time) to make compiling easier.  It is
because this is nearly done that I can send this message.

Roland is working on the library.  Most of the remaining architectural
work is done and being tested.  Then Roland will work on integrating
cthreads (which is mostly busywork), miscellaneous filesystem calls,
and then file descriptors.  After that comes signals.

Jan Brittenson will be working on the network server library.  This is
a library that, when linked against a BSD protocol stack, will produce
a Hurd network server.  (Such a server implements the socket interface
in socket.defs.)


There are four general tasks that can be done by other people:

1. Completing the existing work on the terminal driver.  The existing
work implements most of the logic you already associate with a Posixy
terminal driver; it needs the port management and buffering logic
added.  

2. Writing a readline terminal driver.  We will want, as an
alternative to the Posixy terminal driver, a readline type terminal
driver.

3. Writing miscellaneous shell utilities.  Here we need shell
utilities to create translators, etc.  They should have a nice rich
set of features to do all kinds of GNU things.  

4. Writing miscellaneous filesystem servers.  Here we need a
transparent tar server, a transparent FTP server, and the like.


Future plans for work to be written by me (once the bootstrap works,
and in addition to testing library code as Roland finishes it):

o split the existing filesystem into three parts:
  o a library for port management for complicated multi-threaded
    servers;
  o a library for "normal" disk-based filesystems;
  o ufs specific code.

o Write the PF_FILE socket server (what you know as PF_UNIX).

o Finish the posixy terminal driver if nobody else has.

o Write miscellaneous shell utilities that nobody else has.

o Build a self-hosting system.


What you need in order to be able to help now:

o A 386 PC running Mach 3.0.  If you have some other kind of hardware,
  then you need to port the GNU C library support first.  I'm not
  entirely sure how much work that involves; you will need to contact
  Roland.  It might be too much trouble at this point to spend any
  effort on it.  It's best if it's a machine for which a free port of
  Mach is available, though you could do useful work even if it's not.

  If you are not currently running Mach 3.0 with somebody's
  single-server, then it is very unlikely you could help, unless you
  have a Unix source license.  In that case, you could talk to CMU
  (write mach@cs.cmu.edu) to find out how to get Mach 3.0 running on
  your machine.  It is not possible to do development without a Unix
  emulator of some kind; just bare Mach 3.0 is not sufficient.  I have
  neither the time nor knowledge to help someone get a 3.0
  single-server system running.

o Clue.  I don't have enough time to explain operating systems or Unix
  to people.  You need to have an iron-clad grasp of Unix semantics
  (specificaly BSD); it's essential that things be exactly right from
  that standpoint.  It's not enough that you've programmed Unix
  before; you need to understand all the nits.  However, you may
  disregard my previous comments about a "two question limit".  You do
  need the ability to intuit to some extent, however.

o Time.  It's not good for me to delegate a task and then have nothing
  happen on it.  If you have a full-time job where you can't justify
  Hurd work as part of your job, you might find that you don't really
  have as much time as you thought.  Please make sure you really have
  enough time before volunteering for a task.

o Efficient net access.  Without a real Internet connection (mail only
  is not sufficient), it will be impossible for you to do development
  right now.


If you think you can help, send me email.  If you don't think you can
help right now, then don't give up: the list of conditions will change
as the list of delegatable tasks changes.