In the kernel and user space

Question

Now I know that you should avoid developing an application that goes into the kernel space - it is difficult to debug, complicated, etc .... with that outside the table, what are the advantages for moving the application from user space to the kernel? in the end, if there were no plus sides, it would never have been done ... any?

Answer 1

Some possible benefits:

• system calls can be faster (i.e., lower latencies ) because the CPU does not have to switch from application mode to kernel mode. (This is not necessarily the case, since the processor can make a more precise difference than just “user space” and “kernel space.” For example, Intel x86 processors have a ring model that spans 4 different privilege levels.) ¹⁾

• You can directly access system equipment through memory and I / O ports.

• you can disable task switching if you need to do something without interruption

• You can bypass the security mechanisms operating in the operating system (for example, reading / changing the memory of other processes). (Malicious software can take advantage of this if it is installed as a device driver in kernel mode.)

(And, of course, as you know, there are many security flaws and risks. The difference between application space and kernel space exists for good reasons.)

---

¹⁾ See, for example, the article Making system calls from kernel space from Linux mag :

For example, a high-performance web server might want to reside in the kernel to increase throughput and lower latency. However, there is also a trade-off between security [...]

Answer 2

You have a chance for a tiny mistake in your program to draw all the memory and damage the whole system and all its processes and functions. If you are lucky, the system will fail.

Answer 3

Some of the reasons that come to my mind when searching for options. Kernel mode vs user mode:

1) When special processing is required, and we want to use utilities created in the OS. For example: if we were designing an IO server. Here the delay is 1-5 ms. Unable to wait for context switches due to kernel mode tradeoffs. But if you need to rely on the TCP IP infrastructure defined by the kernel. It should be implemented in kernel mode, closely linking the network structure / TCP / IP and the intended transport infrastructure.

2) If you want to completely create a planning structure. Although this is intuitively available using various system calls and pthread frames. However, if your product / threads fully owns the processor, then there are cases of deadlocks or livelocks that you might want to recover. In such scenarios, you will need a structure that takes into account the time spent by each thread. This cannot be done from a custom lan, and therefore requires support for the kernel scheduler / schedule subsystem.

3) If you want to overload memory access, again in environments where resources are designed for specific operations. It makes sense to overlay physical / kernel memory on virtual threads.

4) If you want to virtualize disk access either to add redundancy or to increase read / write performance.

There could be many reasons, but the main reason:

1) Whenever you want to cut layers for performance, you go to the kernel. Because the kernel adds a virtualization infrastructure for fair sharing of resources (CPU, RAM, network, disk).

2) Whenever you want to use the kernel infrastructure for use, which are difficult to port to a user lan (Tcp / ip or shceduler).