Suppose a process is running and it invokes a system call . Does that means that process will now be blocked . Are all system calls block a process and changes its state from running to block ? Or it depends on the scenario at that time?
No, it does not mean the process is blocked. Some system calls are blocking and some are not. However, note that for the duration of the time the kernel processes the system call, while the process continues to run, your own user code is not executing but the kernel code is executing on behalf of the process.
Some operating systems have even upcalls, where the user application registers some functions to be called by the kernel (back in userspace) at some occasions. The Unix signal machinery is a very simple example, but some OSes have much more complex upcalls.
I think there are some OSes where a syscall trigger some kernel processing which may trigger some upcall back in userspace.
I forgot the details
Related
Is there any (dirty)method to provoke context switching to specific process after specific ISR?
In normal situation, after an ISR, the process which was interrupted will keep running, and I have to wait the scheduler to pick that specific process. I want to switch to the specific process right away after the ISR.
Any advice will be great. Thanks!
Construct your driver so that the process has a thread blocking on suitable syscall (read(), ioctl()) with the ISR waking up that thread (because at least one byte became available for read()).
Then, make sure that thread has the highest priority possible, and preferably uses a realtime scheduler (SCHED_FIFO or SCHED_RR). In practice, if your process does not run with root privileges, you'll need to start the service with root privileges, setup the thread, then drop privileges; or give the binary executable CAP_SYS_NICE capability via e.g. setcap pe=CAP_SYS_NICE binary.
It is technically possible for the driver to also mess with the scheduling, but I would not do that. Anything that is so time-critical, should be done in the kernel ISR instead.
If you want to do it in userspace, because you don't want your code to be a derivative of the kernel and therefore GPL-licensed, you're on your own.
In user mode linux (UML) a trace thread annuls system calls made by the user-space process and redirects them to a kernel running in user-space. Now at some point this userspace kernel would require assistance of the host OS. How does the user-mode kernel call the underlying host kernel, Is it just normal system calls? Or does it use some kind of IOCTL mechanism or something else?
I found an very simple explanation of UML design here. It may be useful for you.
UML constructs it using ptrace system call tracing mechanism.
When a process in user space, its system called are intercepted by ptrace.
When it is in the kernel, no interception. When a process executes a
system call or receives signal, the tracing thread forces the process to run in the kernel.
After the transition, the process state is restored and it continues.
System call virtualization
By switching the user and kernel and system calls interception
Note: the system call must be annulled in the host kernel.
The process state is preserved.
When the system call is complete, the process obtains the returned value in its saved registers and returned to user mode.
Also, this article explains System call virtualization using ptrace with the following picture.
http://www.csee.wvu.edu/~katta/uml/graphics/vsyscall.jpg. The red line represents the normal syscall procedure.
Below are three threading models that i came across.
Based on these below 3 architectures, It is new for me to understand that, there also exist something called kernel thread, apart from user thread which is introduced as part of POSIX.1C
This is 1-1 model
This is N-1 model.
This is Hybrid model.
I have been through many questions on SO for kernel threads. This looks more relevant link for clarification.
At process level, For every user process that is loaded by Linux loader(say), Kernel does not allocate corresponding kernel process for executing machine instructions that a user process has come up with. User process only request for kernel mode execution, when it require a facility from kernel module[like malloc()/fork()]. Scheduling of user process is done by OS scheduler and assign a CPU core.
For example, User process does not require kernel execution mode to execute an instruction
a=a+2;//a is my local variable in a user level C function
My question:
1)
So, What is the purpose of kernel level thread? Why does OS need to maintain a kernel thread(additionally) for corresponding user thread of a User level process? Does User mode programmer have any control on choosing any of the above three threading models for a given User process through programming?
After i understand the answer to first question, one relevant supplementary is,
2)
Does kernel thread actually get scheduled by OS scheduler but not user thread?
I think the use of the word kernel thread is a bit misleading in these figures. I know the figures from a book about operating system (design) and if I remember correctly, they refer to the way how work is scheduled by the operating system.
In the figures, each process has at least one kernel thread assigned that is scheduled by the kernel.
The N-1 model shows multiple user-land threads that are not known to the kernel at all because the latter schedules the process (or how it's called in the figure, a single kernel thread) only. So for the kernel, each process is a kernel thread. When the process is assigned a slice of processor time, it itself runs multiple threads by scheduling them at its own discretion.
In the 1-1 model, the kernel is aware of the user-land threads and each thread is considered for processor time assignment by the scheduler. So instead of scheduling a whole process, the kernel switches between threads inside of processes.
The hybrid model combines both principles, where lightweight processes are actually threads known to the kernel and which are scheduled for execution by it. Additionally, they implement threads the kernel is not aware of and assign processor time in user-land.
And now to be completely confused, there is actually a real kernel thread in Linux. But as far as I understand the concept, these threads are used for kernel-space operations only, e.g. when kernel modules need to do things in parallel.
So, What is the purpose of kernel level thread?
To provide a vehicle for assignment of a set of resources provided by the OS. The set always incudes CPU code execution on a core. Others may include disk, NIC, KB, mouse, timers, as may be requested by syscalls from the thread. The kernel manages access to those resources as they become available and arbitrates between resource conflicts, eg. a request for KB input when none is available will remove CPU execution from the thread until KB input becomes available.
Why do we need a kernel thread(additionally) for corresponding user
thread of a User level process?
Without a kernel-level thread, the user thread would not be able to obtain execution - it would be dead code/stack. Note that with Linux, the concept of threads/processes can get somewhat muddied, but nevertheless, the fundamental unit of execution is a thread. A process is a higher-level construct whose code must be run by at least one thread, (eg. the one raised by the OS loader to run code at the process entry point when it is first loaded).
Does User mode programmer have any control on choosing any of the
above three threading models for a given User process through
programming?
No, not without a syscall, which means leaving user mode.
Does kernel thread actually get scheduled by OS scheduler but not user
thread
Yes - it is the only thing that gets to be given execution when it can use it, have execution removed when it cannot, and be subject to preemptive removal of CPU if the OS scheduler requires it for something else.
what do we mean by thread running in User mode and running in kernel mode? Is this related to thread execution instruction from User mode and thread executing instruction from Kernel mode? Kindly elaborate.
Also, is it possible that if a thread is executing in user mode is put to suspended state, then it may start executing in kernel mode? if yes, how is it possible? Until now I am only aware that a thread if suspended will be SUSPENDED completely, i.e. the context switch will take place by CPU to schedule another thread.
what do we mean by thread running in User mode and running in kernel mode?
There is no way to know what a person means by a phrase without context. If I had to guess, I'd say they are talking about whether the thread is scheduled by a user-space scheduler or a kernel scheduler. But it's also possible they are actually asking whether the thread is running user code or kernel code.
Is this related to thread execution instruction from User mode and thread executing instruction from Kernel mode? Kindly elaborate.
It could be. It also might not be. There's no way to know what a person means by a phrase without context.
Also, is it possible that if a thread is executing in user mode is put to suspended state, then it may start executing in kernel mode? if yes, how is it possible?
For implementations where the kernel schedules threads, the scheduler is running in kernel space. The code that actually suspends the thread typically runs in kernel space too because it has to add the thread to the various kernel scheduler data structures. So the thread that resumes the thread will run in kernel space too. At a higher level view, the same thread of execution can "become" the kernel scheduler, choose a user-space thread to execute, and then "become" that thread.
Until now I am only aware that a thread if suspended will be SUSPENDED completely, i.e. the context switch will take place by CPU to schedule another thread.
Right, and that's kernel code. So the same core is running user space code, then it's running kernel code, then it's running the user space code of another thread.
Modern operating systems have hardware support for separating the user code from the kernel code. On the x86 architecture you can set up memory pages that are not accessible to normal user code, and will trigger a page fault, so that the OS can survive faulty programs.
Code running in kernel mode has higher privileges, but also more responsibillities, as not everything is as easily accessible as from user space. If the user code gets stuck, then the OS can clean it up. If a kernel mode code hangs it might not be that easy, depending on how high the privilege level is.
Is there any other way to execute a program using kernel, other than shell and system calls?
It always used to be the case that there was really only one way to execute a program on Unix and its derivatives, and that was via the exec() system calls. The very first (kernel) process was created by the boot loader; all subsequent processes were created by fork() and exec(). Of course, fork() only created a copy of the original program; it was the exec() system call - in one of a number of forms in the C source code, but eventually equivalent to execve() - that did the donkey work of replacing the current process with a new image.
These days, there are mechanisms like posix_spawn() which might, or might not, use a separate system call to achieve roughly the same mechanism.
A lot of kernels has support for adding kernel modules or drivers at run time. If you want to execute some code from kernel space (probably because you need higher privileges), you can write a kernel module/driver of your own and load it to execute your code. However, inserting a driver only doesn't ensure that your code will be executed. Based on your driver implementation, you will have to have some triggering mechanism for executing your code in kernel space.
yeah, you can compile your kernel with your program sourced in it, but it won't be the smartest thing to do.
Every program is internally executed by Kernel. If you are looking for running kernel module, you have to use the system calls to reach that module and perform some work for you in Kernel mode. Kernel is event driven and only system calls trigger execution of its modules (apart from some system events like network packet received)