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.
without the blocked/unblocked upcall ordering, an interrupted blocked
upcall might put the blocked thread on the intqueue because it needs
to be continued. With the delayed processing, we avoid putting such a
thread twice on the runqueue.
- fix putting a thread on the intqueue when it needs to be continued
after it blocked.
Also check return value when returning a single stack.
- always wait for unblocked upcall if we have to continue a blocked
thread.
=> removes wakeup from sys_sa_stacks when a stack is returned.
=> avoids extra sa_unblockyield syscall when unblocked upcall is
delivered before blocked upcall is processed.
=> avoids double pagefault if we continued a thread before the
pagefault was resolved.
=> avoids losing unblocked state if we continued a thread after
skipping the unblocked upcall.
- use splay tree for the pagefault check if the thread was running on
an upcall stack.
=> removes the limitation that all upcall stacks need to be
adjoining and that all upcall stacks have to be loaded with the
1st sys_sa_stacks call.
=> enables keeping information associated with a stack in the kernel
which makes it simpler to find out which LWP is using a stack.
=> allows increasing the SA_MAXNUMSTACKS without having to
allocate an array of that size.
Revert the (default) ip_id algorithm to the pre-randomid algorithm,
due to demonstrated low-period repeated IDs from the randomized IP_id
code. Consensus is that the low-period repetition (much less than
2^15) is not suitable for general-purpose use.
Allocators of new IPv4 IDs should now call the function ip_newid().
Randomized IP_ids is now a config-time option, "options RANDOM_IP_ID".
ip_newid() can use ip_random-id()_IP_ID if and only if configured
with RANDOM_IP_ID. A sysctl knob should be provided.
This API may be reworked in the near future to support linear ip_id
counters per (src,dst) IP-address pair.
due to demonstrated low-period repeated IDs from the randomized IP_id
code. Consensus is that the low-period repetition (much less than
2^15) is not suitable for general-purpose use.
Allocators of new IPv4 IDs should now call the function ip_newid().
Randomized IP_ids is now a config-time option, "options RANDOM_IP_ID".
ip_newid() can use ip_random-id()_IP_ID if and only if configured
with RANDOM_IP_ID. A sysctl knob should be provided.
This API may be reworked in the near future to support linear ip_id
counters per (src,dst) IP-address pair.
Remove dom_server_port from struct _dom_binding. It's never initialised
and used in only one place, where dom_server_addr.sin_port was probably
intended.
protocol:kernel to boot, explain the interpretation of boot file names
better, and add an example for setups where dhcpd's conditional
bahaviour is not deployed.
symbols, and made it impossible for the kernel to use that value, and
correctly find symbols from LKMs.
o Allow LKM users to use DDB to debug the entry function of a LKM by
loading the symbol table with the temporary name /lkmtemp/ before calling
it, and then renaming it once we know the module name.
Approved by ragge@.
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.
local-loopback (lo0). As posted for review on tech-kern 2003-18-09,
with a long comment explaining (one of) the deadlock scenarios.
I've used this since shortly after 2002-09-12-, without noticing
performance degradataion or instability for non-loopback mounts.
- tweak some attach messages
- establish interrupt after all dma resouces are successfully allocated
- wrap an assertion with #ifdef DIAGNOSTIC
- assume NCRCFG2_FE bit is always enabled
- call bus_dmamap_sync for mdldmap at POSTWRITE for consistency
- pass proper dmamapsize for mdldmap
crossing boundary in iommu_dvmamap_load().
Fixes E2BIG error on dmamap with smaller boundary size than maxxfersize
(which is used by recent changed pcscp(4)).
While here, some KNF around debug printf etc.
uwe