What is the difference between the kernel space an

Question

What is the difference between the kernel space and the user space? Do kernel space, kernel threads, kernel processes and kernel stack mean the same thing? Also, why do we need this differentiation?

Answer 1

Trying to give a very simplified explanation

Virtual Memory is divided into kernel space and the user space. Kernel space is that area of virtual memory where kernel processes will run and user space is that area of virtual memory where user processes will be running.

This division is required for memory access protections.

Whenever a bootloader starts a kernel after loading it to a location in RAM, (on an ARM based controller typically)it needs to make sure that the controller is in supervisor mode with FIQ's and IRQ's disabled.

Answer 2

The maximum size of address space depends on the length of the address register on the CPU.

On systems with 32-bit address registers, the maximum size of address space is 2³² bytes, or 4 GiB. Similarly, on 64-bit systems, 2⁶⁴ bytes can be addressed.

Such address space is called virtual memory or virtual address space. It is not actually related to physical RAM size.

On Linux platforms, virtual address space is divided into kernel space and user space.

An architecture-specific constant called task size limit, or TASK_SIZE, marks the position where the split occurs:

• the address range from 0 up to TASK_SIZE-1 is allotted to user space;

• the remainder from TASK_SIZE up to 2³²-1 (or 2⁶⁴-1) is allotted to kernel space.

On a particular 32-bit system for example, 3 GiB could be occupied for user space and 1 GiB for kernel space.

Each application/program in a Unix-like operating system is a process; each of those has a unique identifier called Process Identifier (or simply Process ID, i.e. PID). Linux provides two mechanisms for creating a process: 1. the fork() system call, or 2. the exec() call.

A kernel thread is a lightweight process and also a program under execution. A single process may consist of several threads sharing the same data and resources but taking different paths through the program code. Linux provides a clone() system call to generate threads.

Example uses of kernel threads are: data synchronization of RAM, helping the scheduler to distribute processes among CPUs, etc.

Answer 3

Each process has its own 4GB of virtual memory which maps to the physical memory through page tables. The virtual memory is mostly split in two parts: 3 GB for the use of the process and 1 GB for the use of the Kernel. Most of the variables you create lie in the first part of the address space. That part is called user space. The last part is where the kernel resides and is common for all the processes. This is called Kernel space and most of this space is mapped to the starting locations of physical memory where the kernel image is loaded at boot time.

Answer 4

The correct answer is: There is no such thing as kernel space and user space. The processor instruction set has special permissions to set destructive things like the root of the page table map, or access hardware device memory, etc.

Kernel code has the highest level privileges, and user code the lowest. This prevents user code from crashing the system, modifying other programs, etc.

Generally kernel code is kept under a different memory map than user code (just as user spaces are kept in different memory maps than each other). This is where the "kernel space" and "user space" terms come from. But that is not a hard and fast rule. For example, since the x86 indirectly requires its interrupt/trap handlers to be mapped at all times, part (or some OSes all) of the kernel must be mapped into user space. Again, this does not mean that such code has user privileges.

Why is the kernel/user divide necessary? Some designers disagree that it is, in fact, necessary. Microkernel architecture is based on the idea that the highest privileged sections of code should be as small as possible, with all significant operations done in user privileged code. You would need to study why this might be a good idea, it is not a simple concept (and is famous for both having advantages and drawbacks).

Answer 5

Kernel space & virtual space are concepts of virtual memory....it doesn't mean Ram(your actual memory) is divided into kernel & User space. Each process is given virtual memory which is divided into kernel & user space.

So saying "The random access memory (RAM) can be divided into two distinct regions namely - the kernel space and the user space." is wrong.

& regarding "kernel space vs user space" thing

When a process is created and its virtual memory is divided into user-space and a kernel-space , where user space region contains data, code, stack, heap of the process & kernel-space contains things such as the page table for the process, kernel data structures and kernel code etc. To run kernel space code, control must shift to kernel mode(using 0x80 software interrupt for system calls) & kernel stack is basically shared among all processes currently executing in kernel space.

Answer 6

The Random Access Memory (RAM) can be logically divided into two distinct regions namely - the kernel space and the user space.(The Physical Addresses of the RAM are not actually divided only the Virtual Addresses, all this implemented by the MMU)

The kernel runs in the part of memory entitled to it. This part of memory cannot be accessed directly by the processes of the normal users, while as the kernel can access all parts of the memory. To access some part of the kernel, the user processes have to use the predefined system calls i.e. open, read, write etc. Also, the C library functions like printf call the system call write in turn.

The system calls act as an interface between the user processes and the kernel processes. The access rights are placed on the kernel space in order to stop the users from messing up with the kernel, unknowingly.

So, when a system call occurs, a software interrupt is sent to the kernel. The CPU may hand over the control temporarily to the associated interrupt handler routine. The kernel process which was halted by the interrupt resumes after the interrupt handler routine finishes its job.