contains the values __SIMPLELOCK_LOCKED and __SIMPLELOCK_UNLOCKED, which
replace the old SIMPLELOCK_LOCKED and SIMPLELOCK_UNLOCKED. These files
are also required to supply inline functions __cpu_simple_lock(),
__cpu_simple_lock_try(), and __cpu_simple_unlock() if locking is to be
supported on that platform (i.e. if MULTIPROCESSOR is defined in the
_KERNEL case). Change these functions to take an int * (&alp->lock_data)
rather than the struct simplelock * itself.
These changes make it possible for userland to use the locking primitives
by including <machine/lock.h>.
* Remove the casts to vaddr_t from the round_page() and trunc_page() macros to
make them type-generic, which is necessary i.e. to operate on file offsets
without truncating them.
* In due course, cast pointer arguments to these macros to an appropriate
integral type (paddr_t, vaddr_t).
Originally done by Chuck Silvers, updated by myself.
big-endian. i386, pc532 and vax still include <machine/byte_swap.h>
and define macros for the {n,h}to{h,n}*() functions. mips also
defines some endian-independent assembly-code aliases for unaligned
memory accesses.
that is priority is rasied. Add a new spllowersoftclock() to provide the
atomic drop-to-softclock semantics that the old splsoftclock() provided,
and update calls accordingly.
This fixes a problem with using the "rnd" pseudo-device from within
interrupt context to extract random data (e.g. from within the softnet
interrupt) where doing so would incorrectly unblock interrupts (causing
all sorts of lossage).
XXX 4 platforms do not have priority-raising capability: newsmips, sparc,
XXX sparc64, and VAX. This platforms still have this bug until their
XXX spl*() functions are fixed.
I've fixed most (not all) m68k FPE bugs that give bogus
calculation results, esp. fsqrt instruction. Also, the internal FP
representation has been reduced from 115-bit mantissa to 67-bit
mantissa which reduced the required mantissa operation roughly by one
fourth. I've done an extensive (though not exhaustive - it's
impossible!) test on the internal routines by feeding them randomly
generated FP numbers, and found that the new code is more precise than
MC68040 FPU (it seems to have a rounding bug).
[ Only change was to keep fpu_calcea.c's name instead of renaming to
fpu_ea.c in Ken's patch. --akb ]
