In article <20060928100604.GA14767@antipasto.TechFak.Uni-Bielefeld.DE> you write:
>I could need some advice how to do deal with some issues best. Here's
>the problem I'm currently facing: In our current implementation,
>schedcpu() recomputes the process/lwp priorities and roundrobin()
>causes the system to reschedule. As these two functions are highly
>specific to our current scheduler scheme, they should not directly be
>included within the framework. But, of course, every scheduler
>implementation will have to provide functions of this kind. Thus, two
>functions, sched_adjust() for schedcpu() and sched_resched() for
>roundrobin() are included in the interface. The question now is what's
>the best way to make our current scheduler work with the
>interface.

It seems to me that this entirely depends on how you intend to slot in 
different schedulers.  If the intention is that they should be selected 
at compile time, and that each scheduler should provide a function of 
each name, then you should rename schedcpu() and roundrobin().  If (as I 
suspect is more likely) you plan to have them selectable at run-time, 
then sched_adjust() and sched_resched() will have to be (or go via) 
pointers, and you can keep the existing names for the existing 
functions.

>1. I could just rename schedcpu() and roundrobin() accordingly. But I
>   have some bad feelings about this approach, since it seems to me
>   bit like breaking our current interface.

Since your entire plan is to replace the current interface, I'm not sure 
this can really be described as a problem.

>4. Define sched_adjust() and sched_resched() as function pointers and
>   let them point to schedcpu() and roundrobind(). I tried this one,
>   but I ran into trouble with the callout handler that actually
>   triggers the execution of schedcpu().

What kind of trouble?

-- 
Ben Harris                                                   <bjh21@NetBSD.org>
Portmaster, NetBSD/acorn26               <http://www.NetBSD.org/Ports/acorn26/>