Re: some small patches

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