"inpcb", and this struct inpcb* and struct inp6cb* are the same type.
On NetBSD they are different types, so we must change the types of
formal argument in IPv6-specific functions from "struct inpcb *" to
"struct in6pcb*".
The code didn't compile on NetBSD beforehand, if both FAST_IPSEC + INET6
were configured. This fix will cause even more short-term breakage for
that case, but its a step in the right direction: it shows up what
still needs to be fixed.
* Include "opt_inet.h" everywhere IP-ids are generated with ip_newid(),
so the RANDOM_IP_ID option is visible. Also in ip_id(), to ensure
the prototype for ip_randomid() is made visible.
* Add new sysctl to enable randomized IP-ids, provided the kernel was
configured with RANDOM_IP_ID. (The sysctl defaults to zero, and is
a read-only zero if RANDOM_IP_ID is not configured).
Note that the implementation of randomized IP ids is still defective,
and should not be enabled at all (even if configured) without
very careful deliberation. Caveat emptor.
for using /dev/crypto for OpenSSL:
1. Add comments explaining crypto_devallowsoft, explaining the
OpenBSD-style three-way logic actully implemented in crypto_newsession().
2. Pass crypto_devallowsoft as the final argument to crypto_newsession(),
instead of a constant 0 value.
3. Set the default value of crypto_devallowsoft to 1, to allow
/dev/crypto access only for hardware-supported transforms.
Items 1-3 may be revised to match the FreeBSD two-way logic, if the
consensus is that there's no point to forcing software transforms.
But as a first step, let the description match what the code actually does.
GC unused variables usercrypto, userasmcrypto, cryptodevallowsoft from
cryptodev.c, in favour of variables crypto_usercrypto, crypto_userasmcrypto,
crypto_devallowsoft, which are used as well as defined in crypto.c.
registers into arguments passed.
Avoids corruption of anything pointed to by r3 and r4 on entry to
os_get_env, and allows pass-by-reference values to be returned.
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.
- 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.
