From owner-freebsd-current@FreeBSD.ORG Thu Apr 17 22:11:30 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D8F337B401 for ; Thu, 17 Apr 2003 22:11:30 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE91443FAF for ; Thu, 17 Apr 2003 22:11:29 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc02.attbi.com (sccrmhc02) with ESMTP id <200304180511280020026ugde>; Fri, 18 Apr 2003 05:11:29 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id WAA58324; Thu, 17 Apr 2003 22:11:27 -0700 (PDT) Date: Thu, 17 Apr 2003 22:11:25 -0700 (PDT) From: Julian Elischer To: Jeff Roberson In-Reply-To: <20030417234012.Y76635-100000@mail.chesapeake.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD current users Subject: Re: some small patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 05:11:30 -0000 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@ > > > > 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.?