blocked in the kernel. The task that catched the exception may unblock
it by sending a reply to the exception message (Of course it will have
to change something so that the exception is not immediatly raised again).
Handling of this reply is a bit complicated, as the kernel acts as the
client instead of the server. In this situation, we receive a message
but we will not send any reply (the message we receive is already a reply).
I have not found anything better than a special case in
mach_msg_overwrite_trap() to handle this.
A surprise: exceptions ports are preserved accross forks.
While we are there, use appropriate 64 bit types for make_memory_entry_64.
may turn into exceptions on Mach: a small message sent by the kernel to
the task that requested the exception.
On Darwin, when an exception is sent, no signal can be delivered.
TODO: more exceptions: arithmetic, bad instructions, emulation, s
software, and syscalls (plain and Mach). There is also RPC alert, but
I have no idea about what it is.
While we are there, remove some user ktrace in notification code, and add
a NODEF qualifier in mach_services.master: it will be used for notifications
and exceptions, where the kernel is always client and never server: we
don't want the message to be displayed as "unimplemented xxx" in kdump (thus
UNIMPL is not good), but we don't want to generate the server prototype
(therefore, STD is not good either). NODEF will declare it normally in the
name tables without creating the prototype.
1) make sure Mach servers will not work on data beyond the end of the
request message buffer.
2) make sure that on copying out the reply message buffer, we will not
leak kernel data located after the buffer.
3) make sure that the server will not overwrite memory beyond the end
of the reply message buffer. That check is the responsability of the
server, there is just a DIAGNOSTIC test to check everything is in
good shape. All currently implemented servers in NetBSD have been
modified to check for this condition
While we are here, build the mach services table (formerly in mach_namemap.c)
and the services prototypes automatically from mach_services.master, just
as this is done for system calls.
The next step would be to fold the message formats in the mach_services.master
file, but this tends to be difficult, as some messages are quite long and
complex.
have one parent yet (on Darwin, multiple parents are possible: the IOKit
seems to handle a graph more than a tree). Introfuction of a keyboard
driver parent for IOHIDSystem.
The kernel keymapping is still a big mystery.
static binary: otool). Dynamic binaires have a pointer to the Mach-O
header on the top of the stack, static binaries don't have this, and
having it produced a crash.
One bugfix: the EXEC_MACHO code assumes that entry = NULL means that
the entry point has not been found in the load commands seen so far.
Therefore we need to initialized entry to NULL if we want a static binary
to discover it. (dynamic binaries were forced to iscover it because when
the intepreter load command is found, entry is updated whatever its
value was before).
One hack: Both COMPAT_MACH and COMPAT_DARWIN are willing to run Mach-O
binaries. COMPAT_MACH fails for dynamic binaries because it cannot find
the interpreter in /emul/mach. For static binaires, it will accept them
(and for Darwin static binaries, this will cause a failure). Until we
rite a test for matchinf Darwin static binaries, just swap the order of
COMPAT_MACH and COMPAT_DARWIN in the exec switch so that COMPAT_DARWIN
is tried first (this will have the advantage of speeding up program
startup). EXECSW_PRIO_{FIRST_LAST} does not seem to work...
(not really related the the actual mouse movement, but this will come).
The darwin_iohidsystem_thread reads events from wscons, translates them
into IOHIDSystem events and wakes up the userland client with a notification.
To do this, I had to improve the void implementation of
io_connect_set_notification_port() to actually register something (I assumed
a single notification port, which makes some sense since only one process
seems to be able to open the driver)
Missing bits:
- we do not take event masks given by the process into account.
- the notification message has not been checked against Darwin
- events are badly translated
and make the stack and heap non-executable by default. the changes
fall into two basic catagories:
- pmap and trap-handler changes. these are all MD:
= alpha: we already track per-page execute permission with the (software)
PG_EXEC bit, so just have the trap handler pay attention to it.
= i386: use a new GDT segment for %cs for processes that have no
executable mappings above a certain threshold (currently the
bottom of the stack). track per-page execute permission with
the last unused PTE bit.
= powerpc/ibm4xx: just use the hardware exec bit.
= powerpc/oea: we already track per-page exec bits, but the hardware only
implements non-exec mappings at the segment level. so track the
number of executable mappings in each segment and turn on the no-exec
segment bit iff the count is 0. adjust the trap handler to deal.
= sparc (sun4m): fix our use of the hardware protection bits.
fix the trap handler to recognize text faults.
= sparc64: split the existing unified TSB into data and instruction TSBs,
and only load TTEs into the appropriate TSB(s) for the permissions.
fix the trap handler to check for execute permission.
= not yet implemented: amd64, hppa, sh5
- changes in all the emulations that put a signal trampoline on the stack.
instead, we now put the trampoline into a uvm_aobj and map that into
the process separately.
originally from openbsd, adapted for netbsd by me.
be inserted into ktrace records. The general change has been to replace
"struct proc *" with "struct lwp *" in various function prototypes, pass
the lwp through and use l_proc to get the process pointer when needed.
Bump the kernel rev up to 1.6V
We try to map the console framebuffer through wsdisplay. It seems to work,
but we still need to _see_ something.
XXX Framebuffer size discovery is borken.
+ In ioframebuffer and iohidsystem:
More methods and more debug for io_connect_method_*
+ A few new IOKit mach traps.
Peeking at Darwin's header files gives some ideas of what we are doing here.
We know understand most of the stuff called by XDarwin and WindowServer before
mapping the framebuffer.
return packet was wrong (port descriptor instead of VM area descriptor),
thus leading to SIGSEGV when calling IOKit's IOFBCreateSharedCursor().
Now this is fixed we can move forward again on graphic mode.
for the IOHIDSystem driver in Darwin. IOHIDSystem provides access
to user interface devices.
Communication between userspace and kernel is done through a shared
memory page. Our plan is to have a kernel thread waiting on wscons
events (for now it just does nothing), and have it feeding the
shared page.
the off_t argument, Darwin does not. In order to get the off_t argument
going through our syscall machinery, we declare it as two long arguments,
and we reassemble it in darwin_sys_lseek.
Darwin specific files. The handler does nothing yet.
This needs some improvement. Darwin attaches an IOHIDSystem device to
each human-interface device in the tree: mouse, keyboard, and a few others.
For now we only emulate one IOHIDSystem device.
send, send once, and dead names, not for port sets and receive rights.
This make vi and telnet able to work again.
Also removed the all process right list and its lock, which got useless. The
all process lock is replaced by a per process lock, located in struct
mach_emuldata.
Also one bug fix: we did not correctly called Mach hooks for struct emuldata
initialization and release for Darwin processes.
1) rights should be shared by the threads within a process. While it would
be easier to handle this with the struct proc/struct lwp split, we attempt to
do this now by sharing the right lists. Because each right holds a reference
to struct proc, this might cause some problems later.
2) in pthread_exit, really exit the thread. Also reintialize the righ tlist to
make sure we will not destroy the parent's right list
3) rights can hold multiple permissions on a port (ie: send and receive). Fix th
is.
4) first attempt on right carried by messages. We still have to do rights carrie
d in the message body (complex messages).
for forking the traditional UNIX init(8) and it does the Mach port naming
service. We need mach_init for the naming service, but unfortunately, it
will only act as such if its PID is 1. We introduce a sysctl
(emul.darwin.init_pid) to fool a given process into thinking its PID is 1.
That way we can get mach_init into behaving as the name server.
Typical use:
/sbin/sysctl -w emul.darwin.init_pid=$$ ; exec /emul/darwin/sbin/mach_init
two ways:
- the child gets its pid as retval[0] (userland stub will turn it into a 0),
retval[1] is 1 and it is 0 in the parent.
- in the child, the fork syscall is successful, hence we must skip the next
instruction.
compat/common, so that they can be shared by several emulations, and use
them for Darwin.
This removes the ugly dependance on FreeBSD freebsd_file.c for COMPAT_DARWIN
used to get and set the thread user value, which is an opaque pointer to
a per thread structure stored in userland. cthread_self() is used by Darwin
as an implementation for pthread_self(), which return the thread id.
We use the p_emuldata field of struct proc in order to keep track of the
thread user value. For now the value is per-process, but we will make it
per-thread when we will take care of threading.
While we are there, do some KNF
manu