Re: some small patches

On Thu, 17 Apr 2003, Julian Elischer wrote:

>
>
> On Thu, 17 Apr 2003, Jeff Roberson wrote:
>
> >
> > On Thu, 17 Apr 2003, Julian Elischer wrote:
> >
> > >
> > >
> > > On Thu, 17 Apr 2003, Jeff Roberson wrote:
> > >
> > > > I object to the sched_clock() change.  We've discussed this on threads_at_
> > >
> > > Yes and the clock code doesn't need to know about KSEs and it is of
> > > ABSOLUTLY NO difference to the sched_clock() function if it derives the
> > > thread from the KSE or derives the KSE from the thread.
> > >
> > > there is no big difference between
> > > sched_clock(curthread);
> > > and
> > > sched_clock(curthread->td_kse)
> > > except that one requires kern_clock.c to know about KSEs and one
> > > doesn't.
> >
> > The difference is in the meaning of the function and not the
> > functionality.  It is an interface that operates on a property of the kse
> > and not the thread.
>
> No it's an interface that tells the scheduler that curthread
> (THAT's A THREAD, OK?) received a clock tick.  The scheduler can map
> that thread to whatever private data structures it needs to, but
> CURTHREAD IS A THREAD! It may have some scheduler provate information
> associates with it, (e.g. a KSE) but basically the function statclock is
> telling the scheduler.
> "hey whatever thread is running now just got a clock tick"
>
> In fact since the thread in question is always curthread
> the whole question is stupid.. it could be a void function,
> and use 'curthread' to derive both td and kse.
>
> The KSE is information PRIVATE TO THE SCHEDULER, in fact there may not
> even BE one. So why do you want to pass it as an argument.?
>
>

We disagree on this point.  No amount of capitalized text is going to
change that.

I don't object so strongly to this change except that I disagree with the
logic behind it.  We need a centralized place to place run queue and slice
information.  We already have that abstraction.  Changing that conflicts
with work that I have planned.