state into global and per-CPU scheduler state:
- Global state: sched_qs (run queues), sched_whichqs (bitmap
of non-empty run queues), sched_slpque (sleep queues).
NOTE: These may collectively move into a struct schedstate
at some point in the future.
- Per-CPU state, struct schedstate_percpu: spc_runtime
(time process on this CPU started running), spc_flags
(replaces struct proc's p_schedflags), and
spc_curpriority (usrpri of processes on this CPU).
- Every platform must now supply a struct cpu_info and
a curcpu() macro. Simplify existing cpu_info declarations
where appropriate.
- All references to per-CPU scheduler state now made through
curcpu(). NOTE: this will likely be adjusted in the future
after further changes to struct proc are made.
Tested on i386 and Alpha. Changes are mostly mechanical, but apologies
in advance if it doesn't compile on a particular platform.
it to determine the boot device: mvme68k, pc532, macppc, ofppc. Those
platforms should be changed to use device_register(). In the mean time,
those ports defined __BROKEN_DK_ESTABLISH.
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>.
Unfortunately, the Cobalt firmware seems to fail loading kernels larger
than about 2.5 megs before compression, so without a boot loader, this
is a rather amputated GENERIC.
- Change comments on cpu_startup() so as what it does (XXX found mostly
common across ports).
- Retain UNIX heritage of /* Good {morning,afternoon,evening,night} */.
cpu_fork() mistakenly created processes forked by proc0, including
kthreads, in splhigh condition, because [1] proc0's PCB was zero
cleared during initialization, and [2] value 0 in status register
field made processes to have splhigh condition when CPU tick was
assigned for them. This mostly doesn't matter as forked processes
dive immediately into user mode through proc_trampoline code path,
however, kthreads never do that and remain in splhigh.
Reported by Ethan Solomita <ethan@geocast.com>.
