software interrupts (was resume capabilities)

[Bill Frantz]

At 01:21 PM 1/2/2000 -0500, shapj@us.ibm.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
>difference.
>
>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
>invocation).

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
>handler.
>
>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.)