[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Hurd on Mach on GNU/Linux (verion 0.0.0)

From: John Tobey
Subject: Hurd on Mach on GNU/Linux (verion 0.0.0)
Date: Sun, 18 Nov 2001 21:29:31 -0500
User-agent: Mutt/1.2.5i

Hi all,

I've been toying with this for a few weeks and am no longer too
ashamed to tell y'all about it.  I want to develop Hurd programs but
am too lazy to reboot or use two computers and too brainwashed by RMS
ideology to spring for vmware.  Plus I am kind of interested to know
about Mach.

Put this all together and stir in some free weekends, and the result
is at:

What this hopes to be is enough of GNUMach ported to POSIX/Linux to be
able to run the Hurd binaries where they have been sitting on my disk
since the last time I booted them up.

What it is currently, on my machine at least:

   * compiles

   * initializes kernel data structures

   * implements task_create()/pmap_create() using fork and shared

   * implements thread_create()/pcb_init() by telling the subprocess
     to execute clone() (a pthreads implementation is half-there, but
     may never really work)

   * jumps to the ext2fs.static entry point

   * handles page faults by telling the subprocess to execute mmap()
     on a shared file descriptor

   * dispatches system calls

   * ext2fs.static loops indefinitely, slowly eating stack (which gets
     extended through page faults) and executing mach_reply_port() and

   * mach_msg_trap() returns MACH_RCV_INVALID_DATA (perhaps because
     the specified root device does not exist?)

I do not guarantee that it will do even this much on your system; I
guarantee the opposite.  This code is not clean.  You do not want to
look too closely at this code.  However, I thought people might be


ps, OTOP means "On Top Of POSIX" but there are a few Linux and i386
dependencies still in there.

John Tobey <jtobey@john-edwin-tobey.org>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]