Software interrupts VS System calls

9
votes

I had a question I don't know if it makes completely sense: If there's an interrupt function in a Interrupt vector, where each address slot is a pointer to some function that handles the interrupt (kind of a service, and runs in kernel mode), then my question is:

Would make a difference making a software interrupt instead of using a System call (aka function)? Let's put an example: I can destroy a process in 2 ways in Windows:

  1. I just call "ExitProcess"
  2. I just use the interrupt "int80h" in assembly (well, at least in Linux. Is it possible in windows?)

Both would work and give the same result. The only different I think is that an interrupt stops the CPU, while the system call, since it is not an interrupt, it does not halt the CPU from doing other things (this allows multithreading and not to stop for something does not really needs halting the whole CPU).

Want I really mean is that all functions in WIN32API (or any other OS) can be implemented as interrupts instead and would make no difference. Then that that would render WIN32API an unncessary layer. Don't you think? Then, what is the difference between software interrupts and system calls? You just need to call the function in the WIN32API to request the service, and with interrupts, you just need to pass the parameters (be it via stack or register) and call the specified interrupt identified by a number. The only reason I can think of is that DLLs (instances of these) are created per process and you use only the functions you need.

This is not possible with interrupts and all processes would share the same data, which is not always what one desires.

PD: This is an extra question which is out of topic but is a little one: Where could I see a reference/list of all the interrupts I can call in an OS? I can't see any documentation anywhere.

1
assemblyoperating-systemsignalsinterruptsystem-calls
Note that CPUs do not stop unless you execute a command such as HLT or PAUSE. However, it will do a lot of "internal" work such as save all your registers on the stack and change bits and switch to a new memory model... all of that is costly as pointed our by Jester, but the CPUs do all of that and it may look like they stop, they don't! – Alexis Wilke
On Windows it's not practical make system calls except through the public API. The system call numbers change every time Microsoft releases a new version of Windows. Also the public APIs often work a fair bit differently than the lower level system calls used to implement them. Even on Linux you're better of using the library interface because it's better documented and more functional. It might even be faster than using the old and slow software interrupt interface. – Ross Ridge
I'm curious if there is a performance benefit to preferring calls over interrupts. many kernel queries may be resolved in user mode by caching kernel data. Eg, we can think of a kernel as a server and an interrupt as a synchronous ajax call; it might be expensive to ask the server who you're logged in as, but if you already cached who you logged in as on client(user mode), you don't need to issue an interrupt(an ajax request). in situations where you have the same machine for the user mode and kernel mode, are calls cheaper than interrupts? – Dmitry
if it does, it might explain why Microsoft prefers its api as functions(callable in user mode without switching modes) rather than each always issuing calls. Eg it might be cheaper to do printf in user mode than having each printf issue a syscall. – Dmitry

1 Answers

10
votes

A system call basically just means a service provided by the OS is invoked. The actual mechanism may involve an interrupt, a call gate or other specialized instructions (syscall, sysenter, swi, trap) depending on architecture and OS.

The winapi hides this mechanism, it's an implementation detail you don't have to worry about. It also might be undocumented and subject to change, while the public API is supposed to be stable.

In 32 bit x86 linux, using interrupt 0x80 to perform system calls has been obsolete since more than a decade, for performance reasons. In 32 bit mode the kernel itself provides code that performs the system call using the mechanism the kernel thinks best. This code gets mapped into every process (read about the vdso here). In x86-64 linux, the specialized syscall instruction is used.

Also, there are OS functions that don't need to switch to kernel mode (which is a costly operation). An API layer can also hide this difference, and provide you with the most efficient way automatically.