On 09-Jul-2002 Julian Elischer wrote: > > A question to those who know.. > > why is userret() called both at the end of trap() or syscall() > and also almost immediatly again (often) at the end of ast().
ast() is really a special form of a trap that is triggered by doing a last-minute type check on return to userland to see if we still have work to do. > It seems that really there is no one place that one can put code that will > be called ONCE and ONLY ONCE as a thread progresses to userland. Sure there is. When you want an action done, set a thread flag marking the request and set TDF_ASTPENDING. Then handle it in ast() if the flag is set. > There is no one place where you can say "after this point we are in > userland" right up until that iret instruction. There is always the danger > that FTER ny insruction that decides that we are now definitly going to > user space, there could occur an interrupt that causes a reschedule so > that some OTHER thread goes to user land. > > Is it possible to clear interrupts and have the iret instruction > itself re-enable them? > (that would give a few instructions 'atomically' with the iret > which may be all I need). Remember how ast() used to do a critical_enter() before it grabbed sched_lock to check flags and dropped the critical section while handling the flags? This is exactly what you have asked for above. The loop and the critical sections then got pushed back into the MD code but still work the same. > is this possible in other architectures? It already works that way on all architectures. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
