From owner-freebsd-current@FreeBSD.ORG  Thu May 20 12:58:31 2004
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 DBA0C16A4CE; Thu, 20 May 2004 12:58:31 -0700 (PDT)
Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id C3A0243D2F; Thu, 20 May 2004 12:58:31 -0700 (PDT)
	(envelope-from julian@elischer.org)
Received: from interjet.elischer.org ([24.7.73.28])
          by comcast.net (rwcrmhc12) with ESMTP
          id <2004052019582101400jaorme>; Thu, 20 May 2004 19:58:21 +0000
Received: from localhost (localhost.elischer.org [127.0.0.1])
	by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA73903;
	Thu, 20 May 2004 12:58:20 -0700 (PDT)
Date: Thu, 20 May 2004 12:58:19 -0700 (PDT)
From: Julian Elischer <julian@elischer.org>
To: Garance Drosehn <drosihn@gmail.com>
In-Reply-To: <97880ae040520123841ba954e@mail.gmail.com>
Message-ID: <Pine.BSF.4.21.0405201251180.72391-100000@InterJet.elischer.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: sparc64@freebsd.org
cc: Thomas Moestl <t.moestl@tu-bs.de>
cc: FreeBSD current users <current@freebsd.org>
Subject: Re: sparc64 kernel code question..
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 20 May 2004 19:58:32 -0000



On Thu, 20 May 2004, Garance Drosehn wrote:

> On Thu, 20 May 2004 14:24:11 +0200, Thomas Moestl <t.moestl@tu-bs.de> wrote:
> > 
> > On Tue, 2004/05/18 at 12:57:34 -0700, Julian Elischer wrote:
> >   > to answer question 2...
> >   > nothing.. in my sources I renamed it to cpu_exit2()
> > 
> > The name probably derives from the fact that it needs to be called
> > after the sched lock is obtained, as was mentioned in the commit
> > message.

but the naming conventions we use has 'sched' to mean that it is
related to the scheduler. Probably a scheduler specific callout, just
as 'cpu_' means a callout to a cpu-specific mechanism.
cpu_sched_ indicates that it is a per-cpu/per-scheduler special case
callout. in fac tit is not it is prely for sparc64 use and it is in exit
so cpu_exit_{something} would be in order.. We also have historical
examples of using mumbble() and mumble2() when a function needs to be
called in 2 parts due to some external requirement,
so cpu_exit() and cpu_exit2()  would be the names by my logic..
certainly _sched_ is wrong..

> 
> Maybe call it:  cpu_exit_postsched()
> :-)

it is not post_sched
maybe
cpu_exit_locked()

would be more descriptive.