I am just now learning about OSes and I stumbled upon this question from my class' lecture notes. In our class, we define a process as a program in execution and I know that an OS is itself a program. So by this definition, an OS is a process.
At the same time processes can be switched in or out via a context switch, which is something that the OS manages and handles. But what would handle the OS itself when it isn't running?
Also if it is a process, does the OS have a process control block associated with it?
There was an older question on this site that I looked at, but I felt as if the answers weren't clear enough to really outline WHY the OS is/isn't a process so I thought I'd ask again here.
First of all, an OS is multiple parts. The core piece is the kernel, which is not a process. It is a framework for running processes. In practice, a process is more than just a "program in execution". On a system with an MMU, a process is usually run in its own virtual address space. The kernel however, is usually mapped into all processes. It's always there.
Other ancillary parts of the OS exist to make it usuable. The OS may have processes that it runs as part of its management. For example, Linux has many kernel threads that are independently scheduled tasks. But these are often not crucial to the OS's operation.
Short answer: No.
Here's as good a definition of "Operating System" as any:
https://en.wikipedia.org/wiki/Operating_system
An operating system (OS) is system software that manages computer
hardware and software resources and provides common services for
computer programs. The operating system is a component of the system
software in a computer system. Application programs usually require an
operating system to function.
Even "system-level processes" (like "init" on Linux, or "svchost.exe" on Windows) rely on the "operating system" ... but are not themselves the operating system.
Agreeing to some of the comments above/below.
OS is not a process. However there are few variants in design that give the opposite illusion.
For eg: If you are running a FreeRTOS, then there is no such thing as a separate OS address space and Process address space, every thing runs as a single process, the FreeRTOS framework provides API's that allow Synchronization of different tasks.
Operating System is just a set of API's (system calls) and utilities that help to achieve Multi-processing, Resource sharing etc. For eg: schedule() is a core OS function that handles the multi-processing capabilities of the OS.
In that sense, OS is not a process. Although it attaches to every process that runs on the CPU, otherwise how will the process make use of the OS's API.
It is more like soul for the body (hardware), if you will.
It is just not one process but a set of (kernel) processes required to run user processes in the system. PID 0 being the parent of all processes providing scheduler/swapping functionality to the rest of the kernel/user processes, but it is not the only process. These kernel processes (with the help of kernel drivers) provide accessor functionality (through system calls) to the user processes.
It depends upon what you are calling the "operating system".
It depends upon what operating system you are talking about.
That said and at the risk of gross oversimplification, most of what one calls "the operating system" is generally executed from user processes while in kernel mode. The entry into kernel occurs either through an interrupt, trap or fault.
To do a context switch usually either a process causes a fault entering kernel mode to so something (like write to the disk). While in kernel mode, the process realizes it would have to wait so it yields by switching the context to another process. The other common way is a timer causes an interrupt, that forces the process into kernel mode. The process then determines who should be executed next, and switches the process context.
Some operating systems do have their own kernel process that function but that is increasingly rare.
Most operating system have components that have their own processes.
Related
I'm learning the concepts of operating system. This is part I've learned: kernel is key piece of os that does lots of critical things such as memory management, job scheduling etc.
This is part what I'm thinking and get confused: to have os operating as expected, in a sense kernel needs to keep running, perhaps in the background, so it is always able to respond to different system calls and interrupts. In order to achieve this, I think of two completely different approaches:
kernel actually spawns some processes purely on its behalf, not user process, and keep them running in background (like daemon)? These background processes will handle housekeeping stuff without acknowledgement from user or user process. I call this approach as "kernel is running on its own"
There is no kernel process at all. Every process we can find in os are all user processes. Kernel is nothing but a library (piece of code, along with some key data structures like page tables etc) shared among all these user processes. In each process's address space, some portion of kernel will be loaded so that when any interrupt or system call occurs, mode is elevated to kernel mode. Pieces of kernel code loaded into user process's address space will be executed so that kernel can handle the event. When kernel does that, it is still in the context of current user process. In this approach, there exists only user processes, but kernel will periodically run within the context of each user process (but in a different mode).
This is a conceptual question that has confused me for a while. Thanks in advance!
The answer to your question is mostly no. The kernel doesn't spawn kernel mode processes. At boot, the kernel might start some executables but they run in user mode as a privileged user. For example, the Linux kernel will start systemd as the first user mode process as the root user. This process will read configuration files (written by your distribution's developers like Ubuntu) and start some other processes like the X Server for graphics and basic input (from keyboard, mouse, etc).
Your #1 is wrong and your #2 is also somewhat wrong. The kernel isn't a library. It is code loaded in the top half of the virtual address space. The bottom half of the VAS is very big (several tens of thousands of GB) so user mode processes can become very big as long as you have physical RAM or swap space to back the memory they require. The top half of the VAS is shared between processes. For the bottom half, every process has theoretical access to all of it.
The kernel is called on system call and on interrupt. It doesn't run all the time like a process. It simply is called when an interrupt or syscall occurs. To make it work with more active processes than there are processor cores, timers will be used. On x86-64, each core has one local APIC. The local APIC has a timer that you can program to throw an interrupt after some time. The kernel will thus give a time slice to each process, choose one process in the list and start the timer with its corresponding time slice. When the timer throws an interrupt, the kernel knows that the time slice of that process is over and that it might be time to let another process take its place on that core.
First of all, A library can have its own background threads.
Secondly, the answer is somewhere between these approaches.
Most Unix-like system are built on a monolithic kernel (or hybrid one). That means the kernel contains all its background work in kernel threads in a single address space. I wrote in more details about this here.
On most Linux distributions, you can run
ps -ef | grep '\[.*\]'
And it will show you kernel threads.
But it will not show you "the kernel process", because ps basically only shows threads. Multithreaded processes will be seen via their main thread. But the kernel doesn't have a main thread, it owns all the threads.
If you want to look at processes via the lens of address spaces rather than threads, there's not really a way to do it. However, address spaces are useless if no thread can access them, So you access the actual address space of a thread (if you have permission) via /proc/<pid>/mem. So if you used the above ps command and found a kernel thread, you can see its address space using this approach.
But you don't have to search - you can also access the kernel's address space via /proc/kcore.
You will see, however, that these kernel threads aren't, for the most part, core kernel functionality such as scheduling & virtual memory management. In most Unix kernels, these happen during a system call by the thread that made the system call while it's running in kernel mode.
Windows, on the other hand, is built on a microkernel. That means that the kernel launches other processes and delegates work to them.
On Windows, that microkernel's address space is represented by the "System" service. The other processes - file systems, drivers etc., and other parts of what a monolithic kernel would comprise e.g. virtual memory management - might run in user mode or kernel mode, but still in a different address space than the microkernel.
You can get more details on how this works on Wikipedia.
Thirdly, just to be clear, that none of these concepts is to be confused with "system daemon", which are the regular userspace daemons that an OS needs in order to function, e.g. systemd, syslog, cron, etc..
Those are generally created by the "init" process (PID 1 on Unix systems) e.g. systemd, however systemd itself is created by the kernel at boot time.
How does the operating system manage the program permissions? If you are writing a low-level program without using any system calls, directly controlling the processor, then how does an operating system put stakes if the program directly controls the processor?
Edit
It seems that my question is not very clear, I apologize, I can not speak English well and I use the translator. Anyway, what I wonder is how an operating system manages the permissions of the programs (for example the root user etc ...). If a program is written to really low-level without making system calls, then can it have full access to the processor? If you want to say that it can do everything you want and as a result the various users / permissions that the operating system does not have much importance. However, from the first answer I received I read that you can not make useful programs that work without system calls, so a program can not interact directly with a hardware (I mean how the bios interacts with the hardware for example)?
Depends on the OS. Something like MS-DOS that is barely an OS and doesn't stop a program from taking over the whole machine essentially lets programs run with kernel privilege.
An any OS with memory-protection that tries to keep separate processes from stepping on each other, the kernel doesn't allow user-space processes to talk directly to I/O hardware.
A privileged user-space process might be allowed to memory-map video RAM and/or I/O registers of a device into its own address space, and basically act like a device driver. (e.g. an X server under Linux.)
1) It is imposible to have a program that that does not make any system calls.
2) Instructions that control the operation of the processor must be executed in kernel mode.
3) The only way to get into kernel mode is through an exception (including system calls). By controlling how exceptions are handled, the operating system prevents malicious access.
If a program is written to really low-level without making system calls, then can it have full access to the processor?
On a modern system this is impossible. A system call is going to be made in the background whether you like it or not.
In a computer system, the ISA level is lower than the OS level. The OS level is built upon the ISA level.
At the OS level, different programs run in different processes.
A program can run before another program finishes running, by context switching.
Programs in different processes do not affect each other.
Assume there is no OS and there is only one cpu core in the computer system. At the ISA level, there does not exist the concept of process. what is it like to run different programs?
must a program start to run after the previous program finishes running?
can the previous finished program affect the following program, in an untended or intended way?
The question "what is it like" sounds like a question about how the processor feels about running the instructions it is given. It just runs them.
It is not true entirely that there wouldn't be a concept of a process on ISA level. Processors may have hardware support for task switching, so they might actually know about them. Of course the OS will still be running the show.
Simply put, at the ISA level the software meets the hardware. So the single core CPU will just churn instructions and command peripherals from a preset memory location onwards until it's turned off or halts otherwise. Is there some other specific question about "what is it like"?
I am recently develop a big interest to learn about operating systems and I have been studying about this topic, I have a question that I am not pretty sure if is a valid one.
I am aware that the OS is the one who controls the process but,
is the OS a process itself? If so, who controls the OS?
Sorry for my ignorance I am learning about operating system and I am trying to have a solid idea about how it works.
Thanks in advance.
The term OS comes with some ambiguities... Does the user interface count as the OS? What about software that reads file systems?
The Kernel is generally the most important aspect of an Operating System. The Kernel is responsible for scheduling threads and processes, as well as abstracting the hardware from the software. The kernel itself is NOT a process, but it is a program. It's a program that always exists in every process space. When a process needs to access hardware, the kernel takes over and returns a response to the process. When the process's allotted time on the CPU is over, the kernel takes over and gives the CPU to a new process.
Other aspects of an Operating System, however, are their own processes. For example, on Windows, the user interface and many background services are their own processes. On Linux and other UNIX-like operating systems, the User Interfaces are also in their own respective processes, and in some cases things like filesystem drivers are in their own process as well, sometimes this is considered a hardware abstraction and is therefore placed in the kernel.
There are many possible design choices, however when it comes down to it there will always be a part of the operating system (the Kernel) that will never be it's own process.
The OS is a bunch of processes. It is started up during the boot process. How the boot process works depends on the system. But generally, the boot process is also a process whose sole job is to start up the OS.
The OS is generally specific to the hardware it runs on. A main function of the OS is to be a layer between the hardware and application programs. Which processes in the OS are used depend on what functions the application programs need to do.
It depends on design approaches.
According to 3.5 section of "Operating Systems Internal and Design Principles - 7th edition" textbook (written by William Stalling), there are 3 approaches:
non-process kernel.
In this approach, user process and kernel are separate.
process image = address space + PCB = (code + data + stack + heap) + PCB
Execution within User Process
In this approach, some common functions of Operation Systems (run in kernel mode) belong to User processes.
process image = PCB + user address space + kernel address space = PCB + (user code + user data + user stack + user heap) + (kernel code + kernel data + kernel stack + kernel heap).
Process-Based Operating System.
In this approach Operating System is a collection of system processes, each system process executes in kernel mode, and is in charge of specific function.
In addition, these system processes separate with user processes.
Best Regards
Viet Nam.
I saw this question somewhere
Four processes p1, p2, p3, p4 - each have sizes 1GB, 1.2GB, 2GB, 1GB. And each processes is executed as a time sharing fashion. Will they be executed on an operating system.
I think the answer should be No,they are not executed on operating system because OS is itself a process and it will be running in parallel to these processes.There will be switching between processes from time to time with the help of dispatcher.
but i am getting the doubt that answer can also be yes because it uses every process uses memory which is managed by theb operating system .
please help me figure out the right answer for the question..
This depends entirely on the OS in question.
As well as starting processes (and possibly consisting of processes), an operating system generally provides services to the processes that run on it, such as memory management, file systems, communications and so on.
In that context, these processes can be said to be running on top of the OS. In other words, processes generally are of little use unless they communicate outside of themselves.
In any event, the dispatcher (or scheduler) tends to be an integral part of the OS so having your processes scheduled means that you're running on top of that OS.
Modern operating systems also provide paging of memory as well which means that you can use a lot more virtual memory than there is physical memory - the OS is then responsible for handling requests for memory that has been paged out.
If two processes co exist, they have their own share of memory. What we assume operating system does is scheduling. Operating system may ask one of the process to stop and another to begin