Are kernel threads processes and daemons?

Question

From Mauerer's Linux Kernel Architecture,

Kernel threads are processes started directly by the kernel itself. They delegate a kernel function to a separate process and execute it there in ‘‘parallel‘‘ to the other processes in the system (and, in fact, in parallel to execution of the kernel itself). Kernel threads are often referred to as (kernel) daemons. They are used to perform, for example, the following tasks:

• To periodically synchronize modified memory pages with the block device from which the pages originate (e.g., files mapped using mmap ).
• To write memory pages into the swap area if they are seldom used.
• To manage deferred actions.
• To implement transaction journals for filesystems.

Basically, there are two types of kernel thread:

• Type 1 — The thread is started and waits until requested by the kernel to perform a specific action.
• Type 2 — Once started, the thread runs at periodic intervals, checks the utilization of a specific resource, and takes action when utilization exceeds or falls below a set limit value. The kernel uses this type of thread for continuous monitoring tasks.

1. Since Mauerer's book says kernel threads are processes, I think that they must be running in user mode, instead of kernel mode. (or am I wrong? Can a process run in either user mode or kernel mode at different times, or only one mode?)

   But Bovet's Understanding Linux Kernel says kernel threads are running only in kernel mode (see the quote below). Are the concepts of "kernel thread" in the two books the same concept?

   Traditional Unix systems delegate some critical tasks to intermittently running processes, including flushing disk caches, swapping out unused pages, servicing network connections, and so on. Indeed, it is not efficient to perform these tasks in strict linear fashion; both their functions and the end user processes get better response if they are scheduled in the background. Because some of the system processes run only in Kernel Mode, modern operating systems delegate their functions to kernel threads, which are not encumbered with the unnecessary User Mode context. In Linux, kernel threads differ from regular processes in the following ways:

   • Kernel threads run only in Kernel Mode, while regular processes run alterna- tively in Kernel Mode and in User Mode.
   • Because kernel threads run only in Kernel Mode, they use only linear addresses greater than PAGE_OFFSET . Regular processes, on the other hand, use all four gigabytes of linear addresses, in either User Mode or Kernel Mode.

2. Mauerer's book says kernel threads are started directly by the kernel, and it seems to also say that daemons are synonyms of kernel threads. So I think daemons must be started directly by the kernel.

   But https://unix.stackexchange.com/a/193918/674 says that screen's daemon is started by screen user interface (see the quote below). I think screen user interface is a process, instead of the kernel. Are the concepts of daemon in Mauerer's book and in the linked reply the same concept?

   When you first start screen, you are actually starting a user interface (ui), which by default will create a daemon (the session manager).

3. In general, How do you understand the concepts of "kernel threads", "process", and "daemon", their relations and their differences?

Answer 1

First : Credit goes https://stackoverflow.com/questions/15983872/difference-between-user-level-and-kernel-supported-threads

User threads and Kernel threads are exactly the same. (You can see by looking in /proc/ and see that the kernel threads are there too.)

A User thread is one that executes user-space code. But it can call into kernel space at any time. It's still considered a "User" thread, even though it's executing kernel code at elevated security levels.

A Kernel thread is one that only runs kernel code and isn't associated with a user-space process. These are like "UNIX daemons", except they are kernel-only daemons. So you could say that the kernel is a multi-threaded program. For example, there is a kernel thread for swap. This forces all swap issues to get "serialized" into a single stream.

If a user thread needs something, it will call into the kernel, which marks that thread as sleeping. Later, the swap thread finds the data, so it marks the user thread as runnable. Later still, the "user thread" returns from the kernel back to userland as if nothing happened.

In fact, all threads start off in kernel space, because the clone() operation happens in kernel space. (And there's lots of kernel accounting to do before you can 'return' to a new process in user space.)