6

System calls are implemented using software interrupts(interrupt vector 128). In roberts love book "Linux Kernel Development" its written that interrupt handle happens at interrupt context. Its also written that system call runs at process context, but system call handle is in fact an " interrupt handle" so why its in different context?

arkadish
  • 345
  • 2
  • 13

1 Answers1

1

You're getting the implementation of your platform mixed up with the design of the Linux Kernel.

When you're talking about the Linux Kernel, the interrupt context is where code runs 'on its own' with no process attached to it - commonly used for handling interrupts from devices. Process context is as a result of a system call from a userland process and code running in it is 'attached' to a process.

When you're talking about the platform implementation, an interrupt context could simply mean that the processor is in a interrupt handler mode of some sort. I don't know enough about your platform to provide anything specific.

tangrs
  • 9,709
  • 1
  • 38
  • 53
  • lets say for example x86. both interrupt handler and system call are implemented the same way. The CPU starts executing the code that is found in the segment related to the interrupt vector in the IDT. The system call handler is logically bound to the user land process(I assume by using the CURRENT macro). For hardware interrupt it similar way just another interrupt vector number and the CURRENT macro still points to the interrupted process. How does the kernel distinguish between those two entities because they are clearly not the same. – arkadish Aug 22 '13 at 11:15
  • I'm not clear on the exact implementation but I'd imagine the kernel would handle the interrupt, find out what caused it and call the correct handlers. For a system call, it might re-enable preemption and jump to the syscall handler while for a device interrupt, it might jump to a interrupt handler (using the CURRENT macro would be pointless here). – tangrs Aug 22 '13 at 11:19