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 Message-ID: <Pine.BSF.4.21.0207091631040.35930-100000@InterJet.elischer.org> In-Reply-To: <20020710090100.Q8947-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0207091631040.35930-100000>