Does int 80h interrupt a kernel process?

Question

First some background knowledge, this is from the book: Linux System Programming: Talking Directly to the Kernel and C Library

Signals are a mechanism for one-way asynchronous notifications. A signal may be sent from the kernel to a process, from a process to another process, or from a process to itself.

The Linux kernel implements about 30 signals.

Signals interrupt an executing process, causing it to stop whatever it is doing and immediately perform a predetermined action.

Ok moving further, from here I will quote this part:

On the Intel family of microprocessors, such as the Pentium, int 80h is the assembly language op code for interrupt 80h. This is the syscall interrupt on a typical Intel-based Unix system, such as FreeBSD. It allows application programmers to obtain system services from the Unix kernel.

I can not quite make the connection in my head really. So when I for example use the

write 

method defined in Posix, and when it is compiled into assembly, and then further assembled into an object code and linked to an executable in a given architecture that runs Linux.... a system call is made right?

I am assuming the compiled code would look something like this:

mov eax,4 ;code for system_write
mov ebx,1 ;standard output
mov ecx, memlocation; memlocation is just some location where a number of ascii is present
mov edx, 20; 20 bytes will be written

int 80h;

Ok my question is exactly at this point. Will int 80h send a signal to kernel / interrupt the kernel? Is kernel just one process? (Is it the init process?) When the cpu executes the int 80h , what exactly happens? The registers are full of information already, (eax, ebx, ecx and edx in my example..), but how is this information used?

I can not quite make the connection between the CPU - the kernel and what exactly the CPU does as it executes the int 80h.

I can imagine some code resides somewhere in the memory that actually sends the required information to the device driver but to which process does this code belong to? (I am assuming kernel but is kernel just one process?) And how does int 80h instruction jump to that code? Is it something that Linux has to implement somehow?

Answer 1

Is kernel just one process? (Is it the init process?)

The kernel is a magic beast. It's not a process. The kernel doesn't have a PID you can refer to.

First, it's worth stating (even though it's obvious) that instructions runs on the processor: Therefore, int 80h is executed by the processor.

There is something called Interrupt Request Handler. They are somehow similar to a function pointer. The processor has a table of interrupt handler. This table is called the Interrupt Descriptor Table (aka IDT) and is system wide (ie, not every process has it's own table). I believe that this table is populated by the kernel when it first boot.

So, what happens when the int 80h is executed?

1. The processor was running in ring 3 protection level (the normal level for a process). For more info on ring level, see this.
2. The processor will switch to ring 0, aka kernel mode. In this mode, hardware protection are disabled. This mean that the code that will be executed from now on can do whatever it wants. Write everywhere in physical memory, rewrite the interrupt descriptor table, etc.
3. The processor will jump to the code located in the Interrupt Descriptor Table for the 80h interrupt. The space available for each interruption in the IDT is very small. This is why this code will generally jump again somewhere else.
4. The previous jump lend the processor in the kernel routine dedicated to handling int 80h. The processor is no longer running your process' code, but it is now running kernel code.
5. The kernel can check the registers and memory and determine why the interrupt was triggered. It will understand that you wanted to execute the system call write.
6. The kernel code will jump again, this time in the routine that handle write. The kernel will runs its code for write.
7. The kernel is done running its code. It tells the processor to go back to ring 3 protection level, and resume your process.
8. Userspace process (aka your process) resumes.

Answer 2

When the CPU executes an INT 80h instruction the currently running process on that CPU is an ordinary user process. As a result of processing this instruction the CPU switches from user-mode to kernel-mode. The process doesn't change. The current process is still an ordinary user process, it's just now executing in kernel-mode. Being in kernel-mode gives the system call permission to do things that the program can't do itself. The kernel code then does whatever is necessary to implement system call and executes an IRET instruction. The causes the CPU to switch back to user-mode and start executing code following INT 80h instruction.

Note if the kernel mode code takes long enough to execute, in particular if it blocks, then the scheduler may kick in and switch the CPU to running a different process. In this case the kernel mode code has to wait for an opportunity to finish its job.

Most of the CPU time spent in the kernel is like this, executing system calls in the context of the process that made the system call. Most of the rest of the time spent in the kernel is handling hardware interrupts. (Note that INT 80h is a software interrupt.) In that case the interrupt runs in the context of whatever process happens to be running at the time. The interrupt routine does whatever is necessary to service the hardware device that generated the interrupt and then returns.

While the kernel creates some special processes for itself, these processes have very specialized tasks. There's no main kernel process. The init process in particular isn't a kernel process, it's just an ordinary user process.

Answer 3

your questions are answered as asked. I recommend to consult the book linux programming interface page 44. howerever short answers are as follows. Ok my question is exactly at this point. Will int 80h send a signal to kernel / interrupt the kernel?

No int 80h does not raise any signal to kernel instead it is an entry in a table of interrupts

Is kernel just one process? (Is it the init process?)

No. Now unix kernel is set of threats (called native threads) which can have 3 different types of process-kernel mappings.

When the cpu executes the int 80h , what exactly happens? The registers are full of information already, (eax, ebx, ecx and edx in my example..), but how is this information used?

int 80h is a trap instruction which transition the environment from user to kernel mode %eax contains the system call number for write to be run in kernel mode. contents of all other registers are stored in memory to be stored on return to user mode I can not quite make the connection between the CPU - the kernel and what exactly the CPU does as it executes the int 80h.

80h is a trap for CPU which changes the environment from user to kernel and save registers to memory. it means CPU helps the kernel for doing somthing useful with efficiency.

I can imagine some code resides somewhere in the memory that actually sends the required information to the device driver but to which process does this code belong to? (I am assuming kernel but is kernel just one process?) And how does int 80h instruction jump to that code? Is it something that Linux has to implement somehow?

here you are asking about device drivers. drivers functionality is different from syscall handling. int 80h does not work with drivers.