I'm trying to get a deeper understanding of how system calls and hardware interrupts are implemented, and something that keeps confusing me is how they differ with respect to how they're handled. For example, I am aware that one way a system call (at least used to) be initiated is through the x86 INT 0x80 instruction.

  1. Does the processor handle this the exact same way as if, say, a hardware peripheral would have interrupted the CPU? If not, at what point do they differ? My understanding is they both index the IDT, just with different indices in the vector.

  2. In that same sense, my understanding is there's this idea of a softirq to handle the "bottom half" processing, but I only see this form of "software interrupt" in reference to being enqueued to run by physical hardware interrupts. Do system call "software interrupts" also trigger softirqs for processing? That terminology confuses me a bit as well, as I've seen people refer to system calls as "software interrupts" yet softirqs as "software interrupts" as well.

  • How can it be interrupting the CPU if it's being done by the CPU itself? That's like being surprised if you intentionally hit yourself.
    – Barmar
    Commented Jul 15, 2020 at 18:36
  • @Barmar: Any processor has pins devoted to "electrical" interrupts (INTR and NMI are common in Intel processors). Any peripheral device, including keyboard or mouse, generate electrical pulses that are sent to the PIC chip (Programmable interrupt controller) or the more modern APIC chip (Advanced Programmable Interrupt Controller). These chips send the signal to the INTR or NMI pins in the CPU, which in turn stops execution and "parses" the interrupt information. This is a very simplistic explanation.
    – ferranm
    Commented Jul 15, 2020 at 19:17
  • @Barmar, bear in mind that there are also device drivers, which implement code to "talk" among the device and the OS... For software, you have the int instruction. When the CPU finds one, it operates like if it is a hardware interrupt. In Linux, kernel implements the IDT table to map interrupts with the code that "honors" the interrupt.
    – ferranm
    Commented Jul 15, 2020 at 19:18

1 Answer 1


INT 0x80h is an old way to call kernel services (system functions). Currently, syscalls are used to invoke these services as they are faster than calling the interrupt. You can check this mapping in kernel's Interrupt Descriptor Table idt.c and in line 50 in the irq_vectors.h file.

The important bit that I believe answers your question is the header of that last file, where you can see how interrupt requests (IRQs) are organized.

 This is the general layout of the IDT entries: 
   Vectors   0 ...  31 : system traps and exceptions - hardcoded events
   Vectors  32 ... 127 : device interrupts
   Vector  128         : legacy int80 syscall interface
   Vectors 129 ... INVALIDATE_TLB_VECTOR_START-1 except 204 : device interrupts
   Vectors INVALIDATE_TLB_VECTOR_START ... 255 : special interrupts

It really does not matter if it is by electrical means or software means. Whenever an interrupt is triggered, the kernel looks for its ID in the IDT and runs (in kernel mode) the associated interrupt handler. As they have to be really fast, they normally set some info to be handled later on by a softirq or a tasklet. Read chapter 2 (fast read...) of the Unreliable Guide To Hacking The Linux Kernel

Let me recommend also reading this really good and thorough answer at stackoverflow to Intel x86 vs x64 system call question, where INT 0x80h, sysenter and syscall are put in context...

I wrote my own (so very modest and still under construction) self learning page about interrupts and signals to help me understand the relation of signals and traps with interrupts (for instance SIGFPE - divide by zero).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .