yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
> - both variants mean additional knowledge for a dispatcher,
>   and enlargement of the api.
Well, variant B at least does not add Yet Another API function.

>   (it's natural, given that the purpose of the api change in the first
>   place was to give schedulers more info.)
Schedulers, but not dispatcher. In sched_enqueue() splitting case it would be
also for dispatcher, wouldn't it?

> - the variant B puts more knowledge about idle lwps int schedulers,
>   while the variant A doesn't.
Agree, scheduler must check for LW_IDLE flag. For the sake of clearness, one
could pass a NULL for sched_switch(), which would mean to not enqueue.

> is your specific scheduler implementation easier with the variant B?
Both cases are equal.

> - the variant B introduces implicit enqueue, while the variant A doesn't.
Yes, but it's a single case. You've said that sched_switch() is a "method",
but one could say, this function is designed especially for mi_switch().

In essence, I am OK with both variants, because practically they are (and will
be) equal - it is just a question of theoretical abstraction. Does it really
worth adding additional function into the API for single use from very
concrete place in mi_switch()?
If you really think that yes - OK, it could be changed, because we could
argue about such details all night.. :)

P.S. Hey, where is the 3'rd voice in such cases?

-- 
Best regards,
Mindaugas
www.NetBSD.org