in kernel and user space

Now I know that developing an app tha开发者_如何学运维t goes into kernel space should be avoided - its hard to debug, complex etc.... with that off the table what are some advantages to moving an app from user space to the kernel? after all if there were no plus sides it would never be done...what are some?

Some possible advantages:

• system calls might be faster (i.e. lower latencies), as the CPU doesn't have to switch from application mode into kernel mode. (This is not necessarily true, as the CPU might make a finer distinction than simply "user space" and "kernel space". Intel x86 CPUs for example have a ring model encompassing 4 distinct privilege levels.) ¹⁾

• you might get direct access to the system's hardware via memory and I/O ports.

• you might be able to suppress task switching, if you need to do something without being interrupted

• you might be able to circumvent security mechanisms enforced by the operating system (e.g. read/modify other processes' memory). (Malware could take advantage of this if it gets installed as a kernel-mode device driver.)

(And of course, as you are aware, there's many many disadvantages and security risks. The distinction between application space and kernel space is there for good reasons.)

¹⁾ See e.g. the article Making system calls from kernel space from Linux mag:

For example, a high-performance Web server may wish to reside in the kernel for increased throughput and lower latency. However, there is also a safety tradeoff [...]

You get the chance for a tiny bug in your program to scribble all over memory and corrupt the entire system and all its processes and functions. If you are lucky, the system will crash.

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

1) When dedicated processing is required and we want to use the utilities built in the OS. Eg: If we were to design an IO server. Here the latencies are to the tune of 1-5 ms. One cannot wait for context switches due to kernel - user mode tradeoffs. But if one has to rely on TCP IP framework given by kernel. It has to be implemented in Kernel mode closely tying the Network /TCP/IP framework and your intended transport framework.

2) When you want to completely own the scheduling framework. While this is intuitively available using various system calls and pthread frameworks. However, If your product/threads completely owns the processor, then there are cases of deadlocks or livelock you may want to recover from. In such scenarios you would need a framework that account for the time taken by each thread. This cannot be done from user lan and hence support from kernel scheduler/schedule subsystem is required.

3) When you want to over load access to memory, again in environments where resources are dedicated for a particular operations. It makes sense to overlay the physical memory/kernel memory for virtual threads.

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

There could be many more reasons but the central root cause:

1)Whenever you want to cut down layers for performance you move to kernel. Since kernel adds virtualisation framework for fairly sharing the resources (cpu, ram, network, disk).

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