On Mon, Feb 19, 2007 at 08:14:26PM +0000, Andrew Doran wrote:
> Hi,
> 
> On Sat, Feb 17, 2007 at 10:17:36PM +0100, Daniel Sieger wrote:
> 
> > Here's a proposed patch to introduce a new scheduler API in
> > Yamamoto-san's idle lwp branch. It is a slightly modified/improved
> > version of the patch I send a couple of weeks ago (see [1]).
> 
> [...]
> 
> > +#ifdef SCHED_4BSD
> >  	if (schedhz == 0) {
> >  		/* 16Hz is best */
> >  		statscheddiv = i / 16;
> >  		if (statscheddiv <= 0)
> >  			panic("statscheddiv");
> >  	}
> > +#endif /* SCHED_4BSD */
> 
> I'm not sure if it is worth #ifdefing this just yet. I think it would make
> more sense to have other schedulers provide a dummy routine that just
> returns and does nothing.

Well, statscheddiv is only used to periodically call schedclock(),
which is a completely 4BSD specific function. I don't see any need why
we should enforce other schedulers to provide a dummy for this. Maybe
you can explain the rationale behind your proposal a bit more?

> +sched_rqinit()
> 
> Perhaps call it sched_init()?

Yep, good point. I'll change that.

> +sched_setup()
> 
> This kicks off scheduling, right? So why not sched_start() or
> something?

Not really right. I does not "start" scheduling. I just kicks off
schedcpu(), which is only one part of the scheduler in 4BSD
case. The scheduler actually schedules processes even before
sched_setup() is called. I agree that sched_setup() is probably not
the best naming, but sched_start() seems confusing for me, as it does
not correctly/completely describe what it does. What do you think
about something like sched_start_timeouts()?

> Bikeshedding I know, sorry. :-)

No problem. IMHO, carefully choosing descriptive and reasonable
names is an important part in getting a good API. So, I'm rather happy
about your feedback. :-)

Regards,
Daniel

-- 
Daniel Sieger
Faculty of Technology
Bielefeld University
wwwhomes.uni-bielefeld.de/dsieger