> >   (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?

it's also for dispatcher, in either variants.
(callee can't know what caller doesn't know.)

> > - 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()?

an argument for sched_enqueue, which sched_4bsd ignores, should be enough.

YAMAMOTO Takashi