How does keyboard interrupt ends up as process signal

Question

I'm studying the linux kernel right know with O'Reilly's Understanding Linux Kernel and lately covered the signal and interrupt handling chapter sticking to some basic 2.4 linux version and diving into code as far as I can understand.

Yet, I couldn't explain to myself nor finding an answer elsewhere, what is the instruction flow that occurs when, let's say, a ctrl + c is pressed for a process which runs in the shell.

what I did figured out so far:

1. once keyboard pressed APIC raises IRQ line to the cpu
2. if interrupts are not maskable, cpu loads the corresponding int. handler from IDT
3. than, some critical int. handler code is invoked ,handling further the char pressed from the keyboard device's register in the APIC to other registers

from here it's vague for me.

I do understand though, that interrupt handling is not in the process context while exception is, so it was easy to figure out how exception updates current->thread.error_code and current->thread.trap_no finally invoking force_sig. Yet, once an interrupt handler is executed, as in the example above, how does it finally gets into context with the desirable process and generating the signal?

Answer 1

The keypress generates an interrupt, just like you figured out. The interrupt is processed by an interrupt handler; which handler depends on the type of hardware, e.g. USB keyboard or PS/2 keyboard. The interrupt handler reads the key code from the hardware and buffers it. From the buffer the character is picked up by the tty driver, which, in the case of Ctrl-C recognizes it as the interrupt character and sends a SIGINT to the foreground process group of the terminal. See n_tty.c.

Note that the tty driver is only involved in "terminal"-type (command line) interfaces, like the Linux console, serial terminals (/dev/ttyS*), and pseudo ttys. GUI systems (X11, Wayland implementations) handle input devices differently.