software interrupts (was resume capabilities)
Mon, 03 Jan 2000 15:02:35 -0800
At 01:21 PM 1/2/2000 -0500, email@example.com wrote:
>> How, exactly, do you implement software interrupts? I understood that
>> the Unix emulation layer for KeyKOS only delivered signals during
>> system calls. Is EROS more flexible in this respect?
>EROS has a slightly better interface for managing this, but it's not a huge
>How to implement UNIX-style signals in EROS:
>1. Give the process a small amount of time to invoke a system call. Hope
>that you can handle it that way.
>2. If this time expires, reach out and set a distinguished fault code in
>the process known to the UNIX emulator that means "hit me with my signal
>now". Think of this as a funny additional system call that the process did
>not know it could use. Process enters UNIX kernel on restart. (one cap
I think the big problem for software interrupts is that you want the stack
to be in a valid state. Since it takes several user-mode instructions to
move the stack from one valid state to another, this means that you can not
recognize a software interrupt between these instructions.
>Having done (1) or (2), now create a signal frame at the bottom of the
>signal stack (via shared memory), writing the current process register
>values to that frame (obtained via the fault upcall). Write a new set of
>registers to the process, including the PC of the signal handler (one cap
>invocation). Return to the process, allowing it to resume in the signal
>Norm, Charlie, Bill: this may suggest that the process key (domain key)
>should have a "set regs and resume" operation. I see no negative
>implications to incorporating this, as a fault key can already be obtained
>given a process key.
If you can perform an action with several calls, then providing them in one
call is a perfectly legitimate optimization technique. (If the user can do
it, and it is useful, then make it fast.)