> What, if anything, do I have to do  in MD code to make that work?
> 
> I can't tell if you're saying the MI kernel code will change so that,
> for instance,  kern_synch.c:waekup() says it 
> 	 ``must be called at splsched() or above''
> 
> (your new splsched, that is), or whether there are changes necessary
> in MD code that manipulates scheduling data or process queues.


The first thing I want to make sure is that when splsched() is introduced
in MI code, and defined to be equal to splhigh() initially, nothing will
break because of the (new) use of splstatclock() in MI code while running
at splsched().  splstatclock() would be used to protect updating "struct proc"
fields, "need_resched()" variables etc, that can be reached from statclock().

This can be guaranteed if all splstatclock()s are of the "splraise()"
variety. Even if that is not the case, I think the patches presented
by Chuck are pretty safe because the sleep queues are still properly
protected, but they'd change former behaviour in that there would be
a window in tsleep/sleep where interrupts (above statclock level) can
be fielded.


> MD changes needed

None, if splsched() == splhigh().
Otherwise, splsched() should block any path to wakeup(), and possibly
arrange to call mi_switch() at splsched(), e.g. in userret()  (but see below)


> ``must be called at splsched() or above''

Such a list would look like:

call/use at splstatclock or above:

		updatepri(), resetpriority(), need_resched(), cpu_switch()
		p_estcpu, p_nice, p_priority, p_usrpri



call/use at splsched or above:

		mi_switch()
		curpriority
		slpque[], etc. (e.g. [t]sleep, unsleep, whakeup, ..)


We probably need to think some more about the spl requirement for mi_switch(),
since:

	(1) for ports that need splsched() to be high (> splstatclock) it
	    is overly strict

	(2) cpu_switch() needs to be called at splstatclock() anyway,
	    because of the run-queue manipulations



-pk