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.