request a mapping at fixed address, overlaying previously existing mappings.
The overlay is done by unmapping (sys_munmap) before mapping at fixed
location. This makes XDarwin able to link and run.
There are two new mach traps:
mach_vm_make_memory_entry, mach_host_get_io_master. Now we need to find
the documentation to understand what they are supposed to do.
This does not buy us new functionnality for now, because we still have to
discover how mach_init (which acts as a name server, enabling processes to
discover each other's ports) is able to receive messages from other processes
(this is a bootstrap problem, and the bootstrap port might be the place to
search).
While we are there:
- removed a lot of debug which is now available using ktrace.
- reworked message handling to avoid mutliple copyin/copyout of the
same data. ktrace of Mach message now uses the in-kernel copy of the
message instead of copying it from userland.
- packed mach trap handlers arguments into a structure to avoid modifying
everything next time we have to add an argument.
Check for target buffer length, and fail if it is too short
Move mach_msg_trap and mach_msg_overwrite_trap to their own file
Remove some useless debug messages now we have ktrace
Remove __P()
is already used, we want to remap to another place. The vmcmd must be
completely rebuild, else things does not work as expected, as the vmcmd has
been modified by the first mapping attempt.
the binary on the second launch.
In mach_vm_map, hack in a failure so that we fail exactly like Darwin when
mapping a page at address 0
Add vm_allocate trap
manu