From owner-freebsd-current  Tue Jul  9 17: 3:39 2002
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 9483B37B400; Tue,  9 Jul 2002 17:03:21 -0700 (PDT)
Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 35D5943E31; Tue,  9 Jul 2002 17:00:21 -0700 (PDT)
	(envelope-from julian@elischer.org)
Received: from InterJet.elischer.org ([12.232.206.8])
          by sccrmhc01.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
          id <20020710000011.YSDQ29588.sccrmhc01.attbi.com@InterJet.elischer.org>;
          Wed, 10 Jul 2002 00:00:11 +0000
Received: from localhost (localhost.elischer.org [127.0.0.1])
	by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA37342;
	Tue, 9 Jul 2002 16:43:07 -0700 (PDT)
Date: Tue, 9 Jul 2002 16:43:06 -0700 (PDT)
From: Julian Elischer <julian@elischer.org>
To: Bruce Evans <bde@zeta.org.au>
Cc: John Baldwin <jhb@FreeBSD.ORG>,
	FreeBSD current users <current@FreeBSD.ORG>,
	FreeBSD current users <current@FreeBSD.ORG>
Subject: RE: userret() , ast() and the end of syscalls
In-Reply-To: <20020710090100.Q8947-100000@gamplex.bde.org>
Message-ID: <Pine.BSF.4.21.0207091631040.35930-100000@InterJet.elischer.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-current.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-current>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-current>
X-Loop: FreeBSD.ORG



On Wed, 10 Jul 2002, Bruce Evans wrote:
> Can these flags be changed asynchronously?  If so, then everything needs
> to be handled by ast() anyway.  userret() should only check for work that
> needs doing in the usual case, and hopefully there is none (except for
> things like ktrace).

That's an interestign way of thinking about it..
in that case, shouldn't ast() be called from within userret()
instead of the other way around?

userret() is called unconditionally from both trap() and syscall()
(or just trap() on architectures where syscall() is called by trap())


if teh tast thing userret() did was to check if ast() should be called
and to call it, it might simplify things..
also, should userret() then loop back to it's start if trap is called?
It would need to, to simulate what it is doing now..

now:

userret()
|
|
|
v
doreti() ? <------>ast()<------>userret()
|
|
|
v
userland


maybe:
userret() ? <------>ast()
(maybe loop back to top of userret)
|
|
|
v
doreti()
|
|
|
v
userland

One other question?
why is userret called again if ast() is called?
It seems about the only thing left in it is the profiling flags.
(under normal conditions)



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message