CODEWITHSUNDEEP
linux-kerneloperating-system
Kam
Kam

Reputation: 6008

From Kernel Space to User Space: Inner-workings of Interrupts

I have been trying to understand how do h/w interrupts end up in some user space code, through the kernel.

My research led me to understand that:

1- An external device needs attention from CPU

2- It signals the CPU by raising an interrupt (h/w trance to cpu or bus)

3- The CPU asserts, saves current context, looks up address of ISR in the interrupt descriptor table (vector)

4- CPU switches to kernel (privileged) mode and executes the ISR.

Question #1: How did the kernel store ISR address in interrupt vector table? It might probably be done by sending the CPU some piece of assembly described in the CPUs user manual? The more detail on this subject the better please.

In user space how can a programmer write a piece of code that listens to a h/w device notifications?

This is what I understand so far.

5- The kernel driver for that specific device has now the message from the device and is now executing the ISR.

Question #3:If the programmer in user space wanted to poll the device, I would assume this would be done through a system call (or at least this is what I understood so far). How is this done? How can a driver tell the kernel to be called upon a specific systemcall so that it can execute the request from the user? And then what happens, how does the driver gives back the requested data to user space?

I might be completely off track here, any guidance would be appreciated. I am not looking for specific details answers, I am only trying to understand the general picture.

Upvotes: 1

Views: 1219

Answers (1)

osgx
osgx

Reputation: 94235

Question #1: How did the kernel store ISR address in interrupt vector table?

Driver calls request_irq kernel function (defined in include/linux/interrupt.h and in kernel/irq/manage.c), and Linux kernel will register it in right way according to current CPU/arch rules.

It might probably be done by sending the CPU some piece of assembly described in the CPUs user manual?

In x86 Linux kernel stores ISR in Interrupt Descriptor Table (IDT), it format is described by vendor (Intel - volume 3) and also in many resources like http://en.wikipedia.org/wiki/Interrupt_descriptor_table and http://wiki.osdev.org/IDT and http://phrack.org/issues/59/4.html and http://en.wikibooks.org/wiki/X86_Assembly/Advanced_Interrupts.

Pointer to IDT table is registered in special CPU register (IDTR) with special assembler commands: LIDT and SIDT.

If the programmer in user space wanted to poll the device, I would assume this would be done through a system call (or at least this is what I understood so far). How is this done? How can a driver tell the kernel to be called upon a specific systemcall so that it can execute the request from the user? And then what happens, how does the driver gives back the requested data to user space?

Driver usually registers some device special file in /dev; pointers to several driver functions are registered for this file as "File Operations". User-space program opens this file (syscall open), and kernels calls device's special code for open; then program calls poll or read syscall on this fd, kernel will call *poll or *read of driver's file operations (http://www.makelinux.net/ldd3/chp-3-sect-7.shtml). Driver may put caller to sleep (wait_event*) and irq handler will wake it up (wake_up* - http://www.makelinux.net/ldd3/chp-6-sect-2 ).

You can read more about linux driver creation in book LINUX DEVICE DRIVERS (2005) by Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman: https://lwn.net/Kernel/LDD3/

Upvotes: 2

Related Questions