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.
will have unimplemented services showing their names in ktrace
Add a new generated file with only service id and name, which will
be included by kdump to display services names.
This removes the need for using the user ktrace facility for services names.
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.
copyin() or copyout().
uvm_useracc() tells us whether the mapping permissions allow access to
the desired part of an address space, and many callers assume that
this is the same as knowing whether an attempt to access that part of
the address space will succeed. however, access to user space can
fail for reasons other than insufficient permission, most notably that
paging in any non-resident data can fail due to i/o errors. most of
the callers of uvm_useracc() make the above incorrect assumption. the
rest are all misguided optimizations, which optimize for the case
where an operation will fail. we'd rather optimize for operations
succeeding, in which case we should just attempt the access and handle
failures due to insufficient permissions the same way we handle i/o
errors. since there appear to be no good uses of uvm_useracc(), we'll
just remove it.
While we are here, try to tag machine dependent functions in header files.
also transformed darwin_ppc_*_state into mach_ppc_*_state, as this is
what they really are (COMPAT_DARWIN is on the top of COMPAT_MACH, not the
other way around)
While we are there, resolved another mystery: the unallocated port described
in the comment removed by this commit was in fact allocated by mach_task_pid().
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.
Some initial support for IOHIDSystem. This gives us some pointer moves in X11
(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
(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.
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.
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.
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.
- introduce mach_port_destroy (badly emulated for now)
- on fork/exec, don't set l_private, as the process might be not mature
enough to survive a proc_representative_lwp call (-> kernel panic)
Once we give WindowServer the io_master_port, it sends a message to it:
305 WindowServer MMSG id 2804 [0x1310009 -> 0x131000e] -12016 bytes, flags 0
x1513
0x0000 0x00001513 0xffffd110 0x0131000e 0x01310009 .........1...1..
0x0010 0xffffcfd0 0x00000af4 0x00000000 0x00000000 ................
0x0020 0xffffcf60 0x00000052 0x3c646963 0x74204944 ...`...R<dict ID
0x0030 0x3d223022 0x3e3c6b65 0x793e494f 0x50726f76 ="0"><key>IOProv
0x0040 0x69646572 0x436c6173 0x733c2f6b 0x65793e3c iderClass</key><
0x0050 0x73747269 0x6e672049 0x443d2231 0x223e494f string ID="1">IO
0x0060 0x48494453 0x79737465 0x6d3c2f73 0x7472696e HIDSystem</strin
0x0070 0x673e3c2f 0x64696374 0x3e0047cc g></dict>.G.
Did you ever dreamt about system call arguments in XML?
are using lwp.
Enable kill -9 to kill parent thread waiting for its child.
Use upcallret instead of child_return for the newly created lwp.
Add debug messages for thread creation.
Thread creation are still broken...
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.
manu