> - Add locking rules to scheduler API. We need to make sure certain API
>   functions are only called with appropriate locks held etc. Any
>   suggestions how to do this best are more than welcome.
I was thinking of locking and other rules needed for API... lets summarize
few:

o When LWP sleeps i.e. goes to sleep-queue, ltsleep/mtsleep (and other, if
  any) functions must call sched_rem(). When LWP is awaken, wakeup/wakeup_one
  (and other, if any) functions must call sched_add(), which would back the
  LWP to runqueue.
Why? For keeping l_back/l_forw consistent in other schedulers - see below.

o When LWP is not in run-queue i.e. not added to run-queue or removed
  by sched_rem(), one could use l_back and l_forw variables of LWP as
  it needs. When LWP is in run-queue i.e. added with sched_add(),
  l_back and l_forw variables could be modified only by scheduler's
  module i.e. implementation-specific functions'.
Why? Same reason, just after Andrew's kern_sleepq.c introduce it is probably
not importatn (seems "outside" doesn't use l_back/l_forw).

o mi_switch() calls scheduler-specific sched_nextlwp(), which must be
  responsible for removing the new (next) LWP from run-queue and adding
  to run-queue an old (current) LWP. One must know, that IDLE LWPs is
  not managed in run-queues (neither adding nor removing). On empty
  run-queue's case, sched_nextlwp() must return NULL.
Why? There could not only be a removing/adding to runqueue operations. For
example, for Linux-smilar scheduler which I'm writing, doing
sched_rem/sched_add is not fine.

Talking about locking, one should note, that soon we will have runqueues per
CPU, so locks will be per runqueue (probably currently used sched_mutex could
be removed?) and these locks are in scheduler-specific part. Hence, these
locks probably should be handled inside sched_tick, sched_nextlwp, sched_add,
sched_rem and other functions. I am not sure about mi_switch(), but it uses
kernel lock and disables interrupts in critical sections, but probably there
shouldn't be a problem (keep in mind that LWP is separated per CPU).
Well, if I am wrong - someone will correct me.

> Personally, I'd vote to increase MAXPRI at least to 159, which
> should be fairly enough for any scheduler.
Using fixed general range per system would be fine. It is reasonable to
increase it, but I am just wondering - why other systems is not using a power
of 2? :)

Thanks.

-- 
Best regards,
Mindaugas