to schedule clock interrupts at a fixed interval, rather scheduling
the next one based on the time of the arrival/servicing of the previous
clock interrupt. Also, pick up a trick from the sbmips port to convert
a division in ip22_clkread to a multiplication, since those are much
cheaper -- the details of that are described in Simon's commit (see
Message-Id: <20020306073437.1D2A8B004@cvs.netbsd.org>). Thanks to
Jason Thorpe and Dominic Sweetman's "See MIPS Run" (where I found
mention of this very subject while looking for something totally un-
related! 8-) for the clue about the source of the timekeeping problems.
For the IP32, where we have no clock-calibration code yet, use the CPU
frequency provided by ARCS instead; it beats a hard-coded value!
As an added bonus, most of the CPU-clock related stuff is now collected
together in cpu_info_store, rather than as a collection of unorganized
global variables.
userlevel; this is necessary due to the 601, unlike other 6xx, having
no concept of separated Valid_user vs. Valid_supervisor for BATs.
* When crossing the kernel/userlevel boundary, have platform-provided
hooks set up the two fixed BAT entries, and possibly additional
segment registers to redeem the 601's BAT limitations.
Both of the above are only built if the $MACHINE provides these hooks,
sparing others the pain.
so that they're more useful for arbitrary types of external storage:
* Add an "mbuf *" argument to (*ext_free)(). If non-NULL, (*ext_free)()
is expected to free the mbuf itself. This allows (*ext_free)() to use
the mbuf for bookkeeping (e.g. deferring the work to a helper thread).
If the "mbuf *" argument is NULL, we are assumed to be in a context
which is safe for performing the destructor operation *now*.
* Adjust MEXTREMOVE() and MFREE() routines for above change.
* Update "ade" and "ti" drivers for new semantics.
eliminate a race where another processor could grab the outgoing
process before we were done saving our state into it, with predictable
results.
Bug spotted on i386 by Frank van der Linden <fvdl@wasabisystems.com>.
thorpej