Date: Sun, 20 Jan 2002 04:32:16 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Julian Elischer <julian@elischer.org> Cc: <arch@FreeBSD.ORG> Subject: Re: doreti() and userret() Message-ID: <20020120034844.A5320-100000@gamplex.bde.org> In-Reply-To: <3C493A80.F77A2283@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 19 Jan 2002, Julian Elischer wrote: > Userret() is supposed to be called the last thing before the > processor is returned to userland.. At least on i386's, this is only true for the pessimized returns from syscall() and trap(). Returns from interrupt handlers normally just return. They sometimes (rarely) go through ast() to handle cases where userret() would do something. In my version of FreeBSD, userret() is almost a no-op and almost all the things that were in userret() are in ast(). > As such it is called from syscall() and from fork_return(). > However AFTER they call it doreti() is called, which in turn > calls ast which sometimes calls userret() again..... > I can't help but feel that there could be some retionalisation there.. There may be any number of calls to userret() for a single return to userland, to handle events that arrive while previous calls are being processed. Unnecessary calls are just pessimizations. In -current there is one call in syscall(), etc. and a loop in ast() that may make any number of calls. The loop must check for new events atomically with exiting. The complications for this are best handled in ast(). > Also, either userret() is the last thing to be called or > ast() is, or maybe doreti is, but > certainly they can't ALL be the last thing called before the kernel returns > to user mode. The logical order is (doreti, ast, userret, iret). > Is it possible that we could take the userret() out of > syscall() and fork_return() > and just make sure that it is always called from doreti()? I haven't completely taken it out. I do the pri_level setting inline and call userret() only to handle the PS_PROFIL case. I think -current only needs it for precisely these things too. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020120034844.A5320-100000>