Issue
I'm confusing some concepts regarding the UNIX kernel, especially defining what it is - whether it is an independent running entity or, just a code block executed in the process but just in the special mode, i.e., kernel mode.
Following are my understandings of the kernel.
Kernel is not a process. It's just the codes loaded on the memory. (https://superuser.com/a/197650/1004546)
According to the above (1), when we describe kernel as an active entity, such as scheduling the processes, it is when the process is executed in kernel mode. (e.g., interrupt, system call)
While the kernel is executed, we do not say that the kernel process is being executed. Since, otherwise, it is contradictory to (1). So, while the context switch is taking place, we say that the same process is executed in kernel mode.
According to (1), (2), (3), the moment kernel code is executed is only when the context switch is taking place, because it's the only moment when the mode of the process is the kernel mode.
Kernel thread has nothing to do with the execution of kernel code - it's the notion regarding the origin of the process - it says that it's created by the UNIX kernel method (system call), not by the user process (.i.e, programmer's implementation)
Please correct me if there are any misunderstandings. Thank you!
Solution
Kernel is not a process. It's just the codes loaded on the memory. (https://superuser.com/a/197650/1004546)
This is about right. Like Marcus says, UNIX is a standard so there is several ways to implement the standard in an actual kernel. For the Linux kernel, the code is loaded in the top half of the virtual address space. Read my answer at What is paging exactly? OSDEV for an introduction and some information regarding paging. That answer isn't all just right but it makes quite some sense as an introduction.
Basically, the instructions that make up the kernel operate on addresses of virtual memory that are above the first half. The bottom half is reserved for user mode processes (code/data, user mode shared libraries, heap, stack, etc).
The kernel isn't a process because it doesn't run all the time. It runs when something calls its code. It is hardware mechanisms that allow modern kernels to work this way. For example, if an external device triggers an interrupt, there is the hardware interrupt table that allow the kernel to attach an interrupt vector to that device. If a process has finished its time slice, there are hardware timers that can trigger an interrupt to notify the kernel. The kernel thus never has to execute constantly to "keep track of what happens" because it uses hardware mechanisms properly to avoid it.
According to the above (1), when we describe kernel as an active entity, such as scheduling the processes, it is when the process is executed in kernel mode. (e.g., interrupt, system call)
When the kernel is servicing an interrupt, it will disable further interrupts to service the critical portion of the handler. Very fast, it will create what's called a kernel thread and add that thread to the list of ready threads with a high priority. Then it will enable interrupts back and return to the thread that was previously running there or call the scheduler which could decide to swap the thread on that core.
Kernel threads are like processes but they are a driver's servicing function. When a driver is registered in the kernel, it calls functions of the kernel to reserve a certain interrupt vector and provides a function to call when this vector is triggered by the device that this driver is supporting. Basically, it asks the kernel to change the address in the interrupt table to the address of that function in the driver. Drivers are in kernel mode code (top half) so they share the address space of the kernel (they use the same page tables). Kernel threads thus have no address space for themselves but they will have a PCB and their own stack.
While the kernel is executed, we do not say that the kernel process is being executed. Since, otherwise, it is contradictory to (1). So, while the context switch is taking place, we say that the same process is executed in kernel mode.
The same process isn't executed in kernel mode when there is a context switch. You will say that when the user mode thread makes a syscall asking for certain kernel service. The syscall handler can put the process on pause while an external device is servicing a transfer and the rest follows (interrupt -> kernel thread -> etc). Eventually, that service is done so the kernel puts the thread who asked for it back on a core and the thread can assume that the transfer was done or handle error codes if any.
For context switches, the kernel might either be triggered by timers or simply just leave every core to execute one thread if there is less ready threads than cores. When a thread is created or a thread is made ready again by an interrupt, the kernel has an opportunity to decide if it should use timers to be notified if the list of ready thread has just grown bigger than the amount of available cores. Context switches thus don't run as part of a process running on the core right now. It runs as part of a timer interrupt, a syscall asking to create a thread or maybe other cases. It isn't completely wrong though to say that it runs as part of a process.
According to (1), (2), (3), the moment kernel code is executed is only when the context switch is taking place, because it's the only moment when the mode of the process is the kernel mode.
A context switch normally refers to switching the registers of a core and other things to execute another thread. It isn't the only case when the kernel is called. It'll be called by interrupts for every external device, by syscalls called by user threads, etc. Interrupts and syscalls don't always involve a context switch. There is a small context switch done to change registers as part of the servicing of something and also the stack registers to not mess up the user thread's stack. In some way, it does mean that most of the time there will be a small context switch but it won't involve as much overhead than switching the thread on a core to another.
Kernel thread has nothing to do with the execution of kernel code - it's the notion regarding the origin of the process - it says that it's created by the UNIX kernel method (system call), not by the user process (.i.e, programmer's implementation)
As stated earlier, syscalls don't create kernel threads (they execute as part of the process) but they often trigger transfers that put the process on pause until an interrupt occurs. It is the interrupt handler that might create kernel threads to service that interrupt later to save time and avoid losing interrupts.
Answered By - user123 Answer Checked By - Candace Johnson (WPSolving Volunteer)