Hi All,
i am newbie to Linux. I am slowly gaining knowledge in kernels. i have a doubt in system calls vs kill signals.

i see there is a System Call Interface named sys_kill. I understand any system calls are delivered to kernel as part of TRAP. This is a HARDWARE INTERRUPT WITHIN CPU.

i also understand CTRL+C, which generates SIGINT is a software interrupt rather hardware interrupt.

can someone tell me how does ctrl+c flows through the kernel, does it do any system call, or its just a pure software interrupt.

Also, plz correct my understanding.

Thanks
vlsireddy

sys_kill is the kernel-internal function called when the kill(2) system call is made. AFAIK anyway. Try man 2 kill.

All signals are delivered to processes by the kernel. The origin of those signals can be a hardware trap like access to nonexistent memory or division by zero, or another process making the kill system call (SIGINT is in that category), or the kernel itself as a consequence of some action by the process (e.g. SIGSTOP when a background process tries to read from stdin).

When you type ctl-c, the shell will use the kill(2) system call to have the kernel send SIGINT to the foreground process. So, ctl-c does generate a system call, and it is purely software (after all, the kernel is purely software).

1 members found this post helpful.

Thanks for your answer.

Also: be careful understanding terms like "software interrupt," which could have a meaning (in context) different from what you assume or expect.

The strictest meaning of that term, is that it is a (CPU ...) interrupt that originates from software, instead of external hardware, but that is treated by the CPU in much the same way. Exactly what does and doesn't fall into this category is a gray area, but the 80x86 INT instruction is a very-obvious example. This instruction was used to implement system-calls in the days of MS-DOS, because it literally caused an interrupt, and therefore a transition from user to supervisor state. The TRAP instruction is much the same. "Like all 'interrupts,' it is handled directly by the CPU," but the source of the interrupt comes from software, not a physical wire.

When you talk about things like SIGINT, these really are an entirely(!) different thing, because the microprocessor knows nothing about such things. So, let's call them signals. A signal is delivered to a process/thread, and its actual effect is to alter the way that the Linux dispatcher deals with it, starting the next time that the dispatcher chooses to allow it to run. When the target process is next dispatched, it will be sent into a "signal handler" in its own user-space code, the kernel having also arranged things such that, when the signal-handler returns, the process will resume where it left off. (Unless the nature of the signal is that "the process dies," in which case the executed code causes the process to graciously achieve its own death.)

Although this procedure is analogous to the CPU's handling of "an interrupt," it is not the same, and the CPU has no direct awareness of it.

1 members found this post helpful.