Note. I primarily work with ARM machines, so some of these things may be specific to ARM. Also, I'm going to try to simplify it as much as I can. Feel free to fix anything that might be wrong or simplistic.
Suppose a thread makes a system call. After that I am a bit unclear in the work. Interruption will cause a call. One of my questions is who will answer this call?
Typically, a processor starts at a specific location in kernel mode. The kernel will save the current state of the process and look at user space registers to determine which system call has been requested and send it to the correct system call handler.
Thus, the kernel will look for the table of interrupt vectors and get the subroutine that must be executed. My next question is: which stack will be used when executing the interrupt? Will it be a kernel cell stack or Thread thread level? (I assume this will be a stack of kernel cells.)
I'm sure it will switch to the kernel stack. There would be some pretty serious security issues when leaking information if they used a user space stack.
Returning to the program flow, let's say that the operation opens the file using fopen. The next question I have is how will the transition from ISR to System Call happen? Or is our ISR mapped to a system call?
fopen() is actually a libc function, not the system call itself. It can (and in most cases) call syscall open() in its implementation, though.
So the process is (roughly):
- User space calls
fopen() fopen makes an open() system call- This causes some kind of exception or interruption. In response, the processor goes into a more privileged mode and starts execution at a specific location in the kernel.
- The kernel determines what kind of interrupt and exception it is and processes it accordingly. In our case, it will be a system call.
- The kernel determines which system call is requested by reading the user space registers and extracts any arguments and passes it to the appropriate handler.
- The handler is running.
- Kernel puts any return code in user space registers.
- The kernel transfers execution back to where the exception occurred.
Also, with a wider image, when Kernel Thread is running, I assume that the "OS area" in RAM will be used to host the pages that make the System call.
Pages do nothing :) Normally on Linux, any address displayed above 0xC0000000 belongs to the kernel.
Looking at it again from a different angle (I hope that you are still with me), I assume that the corresponding kernel thread is processed by the CPU Scheduler, where in the context switch there would have been from Thread Level Thread to the corresponding "Core Level" when answering a system call Fopen System Call.
When using a proactive core, threads are effectively not discriminated against. From my point of view, a new thread is not created to serve a system call - it starts only in the same thread from which the system call was requested, except for kernel mode.
This means that a kernel mode thread serving a system call can be scheduled just like any other thread. Therefore, here you will learn about the "user space context" in kernel development. This means that it runs in kernel mode in the usermode thread.
It’s a little difficult to explain, so I hope that everything is correct.