On Wed, 10 Jul 2002, John Baldwin wrote: > On 09-Jul-2002 Julian Elischer wrote: > > 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..
I think of ast() as the real userret(). Splitting them is an implementation detail. The real userret() has to be very close to the return to user mode, since the return needs to be atomic with checking for things that need to be done before return, so you need fairly strong locking and don't want to hold the lock for very long. > > in that case, shouldn't ast() be called from within userret() > > instead of the other way around? No; that would pessimize userret() and break ast(). ast() is the "real" userret() so i needs to do more. > > 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.. > > The test you refer to is done in MD code because ensuring atomicity involves > doing MD things like disabling interrupts. It really works quite well the > way it is atm. John moved the loop into ast() where it is easier to understand, but Matt made him move it back. There would be little point in userret() repeating the loop, since it "has" to open up a race window on return and then it would miss state changes. These should be seen later by ast(). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
