I am new to this OS stuff. Since the kernel controls the execution of all other programs and the resources they need, I think it should also be executed by the CPU. If so, where does it gets executed? and if i think that what CPU should execute is controlled by the kernel, then how does kernel controls the CPU if the CPU is executing the kernel itself!!!..
It seems like a paradox for me... plz explain... and by the way i didn't get these CPU modes at all... if kernel is controlling all the processes... why are these CPU modes then? if they are there, then are they implemented by the software(OS) or the hardware itself??
thanq...
A quick answer. On platforms like x86, the kernel has full control of the CPU's interrupt and context-switching abilities. So, although the kernel is not running most of the time, every so often it has a chance to decide which program the CPU will switch to and allow some running for that program. This part of the kernel is called the scheduler. Other than that the kernel gets a chance to execute every time a program makes a system call (such as a request to access some hardware, e.g. disk drive, etc.)
P.S The fact that the kernel can stop a running program, seize control of the CPU and schedule a different program is called preemptive multitasking
UPDATE: About CPU modes, I assume you mean the x86-style rings? These are permission levels on the CPU for currently executing code, allowing the CPU to decide whether the program that is currently running is "the kernel" and can do whatever it wants, or perhaps it is a lower-permission-level program that cannot do certain things (such as force a context switch or fiddle with virtual memory)
There is no paradox:
The kernel is a "program" that runs on the machine it controls. It is loaded by the boot loader at the startup of the machine.
Its task is to provide services to applications and control applications.
To do so, it must control the machine that it is running on.
For details, read here: http://en.wikipedia.org/wiki/Operating_System
Related
I understand that using Hardware support for implementing preemptive scheduling is great for efficiency.
I want to know, What are practical ways we can do preemptive scheduling without taking support from hardware? I think one of way is Software Timers.
Also, Other way in multiprocessor system is using the one processor acting as master keep looking at slave processor's processor.
Consider, I'm fine with non-efficient way.
Please, elaborate all ways you think / know can work. Also, preferably but not necessarily works for single processor system.
In order to preempt a process, the operating system has to somehow get control of the CPU without the process's cooperation. Or viewed from the other perspective: The CPU has to somehow decide to stop running the process's code and start running the operating system's code.
Just like processes can't run at the same time as other processes, they can't run at the same time as the OS. The CPU executes instructions in order, that's all it knows. It doesn't run two things at once.
So, here are some reasons for the CPU to switch to executing operating system code instead of process code:
A hardware device sends an interrupt to this CPU - such as a timer, a keypress, a network packet, or a hard drive finishing its operation.
The software running on a different CPU sends an inter-processor interrupt to this CPU.
The running process decides to call a function in the operating system. Depending on the CPU architecture, it could work like a normal call, or it could work like a fake interrupt.
The running process executes an instruction which causes an exception, like accessing unmapped memory, or dividing by zero.
Some kind of hardware debugging interface is used to overwrite the instruction pointer, causing the CPU to suddenly execute different code.
The CPU is actually a simulation and the OS is interpreting the process code, in which case the OS can decide to stop interpreting whenever it wants.
If none of the above things happen, OS code doesn't run. Most OSes will re-evaluate which process should be running, when a hardware event occurs that causes a process to be woken up, and will also use a timer interrupt as a last resort to prevent one program hogging all the CPU time.
Generally, when OS code runs, it has no obligation to return to the same place it was called from. "Preemption" is simply when the OS decides to jump somewhere other than the place it was called from.
This question already has answers here:
How does the OS scheduler regain control of CPU?
(3 answers)
Closed 5 years ago.
I know that a single-CPU system can run only one process at any instant. My doubt is, how does OS being itself a separate process runs on the CPU mean while managing to schedule some other process aswell simultaneously (which is not possible,as only one process can be run on a single-CPU system).
In other words,if another process is consuming the CPU at any time does the OS be context switched ?? or where does the OS runs(as it has to be active always to monitor) ??
I even don't know whether its an appropriate question... but kindly let me know if you have an answer. OR correct me if I am wrong !!
Thanks in Advance !!
In a modern operating system the kernel, the core of the OS, in complete control of how much time it allocates to the various user processes it's managing. It can interrupt the execution of a user process through various mechanisms provided by the CPU itself. This is called preempting the process and can be done on a schedule, like executing a user process for a particular number of nanoseconds before automatically interrupting it.
In older operating systems, like DOS and Windows 1.0 through 3.11, macOS 9 and earier, plus many others, they employ a different mode where the user process is responsible for yielding control. If the process doesn't yield there may be little recourse to reassert control of the system. This can lead to crashes or lock-ups, a frequent problem with non-preemptive operating systems of all stripes.
Even then there is often hardware support for things like hardware timers that can trigger a particular chunk of code on a regular basis which can be used to rescue the system from a run-away process. Just because a bit of code is running is no guarantee that it will continue to run indefinitely, without interruption.
A modern CPU is a fantastically complicated piece of equipment. Those with support for things like CPU virtualization can make the single physical CPU behave as if it's a number of virtual CPUs all sharing the same hardware. Each of these virtual CPUs is free to do whatever it wants, including dividing up its time using either a pre-emptive or cooparative model, as well as splitting itself into even more virtual CPUs.
The long and the short of it here is to not assume that the kernel must be actively executing to be in control. It has a number of tools at its disposal to wrest control of the CPU back from any process that might be running.
I read this paragraph from " Modern Operating Systems , Tanenbaum "
Most computers have two modes of operation: kernel
mode and user mode. The operating system is the most fundamental piece of software and runs in kernel mode (also called supervisor mode). In this mode it has complete access to all the hardware and can execute any instruction the machine is capable of executing. The rest of the software runs in user mode, in which only a subset of the machine instructions is available.
I am unable to get how they are describing difference in these two modes on basis of machine instructions available , at user end any software has the capability to make any changes at the hardware level ,like we have software which can affect the functioning of CPU , can play with registry details , so how can we say that at user mode , we have only subset of machine instructions available ?
The instructions that are available only in kernel mode are tend to be very few. These instructions are those that are only needed to manage the system.
For example, most processors have a HALT instruction that stops the CPU that is used for system shutdowns. Obviously you would not want any user to be able to execute HALT and stop the computer for everyone. Such instructions are then made only accessible in kernel mode.
Processors use a table of handlers for interrupt and exceptions. The Operating system creates such a table listing the handlers for these events. Then it loads register(s) giving the location(and size) of the table. The instructions for loading this register(s) are kernel mode only. Otherwise, any application could create total havoc on the system.
Instructions of these nature will trigger an exception if executing in user mode.
Such instructions tend to be few in number.
Well, in user-mode, there is definitely a subset of instructions available. This is the reason we have System Calls.
Example:
A user wants to create a new process in C. He cannot do that without entering kernel-mode, because certain set of instructions are only available to kernel-mode, So he uses the system call fork, that executes instructions for creating a new process (not available in user-mode). So System call is a mechanism of requesting a service from kernel of the OS to do something for the user, which he/she cannot write code for.
Following excerpt from above link sums it up in the best way:
A program is usually limited to its own address space so that it
cannot access or modify other running programs or the operating system
itself, and is usually prevented from directly manipulating hardware
devices (e.g. the frame buffer or network devices).
However, many normal applications obviously need access to these
components, so system calls are made available by the operating system
to provide well defined, safe implementations for such operations. The
operating system executes at the highest level of privilege, and
allows applications to request services via system calls, which are
often initiated via interrupts. An interrupt automatically puts the
CPU into some elevated privilege level, and then passes control to the
kernel, which determines whether the calling program should be granted
the requested service. If the service is granted, the kernel executes
a specific set of instructions over which the calling program has no
direct control, returns the privilege level to that of the calling
program, and then returns control to the calling program.
Peripheral devices require drivers to work in a computer system (operating system).
Does a CPU need a driver to work?
Same question for a main memory?
The answer is no.
The reason is that the motherboard comes with an (upgradable) BIOS, which takes care of making sure the CPU features function correctly (obviously, an AMD processor won't work on an Intel motherboard). You can upgrade the BIOS, but that should be avoided until, ... reasons of course.
Same goes for memory, it does not require a driver either.
Just so that you know, if you ever tried overclocking you can notice that you can alter the way the RAM functions, ganged/unganged mods and so on. My point is that there is already an interface established using code allowing you to make changes in real time, isn't that the very purpose we even have drivers, to be able to use a peripheral with expected outcome.
On the other hand, peripheral devices are just extensions, which the motherboard does not know how to handle, hence needing a set of instructions i.e. drivers.
In a modern system both memory and the CPU require kernel mode code — as do devices — to function.
Memory requires management of virtual memory tables. The CPU requires maintenance of process control structures.
In the business, such code is not called a "driver".
Generally, one thinks of a device driver as being kernel mode code that responds to devices through the interrupt vector.
That said, on some systems there are "printer drivers" that do not fit that definition of driver.
In short, do memory and CPU have something called a "driver"? No.
Do they have something analogous to a driver? Yes.
This may be very foolish question to ask.
However I want to clarify my doubts as i am new to this thing.
As per my understanding the CPU executes the instruction of a process step by step by incrementing the program counter.
Now suppose we have a system call as one of the instruction, then why do we need to give a software interrupt when this instruction is encountered? Can't this system call (sequence of instructions) be executed just as other instructions are executing, because as far i understand the interrupts are to signal certain asynchronous events. But here the system call is a part of the process instruction, which is not asynchronous.
It doesn't require an interrupt. You could make an OS which uses a simple call. But most don't for several reasons. Among them might be:
On many architectures, interrupts elevate or change the CPU's access level, allowing the OS to implement protection of its memory from the unprivileged user code.
Preemptive operating systems already make use of interrupts for scheduling processes. It might be convenient to use the same mechanism.
Interrupts are something present on most architectures. Alternatives might require significant redesign across architectures.
Here is one example of a "system call" which doesn't use an interrupt (if you define a system call as requesting functionality from the OS):
Older versions of ARM do not provide atomic instructions to increment a counter. This means that an atomic increment requires help from the OS. The naive approach would be to make it a system call which makes the process uninterruptible during the load-add-store instructions, but this has a lot of overhead from the interrupt handler. Instead, the Linux kernel has chosen to map a small bit of code into every process at a fixed address. This code contains the atomic increment instructions and can be called directly from user code. The kernel scheduler takes care of ensuring that any operations interrupted in this block are properly restarted.
First of all, system calls are synchronous software interrupts, not asynchronous. When the processor executes the trap machine instruction to go to kernel space, some of the kernel registers get changed by the interrupt handler functions. Modification of these registers requires privileged mode execution, i.e. these can not be changed using user space code.
When the user-space program cannot read data directly from disk, as it doesn't have control over the device driver. The user-space program should not bother with driver code. Communication with the device driver should take place through kernel code itself. We tend to believe that kernel code is pristine and entirely trustworthy; user code is always suspect.
Hence, it requires privileged instructions to change the contents of register and/or accessing driver functionalities; the user cannot execute system call functions as a normal function call. Your processor should know whether you are in the kernel mode to access these devices.
I hope this is clear to some extent.