--- Emmanuel Dreyfus <manu@netbsd.org> wrote: > In the guts of
COMPAT_DARWIN:
> 
> We now have a fairly good emulation for CLI based Darwin programs on
> the
> powerpc. I have been able to use Darwin's ls, sh, telnet (the
> kerberized
> version, it loads more than 25 libraries), and vi. 
> 
> Now the goal is to produce some graphic display. I learnt that the
> equivalent of the X11 server is called WindowServer. This process
> knows
> the detail of the graphic boards handling, and it provides drawing
> capability to other programs. Processes talk to WindowServer using
> Mach
> messages, I don't now yet how WindowServer talks to the hardware.
> 
> On startup, WindowServer attemps to register its ports so that other
> processes can reach it. There is a nameserver process that associate
> service names to Mach ports. It is called a mach_init. mach_init is
> the
> first process started on Darwin, it even forks UNIX init(8) (we won't
> emulate this, of course).
> 
> So now the goal is to startup mach_init, and to make registration
> with
> it possible. In order to use that, we must have a working Mach
> message
> implementation (from now, we support only message from userland to
> kernel, not from kernel to userland). This is the next task. 
> 
> Help is welcome. Manpower is scarce, especially in the following
> areas:
> - Write MD bits for alpha (to use threads in COMPAT_OSF1) (should be
> easy)
> - bring i386 up ot date (hard...)
> - Writing test programs for COMPAT_MACH (easy but time consuming)
> 
> And now the updated roadmap:
> 
> To do:
> - Find volounteers
> - cleanup COMPAT_MACH from Darwin specific bits
> - machine dependent bits on alpha to use Mach multithreading for
> COMPAT_OSF1
> - bring i386 up to date
> - complete multithreading and semaphore support
> - siginfo
> 
> In progress:
> - Mach messages
> 
> Done:
> - Basic semaphore support
> - Basic mutlithreading support
> - Signal handling
> - Mach traps support in ktrace
> - Debug mach traps quick and dirty emulation to get dynamic linking
> - Even more accurate stack layout on startup
> - Emulate enough of BSD system calls to get dynamic linking
> - create COMPAT_DARWIN
> - implement required mach traps on powerpc
> - accurate stack layout on startup
> - reverse engineering mach traps
> - enough support for in native gdb to trace mach-O bins
> - mach traps support on i386 and powerpc
> - Mach-O binaries suport

Just out of curiosity, how do you test the compatibility? Running a
handful of programs is a good idea, but do you have any way to test its
actual compliance (e.g. if a create a web page, I could test it it a
handful of web browsers or I could use a validator to test its
conformance to a certain standard)? I am just interested to find out if
any sort of automated and/or standardized tests exists for NetBSD...is
the code under regress directories in the source supposed to do this?

> 
> 
> -- 
> Emmanuel Dreyfus.  
> JavaScript est encapsule dans HTML, qui encapsulait
> deja pas mal d'autres conneries comme ca.
> manu@netbsd.org  

______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca