Now that you've thought about these, the question remains: what does XINU do? Well, first of all, XINU does not assume a dual-mode architecture. Thus it does not execute a trap to invoke a system call. It simply makes a subroutine call. Thus there is no memory protection whatever to protect the O/S from accidental or malicious corruption.
XINU does, however, ensure that only one process can be active within the O/S at a time. Every internal system routine that could be called from an application turns off interrupts upon entry, and then restores them on exit. Notice that I said restores rather than enables. What XINU actually does on routine entry is to record the state of the ps register (the one that determines which interrupts are allowed), and then turns off interrupts. On exit, it simply restores the ps to the value that it originally contained on entry. This way, if the interrupts were off for some reason on entry, they would continue to be off on exit.
Take a look at the routines disable() and restore(). You will see them at the start and end of most internal XINU routines. Take a look, too, at their implementations. You'll find that they are simple assembly routines that load and read the value of the ps register.
XINU, by convention, returns SYSERR from a system call if some error has been detected. Otherwise OK or some system-call-specific return value is given.
There is one more small thing that XINU does for system calls. It puts the macro SYSCALL at the start of the header for every system call. This is simply defined as an integer. The real purpose is to document the subroutine as a system call. It makes the code easier to read.
