Hello John, > 1. There are several Machs: > GNUmach > RT Mach > The Mach project > (at http://www.cs.cmu.edu/afs/cs/project/mach/public/www/mach.html) > > Is there a prefered Mach for the Hurd? currently most users run the Hurd on top of GNUmach. Efforts are now underway to use oskit-mach too. GNUmach itself was derived from Utah's Mach4. The main difference of GNUmach as compared to Mach4 and other Machs is the support of a whole bunch of PC-typical hardware through Linux device drivers that were added/kludged to/into GNUmach some time ago. > 2. Can the Hurd be run on other Machs? Yes, though I'm not sure about the most recent version of the Hurd. I used a 7 months old Hurd with the unmodified Mach4 and tried the Hurd once on MK83a (CMU Mach 3.0). It is also reported that the Hurd's boot program was modified so as to run on top of RT-Mach as a 2nd OS-Server(s) besides Lites (a FreeBSD emulating single OS-Server). The problem with RT-Mach is, that it doesn't support Multiboot (yet) which is required. I started investigating the interface of the Hurd (and glibc!) to Mach and it seems at first glance, that the Hurd uses pretty standard IPC and other kernel interfaces that were present since Mach 3.0. I agree with Roland that it is not unreasonable to assume that the Hurd will work on top of other Machs, as long as they stick to the original CMU Mach 3.0 interface. > 3. Is the prefered Mach changing as the Hurd is developed? Or > is it fairly static? I don't know about the _prefered_ Mach, but in general, Mach is of course constantly under development. However, considering the current research versions of Mach, features are being added (mostly) in a backwards compatible style. It may be safe to assume that the current set of Interfaces that the Hurd uses will remain in nearly every version of Mach currently in use or in development. > 4. Is the public interface to a Mach well defined, and the various versions > are simply different implementations? If you ask about some kind of standard or agreement on what the public kernel interface to Mach should be, I can't tell anything. As already said, most current Machs are derived from CMU Mach 3.0 by _adding_ features. Due to the simple nature of the basic interface between the kernel and user-land programs (they mostly communicate through messages that are being moved in or out kernel protected queues called ports), the additional features are just addressed with different messages on the standard ports (say e.g. {task,thread,exception} kernel port). The same holds true for kernel drivers that are accessed through a uniform device_*() interface that didn't change in misc. Mach implementations even if the number of supported drivers increased substantially... > 5 Perhaps a brief history, pointing out which branch of Mach is > relevant to the hurd. Roland? This would be interesting to all of us. -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds.
